数框框时间到~

😭 A770亮机卡计划失败了，进KDE wayland就花屏。只能暂时用7800XT先顶着，改天再研究Intel。

Threadripper 7000系列动任何跟OC有关的设置(PBO/任何主频/任何电压/内存频率和时序）都要熔断fuse并且永久丢失保修。AMD这是跟三星手机学的吗……

我就说怎么华硕这TRX50主板默认配置这么符合POR规范，原来是主板厂商BIOS自己也动不了任何东西，笑死。

Lessons learned: Intel GPU不要开DSC……

TRX50是我过去两百年内见过的内存效能最高的平台。4通道DDR5-5200B JEDEC内存，理论带宽166G，实际跑出>150G的读取吞吐，效率超过90%

对比之前AM5的测试不难看出，两倍的内存通道和CCD 在同频下跑出了>2.2倍的内存带宽，根本不需要任何OC就能跑出AM5永远达不到的效率…只能说AM5的UMC完全是个笑话。

多核感觉测了等于没测😅

502.gcc_r以及505.mcf_r这俩比较吃内存带宽的测试在AM5 Raphael上表现还是一如既往的烂

测Meteor Lake的LP E-core能效是个很折磨人的事情，仅次于之前测手机的Cortex-A5x/A5xx。。跑的太慢了，测一个频点的时间相当于测大核3个频点🙃

Meteor Lake (155H)中低频能效进步比较大，比我预期还强点。单核10W内相比13700H中频提升>20%性能。

不过这并非公平对比。13700H用的是DDR4内存，155H的LP5X以少量绝对性能为代价换取低功耗的优势。

当然……拿去跟Apple或者AMD去比则是完全不行了。其它核心的曲线还在跑，明天发完整版。

4种核心的性能倒是可以先更新。即便排除内存敏感的子项，Meteor Lake的IPC也是大多倒退的。

MTL的低功耗做的相当不错，E-core 5W以下比7840U低几百mW，轻负载大概是6800U水平。

E-core终于拿掉刷分核的帽子，全频段能效战胜P-core，可以当正经“能效核”跑到死不怕拖累能效。

LP E更像是低功耗待机核，为了快速响应事件设计而非运行任何实际的负载。等compute tile唤醒之后就可以摸鱼睡大觉了。

不知道我前段时间吐槽Raptor Lake时试图说服我E-core的“E”可以指“Area efficiency”而不是“Energy efficiency”的网友现在有何感想？

本来还想着给155H装Windows跑LP E-core看是不是Linux下的能效有什么问题，不过这个……看一眼就知道不用多测了吧。

观测了Windows下拔电后MTL LPE核的行为，看起来是极轻度负载时（比如10秒以上不动鼠标）会关闭ring上所有核心，此时后台进程会跑在LPE上。一旦有持续上百ms的负载，则会重新激活普通的大/小核。

猜测彻底关闭后重启ring会有一定的延迟，这个时候需要靠LPE扛住负载。一旦ring启动完成，LPE就失去价值了

所以评价LP E-cores的能效也不能简单的看高负载的动态功耗/能效曲线，而是应该想办法对比漏电功耗以及从不同状态下(CC1/CC6)核心回到CC0的响应延迟。

玩了一把Intel的NPU，能跑HLSL挺有意思的，只是DML demo里面跑DML定义的算子发现一个都不支持是咋回事呢……

Preview啊，那没事了……

amd平台，内存读取怎么比写入低这么多？

关于Zen4使用aida64测试写入的带宽偏高的问题：aida64的代码触发了zen4的写入优化功能，使用non-temporal store指令反复写入相同内容有一个类似压缩的机制，所以可以超越GMI的理论写入速度，有些情况下甚至单核就能跑满内存带宽。这一点用第三方开源工具也能复现，目测是为了优化memset()之类的之前会被GMI写入减半的设计卡脖子的场景。

Zen4 HEDT平台还能跑出相当夸张的数字，比如单线程110GB/s带宽。右边是用脚本读取MBM监控内存带宽实际使用量，以此证明不是测试写出了问题，而是真的跑出了这个带宽。