m3 max 和 13900k cpu 性能的简单对比

Intel 这几年一直很拉胯。
等憋大招吧。

希望 amd 和苹果越来越好，有竞争，舒服的用户

wsl io 烂的一笔。。。。

12535 vs 9496 是什么情况

@biglion666 代码文件在 wsl2 文件系统里面，不是在 windows 系统下面。

直接把 win 机器装上 linux 效果会不会好一些

CPU 型号不同，指令集不同，内存不同，硬盘不同，操作系统不同，隔离环境不同，编译的 target 不同。真不知道最后比较个啥……

wsl 标称的性能损失应该只是机器码指令的执行性能。但是系统调用特别是 io 这方面，最终在代码层面多干了不少事，损失很多。就你这个结果来说，不奇怪。但毕竟你这个测试太不严谨，证明不了什么问题。

@biglion666 wsl2 的 io 和实体 linux 是一样的, 除非你跨系统

不严谨的测试，除了黑，哪来的乐子？

@avalon8 不会, 我测试过, 基本一样

@ttvast 这结果是我自己的机器跑出来真实结果，黑啥了？

其实也可以看 GeekBench 平均值附近的结果，M3 Pro 16 核 Clang 得分是 3W8 左右，13900K 得分是 4W1-4W8

理论上应该还是 13900K 要更强的。

装上 linux 再测试看看吧

一个是 12535 ，一个是 9496 ，这是啥情况

根据我自己的经验... wsl2 会经常被调度到小核上去
op 可以编译时开个任务管理器监控一下

和我的实际体验确实也是差不多的.. 之前有几个机器人位姿优化的 c++的 base, 在 m1 pro 在 pd 下都比我的 12900k 快...

@xtreme1 可以的，我下班回看再跑一遍看看。

13900k 有 32 个逻辑核心，但从结果来看只用到 16 个核心；
那不是用 13700 差不多就可以了？

@Cyshall 128g+2t ，这个价格差价能配一台新 windows 电脑出来了，不考虑价格的性能比较不是黑是啥。。。

@murmur #18 捏造事实叫才叫黑啊，但是我没有阿。

1618%。。。16 线程多一点
13900k8 大核 16 小核合计 32 个线程。。。

也就是说 13900k 在仅出力一半而且有性能损耗甚至 build 对象多了三分之一的情况下就能和 m3max 打成了 2：3 。。。

两边都装虚拟机， 设置相同核心数，测一个呗。

我之前有简单测试过 nodejs 的个人自用项目，
12700 64G 3200 频率的 win11 和 m2max 的 mac studio
大致结论是：
1 ，win11 下最慢，
2 ，wsl 下中
3 ，mac studio 最快
非严格测试。

建议两个平台都用 vm linux 测试比较，这样只有架构差异，专治嘴硬

有一个变量没控制好，就是编译输出的目标平台
编译到 x86 和编译到 arm ，它们不是相同的任务

12535 vs 9496 两边编译的文件数量不一样

你这个结果会误导人，如果不是在 v2 已经有一大批人相信你的结论了，所以会有人说你有黑的嫌疑，而不是给自己加个个性化的条件就与己无关了。

楼主你惹怒了果黑...

只有我羡慕 OP 好有钱吗

这个估计是 Intel 大小核的问题，应该加个 AMD 7950X 对比

苹果编译速度确实快，不仅仅是 clang, go 和 java 都是如此

应该用 7950x3D 来比较，大缓存会加速编译。另外别用 windows ，用 linux 。另外别编一天，arm 和 x86 编译过程是不一样的。最后 pc 端的内存应该超频，毕竟这是常规了。

好歹也用 13900k 装个黑苹果试试吧， 就 cpu 的性能来说，在不同的平台的测试结果能说明什么吗？

还好我手里的项目不是你来提需求

Intel fanboy 真多

@blackeepe 一个是 Mac arm ，一个是 Linux x86 可能是架构不一样导致的实现不一样，所以文件文件数量不一样。

@Huelse 就这么几十个字，但凡看完也不至于说我在黑，而且我还解释了 wintel 慢的可能原因。

不懂就问，编译和 io 也有很大关系，wsl2 下的虚拟盘，io 性能会较低吗？

这么对比就不可靠了，文件数量相差三千多，这本身的任务量差距就很大。
最起码的，编译的文件数量要相同。最好是编译的文件完全一样，这样才有意义。

想看 13900k 在黑果下的性能表现

这配置是真羡慕了

为什么对比 CPU 性能是去跑编译算 CPU 时间啊。。。
这不该正经跑点基准么？通用内存在编译场景下的表现的那不比牙膏厂的小缓存高多了

@mjikop1231 普通用户，刚好有设备就顺手跑了一下，没必要太正经。

WSL1/2 挂磁盘来用写 web 开发还能凑合，写 C++与 Rust 项目用 Linux IO 对比一下，WSL2 IO 性能烂到天际，根本是不可用的东西。

