ExplodingDragon

顺便贴一下使用 chatgpt pro 的结果 , 无法跳步或 SIMD 就没继续看了 （：

这段原始代码不能直接用“常数快速幂”或“矩阵快速幂”跳过 1e14 轮。关键原因是：x ^= x >> 32 不是高低 32 位交换，而是把高 32 位异或进低 32 位；它虽然可逆，但和普通整数乘法的进位混在一起后，整体既不是模 2^64 乘法，也不是 GF(2) 线性变换。

设 B = 2^32 ，C = 0xD1342543DE82EF95 = aB + b ，x = hB + l 。一轮乘法后：

```
L = b*l mod B
H = b*h + a*l + floor(b*l / B) mod B
```

随后：

```
T(h, l) = (H, L xor H)
```

问题就在这里：H 里有整数乘法进位 floor(b*l / B)，而低位又用了 xor 。这会把“模加/乘”的结构和“GF(2) 异或线性”的结构打碎。

一个很小的反例就能排除快速幂假设：

T(1) = 0xd13425430fb6cad6
T(2) = 0xa2684a871f6d95ad

如果它等价于某个常数乘法 T(x)=Kx mod 2^64 ，那么应有：

```
2*T(1) mod 2^64 = 0xa2684a861f6d95ac
```

但实际 T(2) 多了 0x100000001 。这就是进位和异或混合造成的偏差。

同样，它也不是 GF(2) 线性的：

```
T(1 xor 2) != T(1) xor T(2)
```

所以这类写法都不成立：


```
// 错：只能用于纯乘法状态转移
x *= pow_mod(C, n, 2^64);

// 错：只能用于真正的 GF(2) 线性 xorshift
matrix_pow(M, n) * x;
```

这个常数本身确实是常见的 64 位 LCG/LXM 乘子； OpenJDK 相关实现也把 0xd1342543de82ef95 用作 LCG 乘子并说明其谱测试分数。也就是说，如果状态转移只是 LCG 乘法/加法，它能快进；但你这里把 mix 结果反馈回状态了，结构就变了。

@iqoo #29 所以这是打算利用 wasm 嵌入到浏览器做 PoW 来对抗爬虫或者其他自动化工具 ?

我去，初音未来！

看了下 bun 已经合并了 rust pr 了 hhhh ，这种项目还是在小圈子自萌去吧，架构/语言说变就变，旧的 pr / issue 完全不管，藐视贡献者玩独裁主义

https://github.com/oven-sh/bun/pull/30412

根本不需要分辨 , 大部分都是假的

看到群组有人发了也测试了下，但还是字体有问题