前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >M1 暴打 Intel?——这次的芯片有何不同

M1 暴打 Intel?——这次的芯片有何不同

作者头像
出其东门
发布2020-12-14 10:19:55
1.1K0
发布2020-12-14 10:19:55
举报
文章被收录于专栏:01二进制01二进制

1. 前言

之前看到 M1 芯片出来之后,就想说些什么,结果光写 x86 和 ARM 就写了 4000 多字,考虑到文章篇幅,只得分为上下两篇,上一篇文章发出后有很多人表示非常喜欢,让我赶紧更新,在这里向支持我的读者们表示感谢 ?。

那么话不多说,这篇我们来聊一聊,这次的芯片到底有何不同,以至于让那么多人说苹果不讲武德。

在这之前我先说明,我只是一个计算机专业的学生,从来就没有自诩自己是什么专家学者,我写博客也只是为了做一些简单的科普,把自己知道的一些知识分享给大家。如果文章中有什么错误的地方,还请各位读者指正。

2. M1 芯片 ≠ CPU

首先,我们要先摆脱一个认知误区,M1 芯片不是一块 CPU,而是一块专为 Mac 设计的 SoC 芯片。CPU 只是 M1 芯片的一个组成部分

所谓 SoC 芯片,指的是系统级芯片(System on Chip),也称片上芯片,是一个将电脑或其他电子系统集成到单一芯片的集成电路。SoC 集成的主要包括处理器(CPU,GPU 等)、基带、各种接口控制模块、各种互联总线等,其典型代表为手机芯片。举个例子,CPU 公司将自己的所生产的 CPU 设计卖给其他公司,而其他公司就根据该 CPU 自己添加上所需要的各种外设控制器,这就是 SoC。

所以简单来说:SoC 就是一块集成了 CPU、GPU 等多种结构的芯片。因此,千万不要简单的认为 M1 芯片就是 CPU。

官网有一张图,就很好地说明了 M1 芯片的组成成分。如下图所示,苹果称其为统一内存架构(Unified memory architechture),即通过 Fabric 高速总线将中央处理器、图形处理器、神经网络引擎、缓存、DRAM 内存全部连接在一起。因此,M1 芯片的强大,绝不是靠一个强悍的 CPU 支撑的,而是众多性能强大的部件结合苹果优秀的设计共同努力的成果。

3. 统一内存架构(UMA)

通过上一段内容,我们知道了 M1 芯片的强大光靠一颗强大的 CPU 是不够的,毕竟苹果也没办法突破物理定律,单纯通过设计让 CPU 的性能提升数倍。很明显苹果采用了其他的技巧来弯道超车,而「统一内存架构」就是其中之一。

我们知道,处理器在处理任务时,他要做的事情很简单就是取东西和算东西,也就是上一篇文章中提到的“接收指令+运算数据”。

和上篇文章一样,我们还是以打工人为例,取东西就是打工人搬砖,算东西就是打工人砌砖,你砌砖砌得再快再好,砖搬的慢,砌砖的速度也不会快。反过来也是,如果砌砖的慢,搬砖的块,就会有砖堆积。

因此理想状态下,搬砖的速度和砌砖的速度应该是一致的,这样就不用等对方。对于 CPU 来说也是同样的道理,如果双方的速度不一致,就会造成性能浪费。

因此,为了解决上述问题,苹果提供了一个解决方案,就是统一内存架构

3.1 UMA 做了什么?

那么 UMA 到底做了什么?

我们电脑里面有很多 PU(Processing Unit),即处理单元(处理器),我们常见的有 CPU(Central Processing Unit,即中央处理器)、GPU(Graphics Processing Unit,即图形处理器)和 NPU(Neural network Processing Unit,神经网络处理器)。他们都需要取东西、算东西,但是在 UMA 出现之前,他们只能通过 CPU 来分配东西,而 CPU 还要事先从内存中取数据。显然,这种工作方式的效率很低,况且,不同的处理器对于数据的运算速度也是不同的,为了做到时序同步,一定程度上不利于硬件性能的发挥。

而且,每个处理单元作为一个独立的个体,各自处理的数据包格式也不一样。不同 PU 之间通信的语言都是不一样的,统一数据格式时也需要消耗时间,如果这样通信效率还高那才有问题。就像来自不同国家的打工人一起打工时,都说各自的语言,通过翻译才能进行沟通,这听起来效率就很低。

当然了,以上只是简单的举一些例子,真实情况肯定是比这更加复杂的,但即使是这样,我们也能感受到有很多本来不应该存在的步骤耽误了很多时间。所以,为了解决上述这些问题,苹果给出了几个解决方案。

3.1.1 PU 直接访问内存

没有 UMA 之前,需要先将数据从内存中取出,然后由 CPU 优先处理、分配,如下图所示 ?