一般程序上遇到的性能问题瓶颈都是 io ，wsl 同样

确实对于类似使用似场景的人是有意义的。编译是个 cpu 和 IO 密集型的任务，wsl2 还是需要 drvfs 去转换 IO 到 ntfs ，带来的损失在这种场景下是不能忽略的，肯定跟 macos 的原生文件系统有差距。

大冬天的，M3 这种几十 W 的能用吗？
13900K 400W 暖风机不香吗，老寒腿都治好了。

M3 开春再说（逃

没懂怎么有人会对这个结果激动？
我看标题和写的内容，也没啥过激的情况，而且 OP 也特别提到了，这是他日常使用的 2 台机器，只是做个日常使用对比而已。

和我日常感觉一样，mac 上编译项目比我 windows 台式机要快

@shimanooo 真的，13900K + 4090 + 4k 160 显示器，打开大型 3A 游戏，画质拉满，分辨率拉到 4k ，运行半个小时左右，机箱周围要高 4 度左右。

这种东西自己知道就好 放出来 只会能让一部分人不适
这还是在 V2 放其他地方早就开始成群结队 哄堂大笑了
最终就是引战

楼主，输出的二进制文件不一样也能比的吗

@TOM2333 说错了，输出的文件是一样的吗

m3 的内存延迟比 intel 快太多，一个是芯片内访存，一个要在主板上绕一圈，，，

其实结果并不意外吧，毕竟 m3 max 的规格比 i9 高很多，内存延迟也低些，即使严格条件下 m3 max 也应该好点

@TOM2333 额，首先一个 mac os arm 系统，一个 Linux x86 系统，编译出来的文件肯定不一样，但这属于显而易见的事情，所以有点不明白你的意思。

制品链接很耗内存。

测试很有意义，希望苹果赶紧支持 windows 系统的安装，我已经忍不住了

@Cyshall 就生成 arm 下的二进制和生成 x86 的二进制的工作量显然是不同的，作为性能比较最好编译到相同的目标

@Cyshall #55 编译器中，x86 的优化器和 arm 的优化器完全不是一个水平的，x86 优化器进化了这么多年，相当相当复杂了

13900k 只用了一半核，就能和 M3 平分秋色了。

买 M3 的人真惨。

@wwthappy 放 wsl2 ext 文件树里跟 ntfs 有什么关系

如果 LZ 的工作就是基于 clickhouse 做二次开发，那我认为这个比较没问题，在这种使用场景下确实 Mac 具有更好的体验。如果是原生环境，我相信 13900k 的表现不会这么拉垮，但可惜 clickhouse 不支持 Windows 开发，而 Linux 桌面的使用体验只能说差强人意。不过这个对比也可以从侧面说明 wsl 并不是最好的 Linux 发行版

https://www.reddit.com/r/rust/s/C0TF99l2xM
13900KF 19.39s
M3 Max 18.05s

@Granthese 13900KF *29.39s

这帖子就叫做真相真的是很伤人

你这测试一点不科学啊。。图一乐

@YsHaNg 当然有关系，实际上是 NTFS 上的 VHDX 文件里的 EXT4 文件系统。
大多数虚拟机的运算性能其实都不错，不过虚拟机的 IO 性能就没那么好了。

WSL2 还有另一种情况，把整个物理硬盘挂在到 WSL 里面。这样会好不少。

m3 max ,我好羡慕，m3 max 128G 的价格太贵了。。intel 的 128G 只要不要 1w
虽然我觉得 intel 的 cpu 真的很垃圾，那个 200w 的 i7 13700k 和我的 m1 max 差不多，但是扛不住人家内存大

@laminux29 第一句话没问题，13900k 的绝对性能肯定不差，但是大部分软件根本无法利用好这么多核心，所以就结果来看，M3 Max 更胜一筹。

@Cyshall

这是软件的问题，这不是 CPU 的问题。不要本末倒置。

如果真要比，应该拿那种能跑满所有核的专业跑分软件，在双方都是顶配的情况下，来进行测评。

@Cyshall 大多数真吃性能的专业软件还真能最大限度地利用每一个核心……
日常生活中碰到的无法充分利用多核的场景反而是游戏。

上面的有个链接里的帖子其实还给了一组数据，同一台电脑，不同系统：
Asus G15 | 6900HS | Ubuntu 22.04: 1m 20s
Asus G15 | 6900HS | Windows Native: 1m 08s
Asus G15 | 6900HS | WSL-Ubuntu 22.04: 2m 08s

造成 Windows 和 Linux 下的差距的原因，是两个平台下编译的代码内容其实也不相同。有些代码分支或者依赖只用于某个平台。

如果算上编译输出 x86 和 ARM 指令集的差异，不相同的地方更多了。

除此以外还有编译器实现的差异。

这种对比，其实只能说明特定软件用某个编译器，在特定平台编译到特定目标所需要的时间，无法得出一个适用于其他场景的通用结论。

