逛国外论坛时收到来自 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++节点了

万恶的 Intel ，快凉凉吧～～希望 ARM64 在移动平台快快发力。现在 8cx gen3 还是太弱鸡了。游戏平台就选 AMD 没错的，12C 16C 的大核

两方面来看，一方面我觉得没有实锤证据的时候，还是没有必要恶意地去揣测动机。intel 写这玩意儿的时候没考虑/没测试 AMD CPU 上的性能也很正常，完全没必要用阴谋论视角来解释这件事。另外一方面，AMD 这弄一个加速指令速度能比软件模拟还慢，这不管怎么说那就是自己菜。就算 Intel 是专门搜索了一番才故意找到这个 AMD 的弱点，就我看来这也是 AMD 自己没做好。功能做的不够好就得承担有朝一日被人发现了拿来做文章的风险，根源只能怪自己菜不能怪别人故意找茬。

intel 写这玩意儿的时候没考虑/没测试 AMD CPU 上的性能也很正常，完全没必要用阴谋论视角来解释这件事。与你的观点完全相反，Intel 肯定知道 这个世界上有 AMD 的 CPU 。这种针对性优化的代码肯定想到了对竞争对手的影响。Intel 阴谋的可能性非常大。体面的做法是提供编译选项。这样 OpenJDK 二进制版可以由 OpenJDK 官方选择编译选项，Gentoo 这样的优秀发行版也可以提供 USE 由用户进行选择。

笑了，世界上就两家 x86 CPU ，然后一家在写自家软件的时候 “没考虑” 对家要真没考虑，那也是和标准库性能接近，而不是比标准库性能还差

想知道是否哪个 openjdk 版本被证实受这个 bug 影响。

所有 OpenJDK 正式版都暂时未受影响，因为这个 commit 的时间（到目前为止）连 24 小时都不到： github.com/openjdk/jdk/commit/a4e9168bab1c2872ce2dbc7971a45c259270271f

看了下代码，没有故意判断 Amd 走其它的分支，只能说是 Amd 对 simd 优化不行

amd 服务器端已经是屠榜. Intel 这几年服务器被蚕食不少.

说难听点 x86 服务器市场都是 intel 打下的江山，各种软件基础设施 intel 也贡献的不少。amd 这种整天搭开源社区跟 intel 的便车的，被区别对待也是活该

amd 能不能争气点，自己搞个 compiler ，别搭 gcc 的车。。

＃9 AMD64: ?

intel 为什么要考虑 amd 的性能？你魔怔了吧。倒是 jdk 没有做深入测试就把东西和进来才是该批评的

呵呵，看人家 arm64 是个完全不一样的指令集，趁机甩了包袱。过几年让 arm 把服务器市场抢了，amd 也是有锅的。

我有罪

看了一下，代码只是用 supports_avx512dq() 来判断条件的。总不能用 is_intel & avx512dq 来判断吧，那才是专门针对自家优化，落人口实。

＃13 ？

amd 软件生态烂也不是一天两天了

逻辑应该是 Intel 在 AMD64 平台上做了 SIMD 的排序加速 并且开源回馈给社区但是 AMD 的 SIMD 实现性能有问题导致开源的代码在 AMD 上效率不佳这也能怪 Intel? AMD 怎么不写个 AMD 性能好 Intel 性能不好的排序呢？

早年间 Intel MKL 的问题不比这大多了

aocc?

amd 似乎没有 avx512

Zen4 开始支持的： en.wikichip.org/wiki/x86/avx512dq

amd 骨子里看不起软件，不吃自己的狗粮，不好好开发自己的 mkl 和 cuda ，只能说活该。

热知识：AMD 的 AVX512 甚至在有些工况下比 Intel 的 AVX512 还快。Intel 的 AVX512 需要仔细调优否则分分钟降频抹平一切性能优势。AMD 可以无脑启用，因为几乎总是跑得更快。

真 nb ，人家 reddit 评了这个是直接抄 intel 的 implementation 。intel 写啥东西都要帮 amd 测，请问我 intel 码农能拿 amd 给的奖金吗？
楼上很多“胜者为王”的说法，其实是和当今世界逆向而行。我认为不能说 AMD 某个指令慢就说所有的 AMD 用户活该。这和某些游戏只为 Nvidia 或 AMD 特性优化，有意无意地裂化另一方是一样的情况。

ROCm: ?反倒是 Intel 没有对标 CUDA 和 ROCm 的东西。ROCm 是和 CUDA API 级兼容，目前 PyTorch 官方唯二支持的 GPU 加速就只有 CUDA 和 ROCm 。在正经生产环境训练 AI 的话，排除一些公司自研的 AI 芯片，应该除了 CUDA 就只有 ROCm 了。

只要他不提交到公共的开源类库，他当然不需要帮别的平台测啦。提交一个让竞争对手运行速度变慢的「优化」到公共类库？有本事你 Intel fork 一个自己品牌的项目，随便你怎么瞎搞，把 Intel CPU 运行速度优化成 AMD 的一万倍也是你的本事。看看 Clear Linux ，Intel 自己发行的，专门为 Intel 优化的，在 AMD 平台上跑得再慢也没人怪你。Intel C++ Compiler ，也是针对 Intel 优化的。（而且就算是 ICL 这样 Intel 自己的产品，为 AMD 做反优化也已经涉嫌违反反垄断法吃官司了。）这 OpenJDK 又不是你 Intel 搞出来的。

我本来也想说这部分代码 "pretty much directly copied over from Intel's own implementation"但是查了一下 commit 的作者 github.com/openjdk/jdk/commit/a4e9168bab1c2872ce2dbc7971a45c259270271f github.com/vamsi-parasa他的 GitHub 上写着 Intel ，那我只能认为这个事情是 Intel 干的了。不过 openjdk 这种大项目理应自己认真测过再合并，结果没有。

AMD 经常出现：各方面参数都很好，但就是不好用。显卡，low1%不好看，卡顿。cpu 倒没奇怪问题，就是主板平台小问题多，还有内存兼容问题也多。

每次云主机选服务器时，看到 amd 的价格心动，但总是要慎重地考虑一番。

我的意思就是 intel 工程师提交的，为啥要给 amd 测？

openjdk 是你家 amd 的吗？我反问一句，这种变动为什么没有 amd 的来 review 呢？自己都不管了，让 intel 管是吧。

楼又歪了

首先，这种变动应该是 openjdk 来 review 。其次，openjdk 应该让 intel 出具 benchmark 报告。amd 不提 PR 所以他没有义务去 review 。Intel 提了 PR ，当然有义务保证提的 PR 的质量。Intel 不愿意在其他平台测，他可以不往公共类库里塞东西啊。他自己搞个 Intel JDK 又没人会说他。凭什么公共项目可以给你 Intel 放会给 AMD 减速的代码？不愿意好好做 PR 可以不做，不会怪你的。

你自己都说出了主责在 openjdk ，不知道哪来的逻辑还能扣给 intel 。是，那以后大家都别给开源项目做贡献了，每个 PR 都得 perfect ，都不能有瑕疵。

测试都不愿意好好做的程序员这边还是建议不要乱给开源项目做贡献了。

看你这么清高也应该没做过啥开源