買個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的評論回答：