7945HX ，64G+2T ，archlinux ，顺手跑了一下 clickhouse 的编译，clone 最新主线之后直接 cmake 然后 ninja -j 32 ，忘了加 time ，有没精确到秒，不过大约从 3:15 开始到 4:41 ，大概二十六分钟的样子完成。

标题是 m3 max 和 13900K 的对比，实际负载一个跑在实体，一个在虚拟机，这对比本身已经比较离谱了，怨不得别人说你黑。我这个跑分只能跟不超频的 12900K 打的 7945hx 都能 26 分钟编完，我这内存频率还算比较低的，13900K 得接近 40 分钟？多花了 50%以上的时间？显然你的打开方式没能吃满性能，跟 clang 没啥关系，C/C++的编译器多核优化都不错的，你就算拿 64 核的 7995wx 来测，时间消耗的差距不说是线性的，快一两倍总还是有的。如果你坚持 wsl 来编译，当然测试结果对你有意义，但是这不是这两款 CPU 的性能对比。

最后，clang 再怎么跟苹果有优化也不至于这么离谱，更何况 geekbench 测试中直接就有 clang 子项，这对于性能估算十分具有参考价值。geekbench 还是被人戏称为 applebench 的跑分软件，在这个软件的跑分中，m3 max 和 13900K 的 clang 子项都没什么明显的差距，都在 4 万分左右。你这个 i9 的编译速度，大概率是别的原因，不是 clang 的原因。

@squarefong17 我今天又用 wintel 跑了两次，快了三四分钟吧，cpu 方面就刚开始的时候会 32 核心吃满，后面就只能吃到一半核心的样子，不知道是不是 wsl2 的问题，你编译的时候全程 32 个核心吃满了吗？

@Cyshall 我这后半段也有好长时间没吃满 32 线程。这一段似乎什么 asm 的编译？

ubuntu 下编译能吃满：
[12728/12728] Stripping clickhouse binary
ninja 44531.85s user 2145.34s system 3157% cpu 24:38.12 total

补一下我的配置和环境，机器是 nuc13 extreme ，13900k + 96g ，ubuntu 22.04 ，llvm17 。nuc 的性能相比同配置的台式机会略弱一点。

指令：
cmake -S . -B build
time cmake --build build -j 32

结果：
[12728/12728] Stripping clickhouse binary
cmake --build build -j 32 44499.11s user 2132.85s system 3160% cpu 24:35.45 total

@Cyshall 是的，待机差不多 30-50w 之间。nuc13 最高 250w ，然后我在 bios 里面设置了 pl1 持续 192s ，之后功耗限制在 200w （放在隔壁，冬天不开空调，温度在 80 度左右）

@annieguo 你这里的 80 度是 cpu 满负载的情况吗？

@kneo 为啥要管指令集内存硬盘，mac 和 win 都是开发使用，直接测试自己开发环境情况下哪个更有效率才是目的

@s1461a 作为一个苹果用户，说出“我不管”没问题。但是作为一个程序员，这么说我认为是挺没面子的。

@kneo 不结合实际情况，而单纯考虑跑分更是不负责任的。

@s1461a 啊？不结合实际情况？你说的是前面那个“为啥要管指令集内存硬盘”这种人？

@kneo 实际情况表达有误，是实际使用情况。楼主使用 windows+wsl2 和 macbook 对比，然后得出了再 clang 下使用效率。你在意的是两个 cpu 内部哪个更优秀，我在意的是我用 win+wsl2 台式和 macbook 日常使用差距多大。更像是你抛弃了系统对软件的优化，从这个角度而已，你只是在关心硬件，但使用电脑工作不仅仅只是硬件，你脱离系统跑软件？

@s1461a

首先，你说你在意的是“win+wsl2”和“macbook”，但是 op 标题写的是“CPU 对比”。先搞清楚别人在讨论什么。

如果你说自己在比较特定型号机器，在特定运行环境下，执行特定任务的结果，并且，你只在乎这个任务的结果，OK 。

但凡这些条件你换一个，比如同样的运行环境比较，你并非运行 clang 执行编译任务，而是使用 nodejs 运行一个 web 服务器，这个比较结果就没有参考意义。

你说别人在乎“硬件参数”这有点离谱了。我只是指出方法中的问题。我在意的的是科学的思路，工程的方法，然后对海量信息垃圾进行一个标记。难道和我不同，你在这里得到了什么结论？你口中的“系统对软件的优化”，请问哪个系统对哪个软件有优化？证据是什么？技术是什么？别给我整一句“macbook 系统对日常开发使用有优化”，那我可要笑死了。

最后，我不知道你哪冒出来的，逮个人就一口一句“我在意的是”“我在意的是”，是你自己跑过来挖坟的，没人在意你在意什么。有效信息才会被别人在意。op 和你的回复，都不是有效信息。特此标记，恕不回复。