由于疫情的缘故，被困在魔都已经五十多天了，困着就想摸鱼，再加上物流不通，因此很多测试都未能顺利进行，不过还是趁着被封控的功夫做了一点有意思的测试。
内存子系统，是CPU中的重要组成部分，它的缓内存配置，与CPU的实际性能直接相关。
在很多场景中，单线程性能往往使用Latency Performance（延迟）表示，而多线程性能则习惯性用Throughput Performance（吞吐）表示，这实际上揭示了不同侧重性能对内存子系统不同方向上的要求。
因此合理的配置对其性能的好坏具有极大的影响，在这里，我们将基于Alder lake系统，来阐述Latency/Throughput对性能的影响。
这边我们使用的测试环境如下
CPU:
Intel Core 12700K，其中P core固定在5.0 Ghz全核心，以避免由于多线程turbo影响频率，从而在影响多线程的效率计算。类似的，E core被固定在3.8 Ghz全核心。
总线频率被固定在了4000 Mhz，这主要是为了避免由于开关E core导致的ringbus频率变化从而影响测试结果。
DRAM:
这里我们使用的是芝奇的4000CL19的皇家戟，容量为2*16 GB。
具体设置为4000CL16-16-16-32-320-65535，Gear1模式。
OS：Win 11/WSL2/Ubuntu20.04
我们首先对该系统的内缓存的延迟情况进行了相应的Full random latency测试，并标出了对应的一些重要节点。

在Alder lake系统中，我们同时对P/E的内缓存延迟进行了相应的测试。
可以看见在E core的cache中，实际上有一些比较重要的延迟变化情况，在比较重要的几个变化点在L2与L3中。
其中影响比较大的系192KB与512 KB位置，前者超过L1 TLB的cover范围，因此从这个点开始latency将有所增加，而后者则是L2从private过度到4C shared的部分，因此这个点之后的latency也会略有变化。接近的情况也出现了L3中，只不过由于L3（LLC）系全核心shared的部分，故不存在由于缓存性质导致延迟变化节点。
E core的内存延迟大约在79ns左右，系256 MB处的测试情况，实际上我们测试过1 GB附近的情况，延迟也大概在80-81ns左右，因此这里我们标注了79-81ns，对应的cycle数大约为300-308左右。
类似的，我们也对P core的情况进行了相应测试，其内存延迟大约在59-62ns，其中59ns在256M处取得，62ns则约在1 GB处取得，对应的cycle数大约为296-309左右，可以看见其与E core的内存延迟在cycle层面实际上是相差无几的。
Latency ns=cycle/frequency。
值得注意的是，从E-core访问L3的速度似乎比从P-core访问来的更快，快大约10 cycle。