有了 UMA 之后,这些处理单元可以直接访问内存,再也不需要通过 CPU 去获取一些数据了,如下图所示 ?

通过这样的设计方式,这个 PU 们不需要再和 CPU 同步语速,也不用什么乱七八糟的事情都先去找 CPU 过问一遍,这样就省下来一大笔时间了。

3.1.2 Apple-designed package

虽然解决了取数据时的时序问题,但是各处理单元的通信问题仍然没有得到解决,这里就要提到苹果所做的另一个解决方案了——Apple-designed package。

通过 Apple-designed package,各单元处理数据时的数据包格式统一了,他们之间的沟通不再需要翻译了,哪怕都说的是“阿巴阿巴阿巴”也都能明白各自说的是什么了,这就又省下了一部分时间。

3.1.3 高度集成

无论是拆解图还是实例图,都说明苹果这次的高度集成,是直接将内存放到了处理器的旁边,这极大的缩小了内存和处理器之间的物理距离,取数据的速度自然就会更快了。

千万别小看了这点物理距离的减少,目前的计算机都属于冯诺依曼结构,而该结构最大的一个隐患就是:在内存容量指数级提升以后,CPU 和内存之间的数据传输带宽成为了瓶颈,原因之一就在于内存和 CPU 的物理距离过大。虽然现在 CPU 和内存的速度越做越快,但是他们之间的距离却无法改变,而传输数据的速率-光速也无法改变。

我们可以来做一个简单的数学题,i9-7980XE 是一颗 18 核 36 线程的民用 CPU,这颗 CPU 最大睿频 4.4GHz,假设该 CPU 在一个时钟周期内执行一条运算指令,那么该 CPU 执行一个指令需要的时间是 0.000000000227273 秒,即 0.22ns(纳秒),那么在这段时间内,光所跑的距离是 0.0681819 米,四舍五入就约等于 7 厘米。所以说如果 CPU 和内存之间的距离超过 7 厘米,CPU 岂不是要多等一会才能继续收到指令了。这还是一次只取一条指令的情况,如果数量多了呢?

所以物理距离的缩小,自然可以让 CPU 取数据的速度更快一些,这也是 M1 芯片性能提升的关键一点。

3.2 超大缓存

上面说的这些也都只是让 CPU 取数据时可以更快一些,但是 CPU 和内存之间的数据传输带宽成为瓶颈不单单是因为物理距离的原因,最根本的原因还是因为 CPU 太快了,很难做到和内存同步。所以我们得把计算机经常用到的数据导入 cache,也就是缓存,避免计算机去内存要东西,更不应该让计算机去硬盘要东西。

3.2.1 什么是缓存

缓存就是数据交换的缓冲区(称作 Cache),是存贮数据(使用频繁的数据)的临时地方。其实在很多地方都用到了缓存,比如当用户查询数据,首先在缓存中寻找,如果找到了则直接执行。如果找不到,则去数据库中查找。

CPU 也同样设计了一个这样的存在,是一个用于减少处理器访问内存所需平均时间的部件。他的工作原理是:当处理器发出内存访问请求时,会先查看缓存内是否有请求数据。如果存在(命中),则不经访问内存直接返回该数据;如果不存在(失效),则要先把内存中的相应数据载入缓存,再将其返回处理器。

还是拿搬砖这个例子来加深理解,如果我正在砌砖,就算搬砖的人把砖搬过来了,我也来不及砌,光让他在那站着等也不好,所以就让他把砖放到脚边(缓存),这个砌砖的每次就不用跑去搬砖的那里拿砖了,只需要从脚边(缓存)拿砖就好了。

所以,我们知道缓存主要是为了弥补 CPU 和内存之间的读写速度差异而出现的,因此理论上,在一定范围内,缓存自然是越大越好。

3.2.2 M1 芯片的缓存设计

M1 芯片同样也是这么设计的,只是苹果为 M1 芯片带了超大的缓存,这个缓存有多大呢,我们来做个简单的比较。(以下数据摘自维基百科和 CPU - Z)

L1 表示一级缓存,L2 表示二级缓存,即一级缓存的缓存。一级缓存还分为一级数据缓存(Data Cache,D-Cache,L1d)和一级指令缓存(Instruction Cache,I-Cache,L1i),分别用于存放数据及执行数据的指令解码,两者可同时被 CPU 访问,减少了 CPU 多核心、多线程争用缓存造成的冲突,提高了处理器的效能。一般 CPU 的 L1i 和 L1d 具备相同的容量。

这个对比结果非常明显,尤其是在二级缓存,虽然在 M1 芯片中,二级缓存是共享的,但这 16MB 的缓存还是比 i9-10900K 的二级缓存大了不少。虽然 i9-10900K 的三级缓存有 20MB,但是也只是比 M1 的二级缓存大了 4MB,并且三级缓存的速度是比二级缓存慢得多的。

