引用:

原帖由 EraserKing 于 2020-1-30 17:16 发表

先把Mesh的延迟降下来再吹吧

延迟并不是太大问题，或者说延迟问题本身已经体现在较桌面架构略差的性能上了。

云服务商使用至强可以方便的配置1~14核规模的云配置，到28核仍享受完整的缓存。
而用EPYC1~4核不成问题，更大规模就缓存不一致了，需要额外做一致性优化本身就是性能损失和安全问题。
更多情况下，2~4核的场合也因为此前已分配的情况导致剩余的核心位置离散分布在不同的缓存区块，那要么额外做一致性优化，要么就只能去分配完整CCX，把那些空闲核心当垃圾资源浪费掉。

引用:

原帖由 EraserKing 于 2020-1-30 18:57 发表

跨CCD的Cache延迟比Ring Bus下还低，缓存一致性的那一点性能小开销就不劳您操心了
至于安全漏洞在哪呢，是不是还在脑补中呢

如果跨CCX了L3缓存会去存两份并且要应付一致性问题，而英特尔那边L3缓存只有一份。这不是延迟大小的问题，这会增加大量的本无必要的操作，结果就是性能的下降。

安全功能在哪呢？
比如最近英特尔的漏洞CacheOut，AMD这边在功能上压根是缺失的。

引用:

原帖由 EraserKing 于 2020-1-31 11:11 发表

不要说跨CCX，就算跨CCD之后性能也比Mesh强，就不用您操心了
CacheOut我看了下，哦，又来一个漏洞啊，不过这个是TSX的，早就建议关掉了，都关掉的安全功能还算安全功能么

执行不必要操作的效率再高也是白白降低性能。
这也是为啥说zen系列不适合跑既有代码的并行计算，因为稍微增加规模就需要新的优化策略（4->5有跨CCX问题，8->9有跨CCD问题，16->17跨iodie区，32->33跨NUMA区），不能简单就高效运行。

漏洞可以补
功能缺失没有救

引用:

原帖由 EraserKing 于 2020-1-31 18:47 发表

降低了也是很强啊，优化也不能突破物理限制
VoltJockey这样的硬件漏洞现在是怎么补的啊，你给说说呗，还是你云修复了

结果就是如果跨CCX,同样核心数的EPYC云的性能会明显不及英特尔，大概只有60~70%，这还是优化后的结果。
目前EPYC2云平台非常非常吃优化，好的例子64核确实匹敌英特尔56核，但大部分哪怕优化后还是不及的，而不优化很多只能跑出英特尔1/10水平就是那么真实。

如果说安全功能缺失让一部分服务商根本不敢考虑AMD方案，那么落后的缓存体系极大的增加了另一部分愿意尝试的云服务商的成本，虽然64核只有英特尔28核价格，但是要发挥性能的转移成本却很高。

引用:

原帖由 EraserKing 于 2020-1-31 18:47 发表

降低了也是很强啊，优化也不能突破物理限制
VoltJockey这样的硬件漏洞现在是怎么补的啊，你给说说呗，还是你云修复了

顺便一提，根治VoltJockey的方法非常简单，让调压范围略略收窄，代价是略微影响了待机功耗（但仍远远好于AMD平台）。

引用:

原帖由 EraserKing 于 2020-1-31 20:53 发表

又开始编数据了，不知道从哪脑补的
NF用单路Epyc就可以打双路Xeon了，你自己找链接吧，23333

优化后大部分情况是比单路强但不如双路，同核心数性能是至强的60~70%。

引用:

原帖由 EraserKing 于 2020-1-31 20:55 发表

治了吗，这么简单怎么还没出补丁啊，2333

没出微码补丁，但已经出了基于bios的解决方案。

引用:

原帖由 EraserKing 于 2020-1-31 21:24 发表

是哪家厂商的谁在何时何地说的啊，是你自创的评测标准吗，给个链接呗，没证据就是纯造谣了

云服务，VMmark的综合性权威性没话说吧。

https://www.vmware.com/content/d ... ujitsu-RX4770M4.pdf
224核 14.86

https://www.vmware.com/content/d ... iant-DL385Gen10.pdf
256核 12.78

引用:

原帖由 EraserKing 于 2020-1-31 23:14 发表

喜欢VMMark的话世界记录在这里：
https://www.amd.com/system/files ... cord-VMmark3-CN.pdf

限定的真好，靠插槽少回避了实际上一个插槽上是胶水8芯，且有16个独立缓存区的实际问题。
不过事实是，真要耍赖，英特尔也有单插槽56核的，2节点2路的性能可以参考我前面发的2节点4路，仍旧是英特尔更强。