Intel x86-simd-sort“故意”对 AMD 负优化？

逛国外论坛时收到来自 Java 节点的推送：
Heads up: OpenJDK implementation of AVX512 based sorting will perform poorly on AMD systems.
（背景事件：OpenJDK 采纳了 x86-simd-sort 用于快速排序）

正文提到，x86-simd-sort在 AMD Zen 4 处理器的性能十分糟糕，原因是 AMD 平台的 compressstoreu 效率太差。
今年 2 月份的时候就已经有人开了 issue 提到这个问题：performance on amd 7950x
里面有测试结果的对比，可以发现 x86-simd-sort 在 AMD 平台的部份测试结果甚至比标准库更慢，最慢的甚至只有标准库的十分之一。原本是用来优化加速的库，用在 AMD 就成了负优化。

其实已经有人做好了解决办法，来自于该 issue 评论区的其中一位用户（其实就是他解答了原因——compressstoreu 的执行效率），不过就是从未推送回上游。

Intel 自己显然是没必要去“修”的，但也不见 AMD 有提交“修补”的 Pull Request 。

既然 OpenJDK“吸收”了 Intel 的这个排序库，那么人们可能会发现，同一套 Java 程序跑在 Intel 比起 AMD 快得多，然后可能会推断出“AMD 不行”的结论。

表面上看，这是 AMD 的锅。但考虑到 Intel 编译器曾经有过针对 AMD 做过负优化的黑历史，所以我也不能不怀疑，Intel 在开发 x86-simd-sort 的过程中，是否专门筛选过 AMD 的弱项，然后针对性地负优化。

现在就看 AMD Zen 5 及后续新架构会不会直接“修复”这个 bug 。

鉴于 x86-simd-sort 是 C++库，所以还是发在 C++节点了

lonewolfakela

215 天前

两方面来看，一方面我觉得没有实锤证据的时候，还是没有必要恶意地去揣测动机。intel 写这玩意儿的时候没考虑/没测试 AMD CPU 上的性能也很正常，完全没必要用阴谋论视角来解释这件事。

另外一方面，AMD 这弄一个加速指令速度能比软件模拟还慢，这不管怎么说那就是自己菜。就算 Intel 是专门搜索了一番才故意找到这个 AMD 的弱点，就我看来这也是 AMD 自己没做好。功能做的不够好就得承担有朝一日被人发现了拿来做文章的风险，根源只能怪自己菜不能怪别人故意找茬。

mokiki

215 天前

@lonewolfakela
> intel 写这玩意儿的时候没考虑/没测试 AMD CPU 上的性能也很正常，完全没必要用阴谋论视角来解释这件事。
与你的观点完全相反，Intel 肯定知道这个世界上有 AMD 的 CPU 。这种针对性优化的代码肯定想到了对竞争对手的影响。Intel 阴谋的可能性非常大。

体面的做法是提供编译选项。这样 OpenJDK 二进制版可以由 OpenJDK 官方选择编译选项，Gentoo 这样的优秀发行版也可以提供 USE 由用户进行选择。