买个i9，往主板上怼两条16G的内存，干活呼啦呼啦的快。

所以M1晶元压根不会对intel和AMD原有的市场造成太大的影响，大不了就是原来用intel处理器的部分Mac，换M1罢了，intel在这部分的销量减少了，仅此而已。

不过，如果我经常去星巴克，平时就处理些文档，刷刷网页，看看剧，M1版本的MacBook Air 确实会是一个特别好的选择。

x86早就耗子尾汁了，所以大概不会降价也不会性能突变。

M1强在哪里，之前写过两篇回答了，一篇针对CPU部分，另一篇针对SoC整体。没看过的朋友有空可以看一下，好歹是拿到了几个专业徽章的：

智能手机、平板普及也不是一年两年了，上网追剧聊天的，真没几个人用PC了。现在买PC的，大部分生产力，少部分玩游戏。

如果年纪大点或者接触PC时间长点的，最早应该在本世纪初，就听说过「性能过剩」这个说法了。那时候AMD的K7和Intel的奔三频率大战，CPU频率从之前的主流300 MHz迅速提升到1 GHz以上。现在回看，那时候就说性能过剩有点太天真了，才单核1 GHz就以为够用，严重低估了广大程序员浪费硬体性能的水平了，看看程序员们是如何高效的浪费掉CPU厂家提供的性能的：

面向对象编程。摘录一下维基词条：

面向对象程序设计推广了程序的灵活性和可维护性，并且在大型项目设计中广为应用。此外，支持者声称面向对象程序设计要比以往的做法更加便于学习，因为它能够让人们更简单地设计并维护程序，使得程序更加便于分析、设计、理解。

然而面向对象编程时，大量的调用和参数传递，都需要更多的指令去处理。对比下这两个程序：

int main(int args)
{
int a, b, c;
a = 5;
b = 8;
c = a + b;
}

把加法计算改成函数调用：

int func_add(int a, int b)
{
return a + b;
}

int main(int args)
{
int a, b, c;
a = 5;
b = 8;
c = func_add(a, b);
}

对这两个程序分别用gcc编译，看看要执行的指令区别（使用-O0选项避免编译器优化，使用-S选项查看指令文本）

.file "add.c"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl %edi, -20(%rbp)
movl $5, -12(%rbp)
movl $8, -8(%rbp)
movl -12(%rbp), %edx
movl -8(%rbp), %eax
addl %edx, %eax
movl %eax, -4(%rbp)
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Gentoo Hardened 9.3.0-r1 p3) 9.3.0"
.section .note.GNU-stack,"",@progbits

没有函数调用的整个文件只有12条指令。

.file "func_add.c"
.text
.globl func_add
.type func_add, @function
func_add:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
movl -4(%rbp), %edx
movl -8(%rbp), %eax
addl %edx, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size func_add, .-func_add
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $24, %rsp
movl %edi, -20(%rbp)
movl $5, -12(%rbp)
movl $8, -8(%rbp)
movl -8(%rbp), %edx
movl -12(%rbp), %eax
movl %edx, %esi
movl %eax, %edi
call func_add
movl %eax, -4(%rbp)
movl $0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size main, .-main
.ident "GCC: (Gentoo Hardened 9.3.0-r1 p3) 9.3.0"
.section .note.GNU-stack,"",@progbits

函数调用版则是需要执行24条指令，多了一倍。而且大量的调用，会降低CPU分支预测正确率和缓存命中率，分支预测失败起码需要清空流水线浪费十多个时钟周期，缓存命中失败需要从下级缓存甚至内存中取数的话，少说需要等待十来个时钟周期，多则需要等待数百个时钟周期。

应用虚拟机。摘录一下英文维基词条：

A process VM, sometimes called an application virtual machine, or Managed Runtime Environment (MRE), runs as a normal application inside a host OS and supports a single process. It is created when that process is started and destroyed when it exits. Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system and allows a program to execute in the same way on any platform.

Java、微软的.Net都是在应用虚拟机上运行，目的是让应用运行在一个硬体无关的软体环境中。这些应用虚拟机早期尚未成熟的时候性能有多烂就不用我说了吧？好处在于程序员不需要为每种不同的硬体环境编译一套二进位程序，甚至进行代码上的调整。

Web应用、XML、各种脚本语言。