而且,可别忘了,基于苹果这次的高度集成,DRAM 内存和处理器直接通过 Fabric 高速总线连接在一起,这样使得集成的内存可以近似看做是一个超大容量的 L3 缓存,苹果用牺牲扩展性换取吞吐量的策略,给 M1 芯片带来了更高的带宽与更低的延迟。当然了,缓存也并不是越大越好,一方面是制作的难度,另一方面缓存命中率也是评价缓存性能的一个重要指标。如果缓存过大,命中率就会下降,如果这样就会有些得不偿失了。

其实 M1 芯片之所以可以塞入这么大的缓存,和其制作工艺是有很大的关系的,相较于 10nm、14nm,M1 芯片采用台积电最先进的 5nm 工艺制成,晶体管越小,单位面积内可塞入晶体管的数量就更多,这样就让苹果可以为 M1 芯片设计更大的缓存。这一部分具体我们下一节来说。

现在再回过头看我们一开始所说的:“所谓统一内存架构,就是通过 Fabric 高速总线将中央处理器、图形处理器、神经网络引擎、缓存、DRAM 内存全部连接在一起。”这不仅仅是简单的将各单元连接在一起,而是苹果这么多年在移动端 SoC 优秀实践经验的结晶,是只属于苹果自己独享的 moment。

所以说,这么一套搞下来,哪怕 M1 芯片的 CPU 芯片的物理性能没有得到提升,性能也不是最强大的,但 UMA 的设计架构也会给 M1 芯片带来综合性能的提升。

况且,谁说 M1 芯片的 CPU 就不行了呢?

4. 制程&晶体管数量

Apple 官网对于 M1 芯片有如下的介绍:

M1 也是 Apple 首款采用先进 5 纳米制程打造的个人电脑芯片,封装了惊人的 160 亿个晶体管,其数量为 Apple 所有芯片之最。

这里我将两个重要的数字加粗标注了出来,第一个数字是刚才提到的 5 纳米制程,第二个数字是 160 亿个晶体管。

4.1 5 纳米制程指的是什么?

当我们阅读一个和芯片有关的文章时,经常会看到诸如 5nm、7nm、14nm 这些词,例如华为的“最后一款”麒麟芯片,麒麟 9000 就是 5nm 工艺制程,那么这个 5nm 指的到底是什么呢?

说实话,这一块内容水太深了,我自己也不是从事半导体领域的,很难解释清楚,这里就只能简单的说明一下。

引用知乎的一张图,在上图所示的晶体管结构中,电流从 Source(源极)流入 Drain(漏级),Gate(栅极)相当于闸门,主要负责控制两端源极和漏级的通断。电流会损耗,而栅极的宽度则决定了电流通过时的损耗,表现出来就是手机常见的发热和功耗。宽度越窄,功耗越低。而栅极的最小宽度(栅长),就是 XX nm 工艺中的数值。

简单来说就是,Leakage Path 越小,电流损耗越小,总体来看就是功耗越小。宏观来看,随着 Leakage Path 越小,晶体管之间的距离就越小,单位面积内可以塞入的晶体管数量就越多,整体的运算性能就越强。

最近,AMD 疯狂 yes 的原因和其工艺制程的提升有很大关系,而此次 M1 芯片所采用的是目前市面上最先进的 5nm 工艺制程,性能强也是意料之中的事情了。

4.2 为什么晶体管数量越多,运算性能越强?

晶体管就可以看成一个小开关,有通断两种状态。你可以理解为通是 1,断是 0,那么一个晶体管的一次开,或者一次关,就提供一个 2 位的数据:0 或者 1。用无数个 0 或者 1 就可以代表所有的数据。这也就是为什么电子时代信息被称为数字化。其实就是把所有的信息用数字来表示。而数字,可以用电脑来处理。电脑是没法直接处理人类的信息的。这就是计算机采用二进制表示数据的的原因。

所以我们要理解,是因为电路的这个特性才让先辈们选择二进制作为机器的语言,而不是因为二进制简单所以采用二进制的。这里提两个小问题:人为什么要使用十进制?生活中有没有使用其他进制计数的例子?欢迎在评论区留下你的想法。

一个晶体管一次只能表示一个 0,或者 1。那么一大堆晶体管同时工作呢?

简单的说就像是一个大的存放开关的工厂,每个晶体管就是一个开关,关的时候表示 0,开的时候表示 1,晶体管越多,开关也越多,在处理同一个问题的时候走的线路也就越多。这就像是你以前学初中物理时的并联电路,支路越多流通的线路也越多。同样,CPU 的晶体管越多,单位时间内可以流过的电流的支路也就越多,反映在宏观上就是你在一颗 CPU 上能同时处理的数据也就越多,机器也就越快。

