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

iamqk
qk 2020-11-23 字数 78

改变了了cpu架构两个认知

1 精简指令集吊打复杂指令集

2 低功耗吊打高功耗 能耗比上天

CompMarket 电脑市场
24 个回复
legacy
飞翔 2020-11-23

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

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

【 在 iamqk 的大作中提到: 】

: 改变了了cpu架构两个认知

: 1 精简指令集吊打复杂指令集

: 2 低功耗吊打高功耗 能耗比上天

: --

iwannabe
I wanna be 2020-11-23

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

【 在 iamqk (qk) 的大作中提到: 】

: 改变了了cpu架构两个认知

: 1 精简指令集吊打复杂指令集

: 2 低功耗吊打高功耗 能耗比上天

: ...................

zli07
Anonymous 2020-11-23

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

【 在 iwannabe 的大作中提到: 】

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

KM7
楷魔 2020-11-23

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

ibook和powerbook只能继续用G4

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

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

【 在 zli07 (Anonymous) 的大作中提到: 】

: 标  题: Re: M1不仅是性能怪兽,主要改变了长久以来的两个观点

: 发信站: 水木社区 (Mon Nov 23 11:11:06 2020), 站内

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

: 【 在 iwannabe 的大作中提到: 】

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

: :

: --

winggnan
伊南 2020-11-23

1并不成立。。。

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

【 在 iamqk 的大作中提到: 】

: 改变了了cpu架构两个认知

: 1 精简指令集吊打复杂指令集

: 2 低功耗吊打高功耗 能耗比上天

Knightmare
梦醒时分 2020-11-23

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

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

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

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

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

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

【 在 winggnan (伊南) 的大作中提到: 】

: 标  题: Re: M1不仅是性能怪兽,主要改变了长久以来的两个观点

: 发信站: 水木社区 (Mon Nov 23 12:18:22 2020), 站内

: 1并不成立。。。

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

: 【 在 iamqk 的大作中提到: 】

: : 改变了了cpu架构两个认知

: : 1 精简指令集吊打复杂指令集

: : 2 低功耗吊打高功耗 能耗比上天

: --

hgoldfish
老鱼 2020-11-23

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

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

【 在 Knightmare (梦醒时分) 的大作中提到: 】

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

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

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

: ...................

Knightmare
梦醒时分 2020-11-23

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

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

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

【 在 hgoldfish (老鱼) 的大作中提到: 】

: 标  题: Re: M1不仅是性能怪兽,主要改变了长久以来的两个观点

: 发信站: 水木社区 (Mon Nov 23 13:04:19 2020), 站内

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

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

: 【 在 Knightmare (梦醒时分) 的大作中提到: 】

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

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

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

: : ...................

: --

: 灭绝人性啊

octavo
octavo 2020-11-23

苹果比较特别

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

【 在 legacy 的大作中提到: 】

: Arm笔记本早就有了,然并卵

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

legacy
飞翔 2020-11-23

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

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

【 在 octavo 的大作中提到: 】

: 苹果比较特别

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

: --

hgoldfish
老鱼 2020-11-23

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

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

【 在 Knightmare (梦醒时分) 的大作中提到: 】

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

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

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

: ...................

octavo
octavo 2020-11-23

时间能弥补

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

【 在 legacy 的大作中提到: 】

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

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

eGust
十年 2020-11-23

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

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

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

【 在 Knightmare (梦醒时分) 的大作中提到: 】

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

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

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

: ...................

eGust
十年 2020-11-23

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

【 在 hgoldfish (老鱼) 的大作中提到: 】

: 访问内存慢目前主要是用了缓存来应对的。但就算是缓存,也慢啊。l1/l2我记得是一个周期以内,而 l3 就得三四个周期,访问一次内存就得几十个时钟周期(好像是 20-50,具体忘了),CPU 电路在那边干等着,不如去执行另外一个线程。访问内存,就好像高级语言的磁盘IO,阻

hgoldfish
老鱼 2020-11-23

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

没有你说的那么夸张,看这图:

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

【 在 eGust (十年) 的大作中提到: 】

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

eGust
十年 2020-11-23

大概是技术进步了吧,我的数字应该是第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|

【 在 hgoldfish (老鱼) 的大作中提到: 】

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

: 没有你说的那么夸张,看这图:

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

: ...................

myspam
mys/梅艳珊/珊珊/Pam/帕姆 2020-11-23

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

【 在 winggnan 的大作中提到: 】

: 1并不成立。。。

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

Knightmare
梦醒时分 2020-11-23

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

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

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

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

这可能么?

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

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

【 在 eGust (十年) 的大作中提到: 】

: 标  题: Re: M1不仅是性能怪兽,主要改变了长久以来的两个观点

: 发信站: 水木社区 (Mon Nov 23 13:56:13 2020), 站内

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

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

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

: 【 在 Knightmare (梦醒时分) 的大作中提到: 】

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

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

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

: : ...................

: --

eGust
十年 2020-11-23

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

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

【 在 Knightmare (梦醒时分) 的大作中提到: 】

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

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

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

: ...................