如何看待M1 Ultra Cinebench跑分单核落后i7-12700K 19%，多核超i7 3%？

M1 ultra只是增加了核心数量，没有提升核心的性能。

英特尔10nm，大致有台积电7nm的水平。

苹果在这个工艺下，拿出来的东西是A12

2.66ghz主频，gb5跑1000分左右，单核心4w左右的功耗。

英特尔只有大核心产品是i3 12300，烤机开了超线程，四个核心8个线程60w。

4.4ghz单核大约跑1600分左右。

单位频率性能差不多，英特尔如果做低频低压，功耗也未必高多少。

3月18日更新：

M1 Ultra解禁了，R23比题主说的高一点，24169。也没高到哪去。比12700K提升从3%变成了5%，其实也没差多少，打不过12900K是肯定的了。就看12900K降频到这个成绩是多少功耗了（预计100w左右）

Blender 3.1.0看了BMW和Classroom的成绩，基本和R23差不多。

3月12日更新：本来想测试一下Embree 3.13与Embree 3.12的区别，因为Github上标着3.13.0开始支持M1，不过等我仔细看了一下3.13.0与3.12.2的区别才发现，Embree3.13版本以前连SSE2NEON都是没有的。

也就是说，Embree在3.13以前是不支持ARM的，去年4月份才开始支持ARM，而支持ARM的一个更改就是引入这个头文件。直到目前的最新版本3.13.3都还是用的SSE2NEON的形式。所以别幻想什么R25能有什么改进。Cinebench R23应该是自己定制了Embree实现了对ARM的支持，而blender用的是3.12版本，也是自己做的支持。不是通过官方的更新去支持的。

我发这个的目的，是因为果粉喜欢找理由，跑不过的就会找各种各样的理由来洗。绝大多数理由，都是指责软件优化不好。比如handbrake，直接给FFMPEG和X264/X265扣上不支持ARM的帽子。

分割线—————

Cinebench R23的跑分分析知乎上有很多回答了，请参看这个回答，非常详细的分析了Cinebench R23中的指令占比

其中，浮点指令中256位的AVX指令占据了绝大多数，而SSE仅占了一点点。总体的浮点指令占比仅为16%左右。

那么我们今天就来分析分析，一些果粉宣传的SSE2NEON会不会影响性能发挥。

SSE2NEON究竟是什么？它其实是一个头文件，全部的源码就只有一个sse2neon.h，它开头的注释里这样写道：

This header file provides a simple API translation layer between SSE intrinsics to their corresponding Arm/Aarch64 NEON versions

也就是说，它其实使用的是NEON的intrinsic函数，去重写SSE的intrinsics函数，以实现SSE的功能。别有用心的人抓住了translation一词，粗暴的定义为“转译”，让人误以为这是类似罗塞塔或者微软那种二进制翻译。实际上我更认为这是一种API封装，或者是一种代码迁移，通过将库函数迁移到ARM，实现针对NEON的适配。

那这些intrinsic函数是怎样的呢？我们来看看。下面是一个换位指令，SSE的一个函数可以直接把数据的高位和低位拼接成一个结果，NEON似乎没有这个指令，因此，程序员先把低位的指令和高位的指令用NEON的函数取出来，再拼接成结果，用了三条NEON指令来代替实现了一个SSE指令

       // Takes the upper 64 bits of a and places it in the low end of the result // Takes the lower 64 bits of b and places it into the high end of the result. FORCE_INLINE __m128 _mm_shuffle_ps_1032(__m128 a, __m128 b) { float32x2_t a32 = vget_high_f32(vreinterpretq_f32_m128(a)); float32x2_t b10 = vget_low_f32(vreinterpretq_f32_m128(b)); return vreinterpretq_m128_f32(vcombine_f32(a32, b10)); }     

这是没有NEON指令实现shuffle的情况。但是大多数的单精度和双精度浮点指令实际上是这样的。

       // Adds the four single-precision, floating-point values of a and b.a //   r0 := a0 + b0 //   r1 := a1 + b1 //   r2 := a2 + b2 //   r3 := a3 + b3 // // https://msdn.microsoft.com/en-us/library/vstudio/c9848chc(v=vs.100). FORCE_INLINE __m128 _mm_add_ps(__m128 a, __m128 b) { return vreinterpretq_m128_f32(  vaddq_f32(vreinterpretq_f32_m128(a), vreinterpretq_f32_m128(b))); }     