不过晶体管越多芯片性能越好这一点并不是绝对的,只是相对来说,晶体管多了之后,可设计的空间就更大了,剩下的就要看厂商能否利用好这部分设计空间了。

5. M1 真的完美吗?

那么问题来了?说了这么多 M1 芯片的优点,又是采用了 UMA 架构,又是最先进的工艺制程,他是一个完美的芯片吗?我想未必。

5.1 扩展性

相比上面的介绍让你对 M1 芯片的统一内存架构有了一定了解,也知道这样的架构对于性能的提升有很大的帮助。

只是将内存这样焊死在一块 SoC 芯片上,对于后期想要硬件扩展的用户来说,无疑是不可能的。

而且虽然 M1 的 GPU 的性能很强,但也是相对手机上的 GPU 来说的,和桌面级的 GPU 相比还是有很大的差距的,毕竟体积摆在那了,这对外接显示器或者玩游戏的用户来说也是很难熬的。同样的,外接显卡也是用不了的,不过应该也不会有人用 Mac 玩游戏吧。

Mac 当然可以玩游戏,这里挖个坑,下次我们来窥探一下未来——云游戏。

5.2 兼容性

从 x86 架构迁移到 ARM 架构,苹果是下了很大决心的,也是布局已久了。为了不让用户担心应用生态会出现较大的变化,苹果给出了三种不同应用的解决方案,分别是「Universal 通用应用」「Rosetta 2 转译应用」以及「原生 ARM 应用」。其中,Universal 是横跨 ARM 和 X86 平台的应用,目前以后部分开发者将自家软件转向 Universal,例如 Adobe 的 Lightroom,Photoshop 则会在明年更新。这里不得不感慨一下苹果的号召力,apple silicon 一出,各大厂商都在快速跟进,估计隔壁某厂要羡慕哭了。

如果新应用没有适配 Universal,那你也可以通过 Rosetta 2 转译应用,那些原生的 X86 编译应用可以通过苹果提供的 Rosetta 工具,转译成可以在 ARM 平台直接运行的应用,虽然会损失一些性能,但是可以极大提升兼容性。目前从各种兼容性测试视频来看,Rosetta 2 的完成度非常高,并不像隔壁某厂,推出的是一个半成品。

如果说,上面两种解决方案还是无法满足你的需求,那么你还可以依托苹果建成依旧的 App Store 生态,直接运行原生 ARM 应用,它们能够直接在 macOS、iOS 和 iPadOS 上运行,相当于苹果打通了小屏到大屏的主要设备。

即便曾经 macOS 的软件生态还不完善,但在 iOS 几乎已经没有了这个问题,也使得搭载 M1 芯片的 Mac 产品并不需要太过担心没有足够的应用可以使用。

而且,从此次更新的 macOS Big Sur 也可以看出,苹果也是有意让这三端的风格更加统一。无论是系统界面还是图标样式,都在往 iPad 和 iPhone 上统一。

那么为什么同样的软件在迁移的时候会有兼容性的问题?这已经和本文要介绍的 M1 没什么关系了,考虑到篇幅问题,我们之后再说。

那么到底 M1 版 MacBook 能兼容什么软件、不能兼容什么软件?

一个个软件测试,工程量非常大,而且软件们也处于不停的更新换代中。好在 GitHub 上出现了一个关于 M1 版 MacBook 的兼容性测试项目“DoseitARM”。在这个项目中,可以看到开发工具、影音工具、图形图像工具、剪辑工具等各种生产力软件的兼容性测试。各类软件的兼容性又被分为几种不同的情况,分别如下:

他的地址是 ?:https://github.com/ThatGuySam/doesitarm

有兴趣的读者可以长期关注该项目。

6. 最后

对于财大气粗的苹果来说,未来无疑将会长期进行大量的投入来对 M 系列芯片进行迭代,并且其自有生态也保证了能够反哺 M 系列芯片的研发。希望国内的企业也可以像苹果一样有属于自己的芯片,未来值得期待!

如果你觉得我的文章对你有所帮助,不妨点个赞关注我,就当是给我的一点鼓励了,你们的鼓励会让我更加努力做好分享,感谢支持 ?。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-11-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 01二进制 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 前言
  • 2. M1 芯片 ≠ CPU
  • 3. 统一内存架构(UMA)
    • 3.1 UMA 做了什么?
      • 3.1.1 PU 直接访问内存
        • 3.1.2 Apple-designed package
          • 3.1.3 高度集成
            • 3.2 超大缓存
              • 3.2.1 什么是缓存
                • 3.2.2 M1 芯片的缓存设计
                • 4. 制程&晶体管数量
                  • 4.1 5 纳米制程指的是什么?
                    • 4.2 为什么晶体管数量越多,运算性能越强?
                    • 5. M1 真的完美吗?
                      • 5.1 扩展性
                        • 5.2 兼容性
                        • 6. 最后
                        领券
                        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档