M1不仅是性能怪兽，主要改变了长久以来的两个观点

Arm笔记本早就有了，然并卵

发自「今日水木 on SM-G7810」

你不知道之前apple的笔记本用的power芯片吧

所以还是工艺问题，以 Power Mac G5 为例，晶体管数只有 intel core duo 的十分之一

其实当年G5的性能不差，但发热大，只能用在台式机上，笔记本上没法用

ibook和powerbook只能继续用G4

看了下当年的测试对比文章，PowerMac G5 2.7G双核

比同期的Xeon 3.6G双核，3.6G双核奔4，2.4G AMD 4000+都要强的

1并不成立。。。

现在的x86cpu前端有个指令译码器，将x86指令转换为微指令，微指令的执行架构虽然不是纯的RISC，但执行方式和效率都非常接近RISC

然而现在译码器成为了瓶颈，这就是x86一直避实就虚的地方。

什么超线程，本质上不是译码器效率跟不上微指令执行单元吗？

译码器不但要占用额外的DIE size，额外的功耗，还带来了额外的延迟和复杂性。

再加上x86沉重的历史包袱（实模式+32位），这一大堆损耗加起来可是够喝一壶的。

苹果打破的就是你这种落后的认知啊，当精简指令集用同样的工艺堆电路并且甩掉

各种历史包袱以后，性能是可以超越复杂指令集的。

你理解错了啊。。超线程本质上是因为 CPU 访问内存速度比较慢，在等待时，可以把 CPU 腾出来执行另外一个线程的指令。

ARM 不喜欢用超线程，可能是因为手机、平板这些低功耗设备，没必要搞 16 线程，反正早就普及八核用不完。

貌似是你理解错了多线程和超线程？

访问内存慢不是有两个应对么？一个是流水线+分支预测，一个是靠软件且到其他线程、进程执行其他玩意？

超线程是一个微码核心对应两个译码器，本质上是译码器太慢了

苹果比较特别

高通的arm在苹果a7的时候就已经进入挤牙膏了

Arm关键不是性能问题，而是生态问题

发自「今日水木 on SM-G7810」

访问内存慢目前主要是用了缓存来应对的。但就算是缓存，也慢啊。l1/l2我记得是一个周期以内，而 l3 就得三四个周期，访问一次内存就得几十个时钟周期（好像是 20-50，具体忘了），CPU 电路在那边干等着，不如去执行另外一个线程。访问内存，就好像高级语言的磁盘IO，阻塞在那里，操作系统就会调度另外一个线程。CPU 也是类似的原理。在这方面， RISC 和 CISC 并没有太大区别。我记得 IBM 正在生产的 RISC 就有超线程，而且还是一个核心四个超线程？

AMD64 微架构里面，译码器只是 CPU 电路里面很小的一部分，基本上没人关心。从来都不是瓶颈。

时间能弥补

相当于一片新的蓝海，程序员会冲进去的

不是……指令解码只码是前端的功能

前端部分的晶体管数应该只占总量很小的一部分，这也是为什么一直说 x86 实际用的是微指令集，risc/cisc 根本不重要

超线程是一个物理核虚拟成两个逻辑核，使用相同的物理核的资源，其中一个逻辑核处于等待的状态的时候，另外一个逻辑核就开始工作。老鱼的解释是没问题的……

你对 L1/2/3 的描述得换成数量级……L1 基本上是5 cycles左右，L2 就得10以上了，L3 基本就得上千了，内存要是能20~50个周期得2000GHz了吧

哦。。我说的单位错了。是纳秒，不是时间周期。1纳秒，大概是4/5时钟周期。

没有你说的那么夸张，看这图：

https://images.anandtech.com/doci/12625/AMD%20Ryzen%20Cache%20Clocks.png

大概是技术进步了吧，我的数字应该是第2、3代时记的，这些年已经不完全不碰了。

刚刚搜到 so 上面的一个结果：

https://stackoverflow.com/a/33065382

2020: Still some improvements, prediction for 2025

-------------------------------------------------------------------------

0.1 ns - NOP

0.3 ns - XOR, ADD, SUB

0.5 ns - CPU L1 dCACHE reference           (1st introduced in late 80-ies )

0.9 ns - JMP SHORT

1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance -- will stay, throughout any foreseeable future :o)

?~~~~~~~~~~~ 1   ns - MUL ( i**2 = MUL i, i )~~~~~~~~~ doing this 1,000 x is 1 [us]; 1,000,000 x is 1 s]; 1,000,000,000 x is 1 [s] ~~~~~~~~~~~~~~~~~~~~~~~~~

3~4   ns - CPU L2  CACHE reference           (2020/Q1)

5   ns - CPU L1 iCACHE Branch mispredict

7   ns - CPU L2  CACHE reference

10   ns - DIV

19   ns - CPU L3  CACHE reference           (2020/Q1 considered slow on 28c Skylake)

71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*

100   ns - MUTEX lock/unlock

100   ns - own DDR MEMORY reference

135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*

202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*

325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*

|Q>~~~~~ 5,000   ns - QPU on-chip QUBO ( quantum annealer minimiser 1 Qop )

10,000   ns - Compress 1K bytes with a Zippy PROCESS

20,000   ns - Send     2K bytes over 1 Gbps  NETWORK

250,000   ns - Read   1 MB sequentially from  MEMORY

500,000   ns - Round trip within a same DataCenter

?~~~ 2,500,000   ns - Read  10 MB sequentially from  MEMORY~~(about an empty python process to copy on spawn)~~~~ x ( 1 + nProcesses ) on spawned process instantiation(s), yet an empty python interpreter is indeed not a real-world, production-grade use-case, is it?

10,000,000   ns - DISK seek

10,000,000   ns - Read   1 MB sequentially from  NETWORK

?~~ 25,000,000   ns - Read 100 MB sequentially from  MEMORY~~(somewhat light python process to copy on spawn)~~~~ x ( 1 + nProcesses ) on spawned process instantiation(s)

30,000,000   ns - Read 1 MB sequentially from a  DISK

?~~ 36,000,000   ns - Pickle.dump() SER a 10 MB object for IPC-transfer and remote DES in spawned process~~~~~~~~ x ( 2 ) for a single 10MB parameter-payload SER/DES + add an IPC-transport costs thereof or NETWORK-grade transport costs, if going into [distributed-computing] model Cluster ecosystem

150,000,000   ns - Send a NETWORK packet CA -> Netherlands

|   |   |   |

|   |   | ns|

|   | us|

| ms|

还是你说的比较客观,实话实说比较好

晶体管数量多少我查不到，但是印象里intel的前端可是占了1x%

而且耗能占整体30%以上。

x86的前端做的事可是太多了，因为cisc的指令还不是上下文无关的，所以前端还是个状态机，还要做动态的分配真实寄存器等事。你说cisc架构前端不重要这个可真不对。

x86指令集的译码都复杂到了需要microcode编程升级的程度了，你说这个不拖性能

这可能么？

换句话说，就算不考虑历史包袱，x86前端的大量工作本来就应该是在编译器里就做完的事

。intel自己可不止一次想甩包袱了，xscale和itanium都出来了，奈何被AMD背后捅刀。

去 csarch 问问呗，我大概搜过也没找到数字

就像你说的，前端做的事情很多，指令集解码占比很小，不然不敢声称基本没差别。没记错的话 x86 指令集用的是 huffman coding，解码的难度还是很低的