CCX互连
如果你读过Ryzen的架构解析，你就知道：Ryzen的L3不是真正的general-purpose cache通用缓存，而是victim cache。
Victim Cache是特殊的一类缓存。如果从更低一级缓存上有被驱逐的数据，它将被放进victim cache。然后和通常缓存一样工作，直到有数据需要从中提取，此时victim cache中的数据将与更低一级缓存中的数据进行交换。
Haswell的变种Crystal Well/Broadwell上搭载的L4就是victim cache，被CPU和iGPU共享。
Crystal Well的L4结构过为复杂，因此后来Skylake上换回了普通的缓存。
法国媒体的测试结果22GB/s并不是AMD给出的官方数字，只是单方面的猜测。
大多数媒体只看到了22GB/s，而并没有看到这是个假设
更没有看到假设前提：尚不确定Data Fabric提供的带宽是怎样分配，L3和内存的优先级如何。
一切都不清楚，没有官方解释的情况下就妄加猜测或者说肯定绝对是不对的。
并且当前版本AIDA64测得的数据有问题，AIDA64表示将在后来的版本中进行修复（刚更新的版本也没有修复）。
而在上面已经说到，DF频率为RAM的一半，提升内存频率也会提高DF的带宽。
假使最差的情况，带宽真的只有22GB/s，会如何呢？
L3是CCX的victim cache，和Intel不同，不要拿来随便比较你是架构师吗。
那么你需要多少带宽呢？正好就是72bit ECC DDR4的带宽。2400MHz下22GB/s的带宽已经足够。
问题主要会出现在：
1.某个线程需要8MB以上的L3时。比如如果CCX0中某个线程需要12MB的L3，但另一半4MB L3位于CCX1中。同时发送请求，但需要等待CCX1中的数据。
2.Windows经常切换线程负载，不管数据在缓存的哪个位置。对于Intel和AMD的老产品没问题，因为都是共享L3。
这些问题，虽然有架构本身的限制，但可以通过软件优化在很大程度上解决。比如AMD和微软正在开发补丁解决线程调度问题。这能够给游戏带来很大提升。
在Crystal Well上的L4，Linux的内核+驱动更新后，也提升了一倍性能。软件和系统等优化占有很大地位。
如果你读过Ryzen的架构解析，你就知道：Ryzen的L3不是真正的general-purpose cache通用缓存，而是victim cache。
Victim Cache是特殊的一类缓存。如果从更低一级缓存上有被驱逐的数据，它将被放进victim cache。然后和通常缓存一样工作，直到有数据需要从中提取，此时victim cache中的数据将与更低一级缓存中的数据进行交换。
Haswell的变种Crystal Well/Broadwell上搭载的L4就是victim cache，被CPU和iGPU共享。
Crystal Well的L4结构过为复杂，因此后来Skylake上换回了普通的缓存。
法国媒体的测试结果22GB/s并不是AMD给出的官方数字，只是单方面的猜测。
大多数媒体只看到了22GB/s，而并没有看到这是个假设
更没有看到假设前提：尚不确定Data Fabric提供的带宽是怎样分配，L3和内存的优先级如何。
一切都不清楚，没有官方解释的情况下就妄加猜测或者说肯定绝对是不对的。
并且当前版本AIDA64测得的数据有问题，AIDA64表示将在后来的版本中进行修复（刚更新的版本也没有修复）。
而在上面已经说到，DF频率为RAM的一半，提升内存频率也会提高DF的带宽。
假使最差的情况，带宽真的只有22GB/s，会如何呢？
L3是CCX的victim cache，和Intel不同，不要拿来随便比较你是架构师吗。
那么你需要多少带宽呢？正好就是72bit ECC DDR4的带宽。2400MHz下22GB/s的带宽已经足够。
问题主要会出现在：
1.某个线程需要8MB以上的L3时。比如如果CCX0中某个线程需要12MB的L3，但另一半4MB L3位于CCX1中。同时发送请求，但需要等待CCX1中的数据。
2.Windows经常切换线程负载，不管数据在缓存的哪个位置。对于Intel和AMD的老产品没问题，因为都是共享L3。
这些问题，虽然有架构本身的限制，但可以通过软件优化在很大程度上解决。比如AMD和微软正在开发补丁解决线程调度问题。这能够给游戏带来很大提升。
在Crystal Well上的L4，Linux的内核+驱动更新后，也提升了一倍性能。软件和系统等优化占有很大地位。
16楼2017-03-05 18:51收起回复
关键是没主板。。。
爱迪课