这是一条计算指令，加法，也就是简单的基础指令，一条SSE指令在NEON里直接有对应。

再看按位与

       // Computes the bitwise AND of the four single-precision, floating-point values // of a and b // //   r0 := a0 & b0 //   r1 := a1 & b1 //   r2 := a2 & b2 //   r3 := a3 & b3 // // https://msdn.microsoft.com/en-us/library/vstudio/73ck1xc5(v=vs.100).aspx FORCE_INLINE __m128 _mm_and_ps(__m128 a, __m128 b) {  return vreinterpretq_m128_s32( vandq_s32(vreinterpretq_s32_m128(a), vreinterpretq_s32_m128(b))); }     

再看Load

       // Load 4 single-precision (32-bit) floating-point elements from memory into dst // in reverse order. mem_addr must be aligned on a 16-byte boundary or a // general-protection exception may be generated // //   dst[31:0] := MEM[mem_addr+127:mem_addr+96] //   dst[63:32] := MEM[mem_addr+95:mem_addr+64] //   dst[95:64] := MEM[mem_addr+63:mem_addr+32] //   dst[127:96] := MEM[mem_addr+31:mem_addr] // https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_loadr_ps FORCE_INLINE __m128 _mm_loadr_ps(const float *p) { float32x4_t v = vrev64q_f32(vld1q_f32(p)); return vreinterpretq_m128_f32(vextq_f32(v, v, 2)); }     

这是这个文件里的大多数的情况，基础的加减乘除，逻辑运算和load/store指令，都是一一对应的，NEON没有的情况是比较复杂的功能，例如上面的shuffle指令，两个源操作数的高位和低位分别取出来拼接成结果。也就是RISC的逻辑：一条指令的功能非常复杂，需要许多精简指令的序列来代替。

在程序中，我们已经很少直接编写汇编语言了，而是使用这些intrinsic函数。换句话说，实际上SSE2NEON的功能，是汇编层级的直接转换，原自于程序员的手工编写优化的代码，而不是罗塞塔或别的什么搞自动翻译。API封装所带来的函数调用开销被force in-line消除了

那么损失唯一有可能的来源是什么？就是是否这种写法，在NEON看来不太好，需要更换，这种情况在于，NEON提供了SSE中没有的指令，需要利用这些指令重写算法？

带有这种想法的人，他的用意很险恶，更高效的方法可能会有，但那样基本等同于更换算法。我的算法使用了一些由CPU提供的功能来加速，另一些CPU没有提供这些功能，于是另一些CPU的粉丝要求开发者换算法。重新研发一种算法。不同算法的效率本身就可能差异很大。更没有任何可比性。

多么简单的一件事情，在FORCE_INLINE强制内联以后，SSE函数实际上已经不存在了，那么问题来了，实现同样的功能，NEON凭什么比SSE慢？带节奏的人为什么不回答这个问题呢？

事实上就算SSE没有，AVX也会有。因为AVX比NEON新得多。并且，AVX可以实现SSE的几乎所有功能，先不说Cinebench R23中绝大多数浮点指令都是AVX指令，不可能也不会使用SSE2NEON。如果大家都要求换算法，那Embree直接全部淘汰SSE，转向AVX等更现代的指令呢？

有些说想看结论，其实只要对比一个良好优化的程序和Cinebench的结果就很容易破解这种谬论。来自极客湾测试的两个结果，一个是疑似使用”转译“的R23，另一个是基于老牌跨平台编解码器x264/265的Handbrake，x264/265采用手工汇编来优化适配各个指令集，不存在”转译“的情况。前者是浮点，后者则是整数。

其实可以看到，在h264/265的转码总时长上，i7 12700H领先M1 Max 41.5%，Cinebench R23则领先40.8%。基本相似。11800H的视频转码领先幅度为16.2%，还高于R23的10%不少