hardware.fr对Ryzen性能低下原因的一些猜想
http://www.hardware.fr/articles/956-22/retour-sous-systeme-memoire.html看到有人在转这个的机翻，那就随手翻一下（不懂软硬件瞎翻）：
可能的三大原因：
- RAM延时过高
- CCX之间的带宽严重不足
- CCX之间的cache访问开销巨大
考虑到以上原因，以及Windows习惯于不停地将线程在不同核心之间转来转去，很可能将线程从一个CCX转到另一个CCX时开销非常巨大
有两种情况容易导致性能低下：
- 线程在转移时，会导致访问cache内数据的延时太高
- 线程无论被转移与否，塞爆了cache
比如在7z和winrar的测试中，更可能是第二种情况，此类软件会持续调用超大的压缩字典。此时CCX之间有限的内存带宽是一个瓶颈
在游戏中，则更偏向于第一种情况，或者是一和二皆有
问题这就无药可救了吗？
也不一定，一种可能的方案是修改windows的调度器，限制跨CCX的线程转移，和推土机时代针对模块（1M2C）的措施有点像
另一种可能对游戏性能有益的方案，就是win10将要引入的“游戏模式”
游戏模式的特点之一，就是减少线程的转移
其他一些补救措施，小aa应该会在GDC大会期间介绍，以后我们会聊到这个话题
目前还无法知道这些措施能有多大效果，而且和每个程序员具体如何开发高度相关
至于CCX之间低下的带宽、高延时，那是完全没救了，只能等下一代zen
Si vous nous avez suivi jusqu'ici, on peut commencer à voir les causes des ralentissements que nous notons dans certains benchmarks. Si l'on résume ce que l'on a pu voir jusqu'ici :
La latence mémoire de Ryzen est plus élevée
La bande passante entre les CCX est particulièrement réduite
Les accès caches entre CCX sont coûteux
Si l'on rajoute la tendance de Windows à déplacer les threads en permanence, on peut commencer à comprendre un peu mieux certains comportements. En effet, balader les threads d'un CCX à l'autre est excessivement couteux sur Ryzen dont la bande passante entre les CCX est réduite.
On peut imaginer facilement deux cas qui causeront des ralentissements :
des threads qui, lorsqu'ils sont balladés payent un prix fort en latence pour accéder aux données de leurs caches
des threads qui, balladés ou non, saturent l'intégralité du cache
Dans le cas de 7-Zip ou de WinRAR, on penchera sur la seconde option, en pratique ces logiciels utilisent un dictionnaire de compression particulièrement large auxquels ils font référence en permanence. Nous supposons que dans ce cas, la bande passante mémoire limitée entre les CCX est un facteur limitant.
Pour les jeux, nous supposons que l'on est plus proche du premier cas, ou d'un mix des deux.
Le problème est-il donc insoluble? Probablement pas, plusieurs solutions sont envisageables, comme par exemple une adaptation du scheduler de Windows pour limiter les déplacements des threads hors du CCX, un peu à l'image de ce qui était fait pour Bulldozer avec les modules. On peut imaginer qu'AMD travaille avec Microsoft pour implémenter un système de ce type, même si le constructeur n'a pas pu nous le confirmer.
Un autre changement qui pourrait se révéler salutaire pour les jeux est l'arrivée du "Game Mode" de Windows 10, dont l'une des particularités est justement là aussi, de moins bouger les threads. D'autres techniques de mitigations sont envisageables et AMD devrait présenter lors d'une session à la GDC plusieurs d'entre elles, nous vous en reparlerons.
Quelle partie de l'écart sera rattrapée par ces éventuels correctifs, patchs, et modifications ? C'est en l'état impossible à dire et il faut rester très prudent sur ce que feront, ou non, les divers développeurs concernés. La bande passante réduite entre les CCX et la latence élevée resteront des choses qui elles n'évolueront pas, en tout cas pas avant une future révision de Zen.
内容差不多的英文贴：
Causes of poor gaming relative to CPU performance of Ryzen:
1. Windows is load-balancing across CCXes.
This means that a thread is being moved around on the CPU - which is normal - so that a single core isn't used more than others. On Ryzen, that needs to happen ONLY within a CCX, otherwise you will incur a massive penalty when that thread no longer finds its data in the caches of the CCX.
2. SMT hurts single threaded performance due to shared structure.
Ryzen statically partitions three structures to support SMT:
a. Micro-op queue (dispatcher)
b. Retirement queue
c. Store queue
This means that, with SMT enabled, these resources are cut, potentially, in HALF (mind you, these are just queues that impact throughput of a single thread).
3. Memory latency quirks still not worked out.
Gaming can be quite sensitive to memory latency and bandwidth. These issues will be, most likely, remedied with BIOS updates.
Combined you can see, clearly, what is happening and most of the reviews make sense.
A Windows driver update to treat each CCX almost as if it were its own CPU will help immensely. The SMT problem is likely PERMANENT... unless AMD can adjust the partitioning with microcode, which I doubt.
What this all means is simple: once the Windows update has landed, BIOSes are patched up, and SMT is disabled, an 8-core Ryzen will likely be competitive with a quad i7 in gaming while blowing past it in multi-threaded. If all you do is game, then the 1700 may well become a very valid option that will work increasingly better in future games.
This also lets us know where Zen 2 will be able to improve the most. Make the impacted queues competitively shared (or just a little larger), improve inter-CCX communications, decouple the L3 speed from core speeds (for higher core clocks), and a few other relatively simple tweaks and you have a second generation Ryzen that steals the show.
We also know why AMD hasn't released anything other than their 8-core chips - these issues need to be ironed out in production. You need thousands of eyes and testers and numerous companies each responding to their customers' needs to get a grip on what is most important to fix before finalizing Zen 2. 所以又是当年推土机“这届软件不行”的套路？ CCX堆积木这么简单没点代价不可能吧
—— 来自 Xiaomi Redmi Note 3, Android 7.1.1上的 S1Next-鹅版 按照两个CPU调度？按照两个socket/SMP的做法来玩？
看来ZEN也是Cluster-on-Die了 按目前的多线程性能，跨ccx原因可能性比较低
要验证也容易，关掉（只分）一半测 这个猜测挺没道理的~~~~~~要是有这个问题,多线程测试的时候农企早被爆菊了,然而目前情况是多线程农企并不怵啊~~~另外ZEN不是可以随便开关核心吗,两个CCX之间2+2和单个CCX4核心对比测试一次就知道结果了啊 zen 会和k8出tlb补丁一样 性能 会爆发的 KOGmk2 发表于 2017-3-3 12:12
这个猜测挺没道理的~~~~~~要是有这个问题,多线程测试的时候农企早被爆菊了,然而目前情况是多线程农企并不怵 ...
大部分多线程测试根本就不需要线程转移，每个核心都跑的满满的 cloudliu 发表于 2017-3-3 12:23
zen 会和k8出tlb补丁一样 性能 会爆发的
TLB不是K10么，而且刷BIOS补丁之后会降低10%-40%性能 KOGmk2 发表于 2017-3-3 12:12
这个猜测挺没道理的~~~~~~要是有这个问题,多线程测试的时候农企早被爆菊了,然而目前情况是多线程农企并不怵 ...
简单说就是把Bulldozer那套又说了一遍，满线程性能足，线程不满的时候调度有问题 那么搭配Linux使用更佳？ wl5993 发表于 2017-3-3 12:35
简单说就是把Bulldozer那套又说了一遍，满线程性能足，线程不满的时候调度有问题 ...
调度问题那就只能指望巨硬了~~~Mantle和DX12投入实战之后,老FX确实游戏性能提升了不少.......要是只是跨CCX调度有问题,那么玩游戏的时候只用一个CCX再拉高主频也许更实在~~~反正这次农企出了官方工具开关核心+超频 听起来就是线程调度的问题，重载情况下性能比轻载更好。话说有没有Linux平台下跑性能的比较？ 巨硬说是要出补丁对RYZEN优化，但是有多少效果就不知道了 cloudliu 发表于 2017-3-3 12:23
zen 会和k8出tlb补丁一样 性能 会爆发的
tlb patch是粪龙。地雷云你快重新下饵。 我农又要刷脸让全世界迁就他的设计了吧，还是这届软件不行啊。 本帖最后由 ostcollector 于 2017-3-3 13:34 编辑
说起来，为什么 http://www.phoronix.com/scan.php?page=article&item=ryzen-1800x-linux&num=5 里面 ffmpeg 性能如此诡异，6800K不如990X……
还有，在Linux上面有些单线程程序都把4790K和7700K灭了……比如GraphicsMagick，然而Himeno上面被打成傻逼了 在运行单线程程序时，Windows为什么要不断在不同核心上转移线程？ ryzen是第一个我看好测试不知道性能好不好的cpu。 无名的旅人 发表于 2017-3-3 13:29
在运行单线程程序时，Windows为什么要不断在不同核心上转移线程？
说是核心之间的负载均衡，避免单个核心长时间负载比别的核心高 KOGmk2 发表于 2017-3-3 12:12
这个猜测挺没道理的~~~~~~要是有这个问题,多线程测试的时候农企早被爆菊了,然而目前情况是多线程农企并不怵 ...
还真有2+2 vs 4+0的
http://www.mykancolle.com/content/uploadfile/201703/ae6c1488511408.png 瞎猜，线程的调度频率才多少，怎么可能至于到严重影响性能……
starrin 发表于 2017-3-3 14:42
说是核心之间的负载均衡，避免单个核心长时间负载比别的核心高
感觉还是没什么真正的必要性……无论是一个核心长期高负载，还是相对高温，应该都不会有实质性影响才对
从监测软件来看，线程转移是极其频繁的
一开始文中这个说法我是不太信的，结果25L这个测试…… 本帖最后由 华蝶风雪 于 2017-3-3 18:58 编辑
按25L这个，单ccx的r5r3还能提升一点点…
可惜项目少了点，还都是游戏 无名的旅人 发表于 2017-3-3 18:41
感觉还是没什么真正的必要性……无论是一个核心长期高负载，还是相对高温，应该都不会有实质性影响才对
...
Windows 2000时还是固定一个核/CPU，Windows XP开始就是轮流切换了
—— 来自 OnePlus ONEPLUS A3010, Android 7.0上的 S1Next-鹅版 原来8核就是胶水了………原来以为拿波里开始才是。 囧囧囧 发表于 2017-3-3 21:15
原来8核就是胶水了………原来以为拿波里开始才是。
naples是8路32核大胶水 2333333 lumia 发表于 2017-3-3 20:51
那么就是说4核Ryzen不存在这个跨CCX调度问题？
如果是2+2配置的话还是会有，全在一个CCX上就不会 wangh 发表于 2017-3-3 18:39
瞎猜，线程的调度频率才多少，怎么可能至于到严重影响性能……
10ms一次，一秒100次 ostcollector 发表于 2017-3-3 13:28
说起来，为什么 http://www.phoronix.com/scan.php?page=article&item=ryzen-1800x-linux&num=5 里面 ffmpe ...
据国外网友说himeno里被吊打是因为ryzen对FMA指令支持不好 辣摸如何禁用这个什么鬼线程调度？ 有人测了ryzen在win7下的表现，比win10高10~20%。。。喷了
—— 来自 Jiayu S3, Android 7.1.1上的 S1Next-鹅版 草薙·京 发表于 2017-3-5 13:11
辣摸如何禁用这个什么鬼线程调度？
Windows现在有两点需要改：
转来转去时不要从同一个物理核心的线程1转到线程2去
转来转去时尽量在同一个CCX里面转，避免损失L3 Cache里面的数据
但这个超低互联带宽是没救了，某种程度上可以看成双路4C8T处理器，需要L4 Cache+拉高互联带宽才能救 qwased 发表于 2017-3-5 13:16
有人测了ryzen在win7下的表现，比win10高10~20%。。。喷了
—— 来自 Jiayu S3, Android 7.1.1上的 S1Next ...
有人测了draw call理论性能，win7比win10高17.8%
页:
[1]
2