这些技术的共同性都是使用文本，极大的方便了程序员直接查看代码和数据。然而对这些格式文本的解析和转换为CPU可以处理的数据，也是非常浪费硬体性能的。有兴趣的，可以随便找个开源语言，看看里面的html/xml的解析器里面使用了多少正则表达式处理，正则表达式的实现里面又有多少分支判断和循环。如果改成用二进位的数据结构来实现，一个浏览器需要两三秒才渲染出来的网页，完全可以几毫秒内完成渲染。

上面这些技术的流行，告诉大家，CPU性能是永远都不会嫌多的。

然而，程序员浪费硬体性能是为了提高开发效率(说白了就是偷懒)：面向对象是提高代码复用率，不用重复造轮子；跨平台、脚本语言、Web应用，省了多平台、多版本的重复开发、分发更新、兼容旧版的麻烦；Web应用、XML、脚本语言使得程序员看代码无需再找对应的源码，查数据无需先做格式转换。当CPU主频提升困难，又没有出现新的革命性技术可以大幅提升单核性能的这些年来，CPU厂家提升性能的主要手段一是堆核心，二是加宽SIMD指令。然而单个线程只能在一个核心上运行，要利用上这些新增加的核心性能，程序员要面对多线程编程的各种坑。多线程编程有多坑？随手推篇文章：

https://zhuanlan.zhihu.com/p/38016238?

懒得看的，摘录一段：

说起多线程，有那么几个老生常谈的概念不得不再次在此重申一遍。这里，用群众喜闻乐见的「挖坑」这件事进行类比：

并发：有一群人在挖坑。可能是挖同一个坑，也可能是各自挖各自的坑。单线程 vs. 多线程：一个人在挖坑 vs. 一群人在挖坑。坑的数量不明，人员的组成不明，挖坑的具体安排不明。同步：可以是下面中的某一个：线程同步：一群人在挖坑，同时有一群人在拉土，坑挖好了的时候拉土的人才开始工作。数据同步：一群人在挖坑，以某种方式保证所有人都知道挖坑进度，防止挖到别人的坑里并产生事故。非同步：一个或一群人在挖坑，忽然有人指示开挖新坑，但并没有人为之所动；几小时后连新坑都挖完了，但具体中间是怎么安排的并没有人知道。

这就吃力不讨好了，所以不是真的需要处理大批量的数据的应用，很少为多线程优化，单独一个线程处理界面响应已经算做的不错了。也是因为这样（PS：再加上AMD推土机系列的不争气），Intel才有底气在桌面、笔记本市场挤了近十年的牙膏，从Core 2 Quad一直到Core Gen 7，主流桌面最高级别的CPU一直都只有4核8线程——反正给多了一般人也等闲用不上。4核8线程的规格，足够2~3个稍微有点多线程多任务的应用在后台运行的同时，CPU还有足够的资源保证前台应用的快速响应。

至于加宽SIMD指令，对于批量数据处理很有用。如果说64bit的MMX、128bit的SSE很方便也很适合处理一些常见矢量数据的话，256bit的AVX/AVX2和512bit的AVX512，适用范围真的很窄。这些之前也写过回答了，不重复：

所以，现在x86早就严重两级分化了：一方面是提升单线程性能，只能像苹果那样加宽架构来提升，但是x86的变长指令严重制约了解码单元性能（这个在M1跑分超过i9那篇回答中有详细说明，不重复了），而且宽架构需要消耗更多的晶体管，单个核心成本过高；另一方面则是随著制程工艺升级带来的功耗下降，在限定功耗的场景下塞进去更多的核心。但加宽架构和更多核心这两个方向是矛盾的，因为都会消耗更多的晶体管。CPU厂家只能在两者之间，加上成本因素(晶片大小)来平衡。但可以肯定的一点是，加核心带来的性能提升几乎是线性的，只要你的应用能躲开内存瓶颈并且分出这么多线程来跑，而加宽架构则是会因为受到演算法中的指令并行度、分支预测正确率、缓存命中率这些因素影响，两倍的晶体管很可能只能提升40%的IPC——对于x86而言，还有一个绕不开的解码器性能需要去解决。

从两家已经公开的roadmap来看，Zen4会有哪些改进还不明确，Intel则是打算走大小核混合，可能还有类似M1这样搭配多种专用单元的SoC路线。但和M1的不同在于Intel大概率会把各种专用单元做成chiplet，用晶元堆叠/互联的封装方式来集成，而非M1这样固定多个专用单元。具体请参看关于LKF的评论回答：