David's random thoughts – Telegram
David's random thoughts
1.73K subscribers
268 photos
1 video
29 files
173 links
个人想法合集,主要同步来自Twitter (𝕏)、知乎、博客等账号发布的内容。

注:本频道并非纯粹包含技术相关内容(虽然以它们为主),本人不会刻意回避政治观点表达。可能包含一些直言不讳的主观评价,慎入。

个人博客:https://blog.hjc.im
Download Telegram
M4 Pro Geekbench 6.3 vs 6.2.2: https://browser.geekbench.com/v6/cpu/compare/8846063?baseline=8845664

其它成绩也更新在了GB个人主页。
👍3
M4 Pro的SPEC多核,核心功耗从25W到60W不等,package功耗不明。图1/2两个报告是纯大核的10线程和大小核14线程,分别略低于55W/88W package功耗的9950X。

比较亮眼的子项有gcc和mcf,这两项和内存带宽强相关所以AM5自然性能是一坨;比较差的子项有perlbench和xz以及古典AI三项,其中有几个比较喜欢SMT
3
M4 Pro vs 9950X的同核心数的多核能效(开/关SMT)
🐳4
M4 Pro跟自家3年前的M1 Max比,同样8线程运行SPEC int测试性能提升35.5%,如果算上核心数增长就达到了惊人的67.4%。

不过10大核版本的M4 Pro运行8线程测试并不会平衡到两个P cluster 4+4调度而是会先把一边填满形成5+3,所以可能会略低于同参数的8大核版本的分数。
2
笑了,M4 Pro拿UTM/qemu开个linux虚拟机随手跑了下548结果发现比macOS host跑的还高
😁412
图1: Linux vs macOS 默认malloc
图2: Linux vs macOS 统一jemalloc

均为手动拉满风扇。统一malloc必要性还是很大的,Linux在纯核心瓶颈的场景下表现略好,但是macOS libmalloc帮大忙让520 523绝杀。这个现象在M2上还不够明显,但是M3之后为了拉高频率大幅度放松L2时序,可能使得malloc的重要性增加。
👍11🤔1
Linux下nvidia和amdgpu有criu支持,不过我好像还没见过谁把它用在游戏图形应用上

https://www.zhihu.com/question/456048017/answer/34367726593
2
有趣的OS小细节:Linux使用4K页面并关闭THP时,由于内存映射粒度是页面所以无法触发Zen的TLB聚结,TLB覆盖范围是4K*entry。但Windows下由于粒度是64K所以可以正常观测到等效16K页面的TLB覆盖,未来理论上硬件还可无缝扩展至更大的64K。这也是近年来我见过的为数不多的Windows比Linux性能表现更好的地方
19😱3
M4 Pro E-core @ 2592 MHz,uncore拉满的情况下SPEC17 int性能可以来到5.17分。如果不动uncore则是4.42分(从omnetpp的成绩来看目前榜上那个M3 Pro的E-core应该也是没有拉高uncore的)

这一代的E核频率略下降(2.6 vs 2.75 GHz),IPC略提升,最终性能与M3 Pro的E-core接近。

感觉不如Skymont(逃

Geekbench 5/6分数也更新了:https://browser.geekbench.com/user/391511
2
测试M4 Pro 大/小核心的访存延迟曲线

L1d: 大核128K,小核64K,均为3周期(非简单pointer chase则4周期)
对4.5 GHz的大核来说,不论是绝对延迟、周期数还是容量,它L1性能都站在处理器的顶端

L2: 大核16+16 MB,从27(近)到90+(远)周期不等;小核4MB 14-15周期。大核L2从带宽上更容易理解结构
M4 Pro的单线程带宽,以及对比x86。与延迟测试不同的是,在带宽测试里我们很容易看出单个核心可以全速访问两个P cluster所有32M L2缓存,带宽基本维持在120 GB/s附近。

除此之外也比较容易发现Apple相比x86目前大优势在于128bit SIMD吞吐。Zen5需要256/512bit SIMD才能使得每级缓存发挥出全部实力。
最后是多核心,本代M4 Pro使用单cluster 5核心纯读取可以跑出220+ GB/s内存带宽,不再有M1年代单cluster带宽限制。这可能是P cluster现在不仅可以使用另一个P cluster的缓存,也可以通过另一个P cluster的data path来读写内存

3个小核内存带宽大约是44 GB/s (单核32GB/s),cluster级别瓶颈比较明显
因此今天的8700G、5600G以及笔记本AI 9 HX370、8845H这些,其实都不能叫APU——一来它们的GPU在闲置时起码也要分走512MB(早一点2200G好像可以只占64MB)的系统内存;二来它们的GPU最大也只能访问到一半的系统内存,不能全部


Linux + ROCm环境下APU的GPU可以访问全部内存空间,不需要预先分配显存,也没有一半内存容量的限制(因为不走GTT而是走Linux HMM框架分配内存的UMA)

比如我拿32G内存、预留512M显存的HX 370来跑32B 4bit模型,单模型本身就占用了超过16G内存,但是依然可以被GPU访问到并且跑出符合预期的推理性能。

https://www.zhihu.com/question/4693494927/answer/38232206295
🙃 Linux 6.12好不容易等来一堆期待已久的功能和fix,结果发现smb cifs又被搞炸了
😁28🤡4
USB4兼容性现状:以下4台机器任选两台出来组合,均无法使用USB4/雷电以太网

台式机Intel JHL8540独立主控
Mac Mini M4 Pro 雷电5
AMD Rembrandt (7735U)的原生USB4 (Linux)
AMD Strix Point (HX 370)的原生USB4 (Windows)
😇26🤡4
悲报:M4 Pro的HEVC编码器画质相比M1 Max几乎没有任何变化😅
🤣331👍1
llama.cpp的server终于引入了speculative decode,现在我日常用的qwen 72B q8性能达到了>20 token/s😃

https://github.com/ggerganov/llama.cpp/commit/9ca2e677626fce759d5d95c407c03677b9c87a26

配置参考: llama-server -dev ROCm0,ROCm1 -devd ROCm2 -t 24 -c 65536 -cd 65536 -m qwen2.5-72b-q8.gguf -md qwen2.5-1.5b-q4.gguf -ngld 999 -ngl 999 -np 4 -sm row -ts 1,1 -cb -ctk q8_0 -ctv q8_0 -fa --draft-max 4 --draft-min 1 --draft-p-min 0 --samplers "temperature;top_k;top_p" --temp 0.1 --host 0.0.0.0 --port 8000
👏8👍4