作者wei115 (社畜)
看板PC_Shopping
標題[情報] Intel 與 AMD 聯手推進 APX 指令集!x86
時間Thu May 7 04:37:30 2026
完整標題:
Intel 與 AMD 聯手推進 APX 指令集!x86 架構迎來史上最大變革,效能提升不增功耗
原始連結:
https://www.koc.com.tw/archives/641394
內文:
Intel 與 AMD 這對數十年來在 CPU 市場上正面廝殺的競爭對手,正透過 x86 生態系統
顧問小組(EAG)持續深化合作。繼兩天前聯合發布 ACE(AI Compute Extensions)AI
矩陣加速指令集白皮書之後,EAG 再度揭露了 APX(Advanced Performance Extensions
)的最新細節。這項被稱為「x86 自 64 位元以來最大演進」的指令集擴充,將通用暫存
器數量直接翻倍,並在不增加晶片面積與功耗的前提下顯著提升效能。
https://i.imgur.com/dDlr9lf.jpeg
APX 是什麼?為什麼是 x86 的重大演進?
APX(Advanced Performance Extensions)是 Intel 與 AMD 共同制定的新一代 x86 指
令集擴充標準。它的核心精神非常直接:讓 x86 指令集能夠存取更多的暫存器(
Registers)。
暫存器是 CPU 內部容量極小但存取速度極快的儲存單元,負責存放正在運算的資料、指
令與記憶體位址。當指令集能存取更多暫存器時,處理器就能在更短的時間內完成更多工
作,因為大量資料可以直接在 CPU 內部處理,不需要頻繁到速度較慢的記憶體中讀寫。
https://i.imgur.com/6wsaewW.jpeg
這項規格早在 2024 年 10 月就由 Intel 首次提出,如今在 EAG 的框架下由 Intel 與
AMD 共同推動,並釋出了更多技術細節。
APX 六大核心改進
APX 並非單一功能的補強,而是對 x86 指令集架構的一次系統性升級。以下是主要改進
項目:
通用暫存器(GPR)翻倍:由現有的 16 個一舉擴充至 32 個。這讓編譯器可以將更多資
料與變數保留在暫存器中,而非寫入速度較慢的記憶體,對程式碼編譯與執行效率有直接
幫助。
https://i.imgur.com/2N81Nkk.jpeg
記憶體操作效率提升:經過 SPEC CPU 2017 整數基準測試的模擬驗證,APX 編譯後的程
式碼可減少 10% 的讀取操作(loads)與 20% 的寫入操作(stores),代表更快且功耗
更低的程式執行。
非破壞性指令形式:傳統 x86 指令大多是「破壞性」的,運算結果會直接蓋掉其中一個
來源運算元。APX 新增了非破壞性版本,減少暫存器複製需求,讓程式碼更簡潔且執行更
快。
條件執行擴充:過去 x86 的條件執行僅限於 CMOV 與 SET 等少數指令。APX 新增了條件
式讀取(Conditional Load)、條件式寫入(Conditional Store)、條件式比較/測試(
Conditional Compare/Test)以及旗標抑制功能,大幅擴展 if-conversion 的應用範圍
,減少分支預測失誤。
堆疊操作強化:新增 PUSH2 與 POP2 指令,可以在一次記憶體操作中同時推送或彈出兩
個暫存器,加速函式呼叫的進入與返回流程。
程式碼密度不變:儘管新增了大量指令與功能,APX 並不顯著增加程式碼體積,並且完全
向下相容——既有的 x86 軟體可以在支援 APX 的處理器上無縫執行。
與 ACE 指令集同屬 EAG 框架下的戰略布局
APX 的公布時間點極具戰略意義。就在兩天前的 4 月 30 日,Intel 與 AMD 才剛聯合發
布了 ACE(AI Compute Extensions)技術白皮書,將其定位為 x86 架構的「標準矩陣加
速架構」,支援 INT8、FP8、BF16 等主流 AI 資料格式,並相容於 AVX10 指令集。
ACE 聚焦 AI 矩陣運算加速,APX 則專注於通用運算效能的全面提升:兩者相輔相成,共
同構成 EAG 對 x86 架構未來發展的完整藍圖。EAG 自去年成立以來,陸續公布了 FRED
(彈性返回與事件遞送)、AVX10(向量指令集統一)、ChkTag(記憶體安全標籤檢查)
以及 ACE 與 APX 等多項核心特性。
https://i.imgur.com/s3drPcm.jpeg
不用更大面積、不必更高功耗,效能自然提升
APX 最令人驚豔的特色之一,是這些效能提升幾乎不需要額外的矽晶圓面積或功耗作為代
價。Wccftech 的報導強調,APX 可以在不顯著增加核心面積與功耗的情況下,實現更高
的通用運算效能:這對於晶片設計與散熱解決方案來說,意義極為重大。
對開發者與消費者的意義
對於軟體開發者而言,APX 最大的價值在於編譯器的最佳化空間大幅增加。當編譯器能夠
將更多變數保留在暫存器而非記憶體中,程式就能跑得更快、更省電。尤其對於 LLVM
與 GCC 等主流編譯器來說,APX 的 32 個通用暫存器將成為極具吸引力的編譯目標。
對於一般消費者而言,APX 帶來的效益將間接體現在日常使用中:從網頁瀏覽、文書處理
到遊戲與內容創作,支援 APX 的處理器將能以更低的功耗完成相同的工作,或在相同功
耗下提供更流暢的效能表現。
結語
Intel 與 AMD 從數十年的競爭對手,到如今在 EAG 框架下聯手推進 x86 架構的演進:
這不僅是為了對抗 ARM 與 RISC-V 的新興威脅,更是對 x86 這套走過近半世紀的指令集
架構注入全新生命力。APX 的通用暫存器翻倍、ACE 的 AI 矩陣加速標準化,再加上
FRED、AVX10、ChkTag 等一系列基礎架構革新,x86 的故事顯然還沒有寫完。
心得:
出大事了
x86要大改了,上次大改還是x86-64
x86-64的重點在於擴充暫存器長度+新增新暫存器
APX的重點在於新增新暫存器+現代風格的資料流指令
目前用的資料流邏輯還是1970年代流行的那套
從古老到現代,過去50年的歷史刻在x86的指令集裡面
並且x86已經做好再戰50年的準備了
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.233.109.127 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/PC_Shopping/M.1778099855.A.2E4.html
1F:→ hn9480412: 但還有一個豬隊友微軟 59.125.187.40 05/07 04:46
2F:推 WusoAiwen: 難怪兩家股價最近這麼飆,果然商場上 101.8.48.155 05/07 06:44
3F:→ WusoAiwen: 沒有永久的敵人 101.8.48.155 05/07 06:44
4F:→ olozil: 阿不就越來越像RISC 220.132.89.193 05/07 08:10
5F:推 NoneWolf: 太好了 我買AMD 42.70.198.105 05/07 08:29
6F:推 takanasiyaya: x86抄risc也已經很久了就是。 49.218.208.119 05/07 08:40
7F:推 smallreader: 新增16個暫存器不增加空間 是重新利223.139.162.224 05/07 08:56
8F:→ smallreader: 用AVX的暫存器嗎(不懂就問)223.139.162.224 05/07 08:56
9F:→ olozil: 這跟AVX沒什麼關係就是了 111.243.2.147 05/07 09:04
10F:推 smallreader: 看來我被"不增加面積"誤導了,他們有223.139.162.224 05/07 09:28
11F:→ smallreader: 在實體上增設這16個暫存器,說的也是223.139.162.224 05/07 09:28
12F:→ smallreader: "不顯著增加"面積而已223.139.162.224 05/07 09:28
13F:→ smallreader: 中文都亂寫,不意外223.139.162.224 05/07 09:30
14F:推 oopFoo: 現代cpu都有幾百個"虛擬暫存器",只是開 36.224.222.169 05/07 09:31
15F:推 smallreader: 第一段最後一句對應原文意思是「在不223.139.162.224 05/07 09:32
16F:→ smallreader: 顯著增加...之下,能提升效能」223.139.162.224 05/07 09:32
17F:→ oopFoo: 放出來而已。基本上就是指令集的改進。 36.224.222.169 05/07 09:32
18F:→ oopFoo: NovaLake會有,Zen6應該要有。FRED已經在 36.224.222.169 05/07 09:33
19F:→ smallreader: 被翻成在不增加...下能顯著提升 整個223.139.162.224 05/07 09:33
20F:→ smallreader: 意思就大轉彎了223.139.162.224 05/07 09:33
21F:→ oopFoo: PTL上了。FRED在某些io上有大進步。 36.224.222.169 05/07 09:34
23F:→ oopFoo: fred只需要作業系統支援。apx就需要重新 36.224.222.169 05/07 09:37
24F:→ oopFoo: 編碼,理論上可20%的效能提昇。 36.224.222.169 05/07 09:38
25F:推 oopFoo: 基本上,實體面積真的沒什麼增加。 36.224.222.169 05/07 09:44
26F:推 olozil: 對APX不用太期待,基本上就是已經沒什麼手 111.243.2.147 05/07 09:49
27F:→ olozil: 段了還不想大改,影響CPU的主要有計算、控 111.243.2.147 05/07 09:49
28F:→ olozil: 制、IO、同步,增加暫存器就是對計算與控 111.243.2.147 05/07 09:50
29F:→ olozil: 的部分增強,但效果有限,IO來說你加大了 111.243.2.147 05/07 09:50
30F:→ olozil: L1反而性能會下降,你把L1從32K->48K 111.243.2.147 05/07 09:50
31F:→ olozil: 訪問就會從4個cycle變5個cycle, 111.243.2.147 05/07 09:50
32F:→ olozil: 然後掉性能,X86最大的問題一直是記憶體的 111.243.2.147 05/07 09:50
33F:→ olozil: 一致性,這是RISC不會有的問題 111.243.2.147 05/07 09:50
34F:推 smallreader: 就算是虛擬的也要有實體位置支援吧223.139.162.224 05/07 09:57
35F:推 olozil: 直接舉例來說,上一次加暫存器是X86-64, 111.243.2.147 05/07 09:57
36F:→ olozil: 然後這次幅度還會比上次小一點 111.243.2.147 05/07 09:58
37F:→ smallreader: 不然能並行的線頭數量會減少(?)223.139.162.224 05/07 09:59
38F:推 oopFoo: 記憶體的一致性,TSO,有好有壞。現代cpu 36.224.222.169 05/07 10:01
39F:→ oopFoo: 的性能,根本發揮不出來。記憶體頻寬又小 36.224.222.169 05/07 10:02
40F:→ oopFoo: 所謂的虛擬其實就是實際暫存器,我講的 36.224.222.169 05/07 10:04
41F:→ oopFoo: 有點反過來。實際有幾百個暫存器,cpu會 36.224.222.169 05/07 10:04
42F:→ oopFoo: 虛擬成好幾組,同時使用。現在只是開放 36.224.222.169 05/07 10:05
43F:→ oopFoo: 給程式直接使用,可縮短程式碼,更有效率 36.224.222.169 05/07 10:06
44F:推 smallreader: 嗯 反過來 實體=幾百個 虛擬=一個執223.139.162.224 05/07 10:06
45F:→ smallreader: 行緒所看到的223.139.162.224 05/07 10:06
46F:→ oopFoo: 的應用。 36.224.222.169 05/07 10:06
47F:推 CyBw: 還沒要升x86-128嗎,都幾年了 114.35.167.130 05/07 10:09
48F:推 oopFoo: 暫存器增加多吧,x64加8個,apx加16個。 36.224.222.169 05/07 10:14
49F:→ oopFoo: cpu內部看到的暫存器跟程式碼不一樣。例如 36.224.222.169 05/07 10:15
50F:→ oopFoo: store [rax]然後接著load rax,cpu會用兩 36.224.222.169 05/07 10:16
51F:→ oopFoo: 暫存器,因為它們互不干擾,可以平行處理 36.224.222.169 05/07 10:17
52F:→ oopFoo: 你要一個cycle同時處理8個指令,那這八個 36.224.222.169 05/07 10:18
53F:→ oopFoo: 指令不能互相依賴。太少暫存器就容易製造 36.224.222.169 05/07 10:19
54F:→ oopFoo: 依賴。 36.224.222.169 05/07 10:19
55F:推 nrsair: 新指令集擴充 49.217.202.62 05/07 10:20
56F:推 s25g5d4: 6202 年還在談 CISC/RISC 就落伍了,是沒 211.22.64.132 05/07 10:31
57F:→ s25g5d4: 看到 ARM 近幾年瘋狂加各種 SIMD 指令集 211.22.64.132 05/07 10:31
58F:→ s25g5d4: ,ARM 跟 x86 這幾年差異主要在 variable 211.22.64.132 05/07 10:31
59F:→ s25g5d4: instruction length 而已。ARM 現在也是 211.22.64.132 05/07 10:31
60F:→ s25g5d4: decoder 拆 mOP 下去跑,跟 x86 一樣, 211.22.64.132 05/07 10:31
61F:→ s25g5d4: 只是 fixed length decoder 比較好做而已 211.22.64.132 05/07 10:31
62F:推 kuninaka: 股價飆跟這沒關係啊 1.174.97.117 05/07 10:46
63F:→ kuninaka: 那是AI需求 1.174.97.117 05/07 10:46
64F:→ h311013: 蘋果推自研真的是很有遠見 61.227.103.243 05/07 11:31
65F:推 wahaha99: 就算是實體暫存器 佔用空間也還好 37.19.205.168 05/07 11:35
66F:→ wahaha99: 君不見現在佔CPU最多的早就不是邏輯單元 37.19.205.168 05/07 11:35
67F:推 takanasiyaya: Apple從來就喜歡自研,只有core2時 49.218.208.119 05/07 12:43
68F:→ takanasiyaya: 代的Intel真的太厲害才低頭用Intel 49.218.208.119 05/07 12:43
69F:→ takanasiyaya: ,不然全部都嘛用自己的。不過M系列 49.218.208.119 05/07 12:43
70F:→ takanasiyaya: 記憶體架構有創新是真的有意義 49.218.208.119 05/07 12:43
71F:→ labbat: 存儲記憶體都是公共資源,通用暫存器都是 39.15.56.30 05/07 12:47
72F:→ labbat: 特定執行緒限定資源,編譯器活用可以減輕 39.15.56.30 05/07 12:47
73F:→ labbat: 匯流排負擔 39.15.56.30 05/07 12:47
74F:推 Bencrie: 我想得到的好處就 x86-64 ABI 呼叫函數 60.251.10.52 05/07 12:51
75F:→ Bencrie: 的時候 args 塞 regs 的上限變高 60.251.10.52 05/07 12:51
76F:推 guanting886: 看起來雖然是APX很厲害 但感覺上是 42.78.166.15 05/07 13:16
77F:→ guanting886: 兩邊找機會把過去的技術債一起清掉 42.78.166.15 05/07 13:16
78F:→ guanting886: 之前有多少0day搞到資料中心很緊張 42.78.166.15 05/07 13:16
79F:推 ltytw: 清掉技術債怎麼不是找時間重新發明X86? 36.234.230.69 05/07 13:20
80F:→ ltytw: 例如什麼X86 Gen2 然後順便清掉技術債或 36.234.230.69 05/07 13:20
81F:→ ltytw: 屎山代碼 36.234.230.69 05/07 13:21
82F:推 tsairay: 清掉技術債不是叫你不要向下相容 202.39.11.150 05/07 13:22
83F:噓 bhmagic: 血紅姊哭哭 沒人理VIA 99.118.209.229 05/07 13:29
84F:→ olozil: X86實際可用6個暫存器, _sp與_bp有限制 111.243.2.147 05/07 13:37
85F:→ olozil: 所以是 86(6) -> 86-64(16) -> APX(32) 111.243.2.147 05/07 13:38
86F:→ olozil: 這次增加幅度沒有上次多 111.243.2.147 05/07 13:39
87F:→ commandoEX: 升128沒啥好處吧,要說的話AVX就能處 59.125.204.130 05/07 13:47
88F:→ commandoEX: 理128/256/512 bit的數據了 59.125.204.130 05/07 13:48
89F:推 takanasiyaya: 卡難,x86的小白使用者們不允許,i 49.218.208.119 05/07 13:48
90F:→ takanasiyaya: 皇當初雄心壯志要打掉x86重練itinum 49.218.208.119 05/07 13:48
91F:→ takanasiyaya: 的結果就是被AMD x86-64闖空門進去 49.218.208.119 05/07 13:48
92F:→ takanasiyaya: 伺服器 49.218.208.119 05/07 13:48
93F:→ commandoEX: VIA授權不是過期了嗎? 59.125.204.130 05/07 13:49
94F:→ ma721: 把ai放進去 101.10.87.189 05/07 14:07
95F:推 leon1757tw: 要清技術債的是x86s吧 不過被放棄了 123.110.162.31 05/07 14:17
96F:推 s25g5d4: 重新發明 x86?IA64: 211.22.64.132 05/07 14:52
97F:→ gainsborough: 只要I、A、高通、發哥還是賣SOC,那 114.41.201.174 05/07 16:10
98F:→ gainsborough: 注定就有面積大小的成本獲利定價衝 114.41.201.174 05/07 16:11
99F:→ gainsborough: 突,感覺還是打不贏大面積狂堆晶體 114.41.201.174 05/07 16:12
100F:→ gainsborough: 管數量的蘋果SOC(面向普通消費者) 114.41.201.174 05/07 16:12
101F:→ cor1os: 加新指令集才是淘汰老PC最快的方法 -.- 122.147.131.2 05/07 16:30
102F:推 oopFoo: _bp沒有限制,_sp有限制所以_sp+_bp來存取 58.114.66.74 05/07 19:58
103F:→ oopFoo: stack frame。但esp可以offset了,ebp就可 58.114.66.74 05/07 19:59
104F:→ oopFoo: 空出來。如果你的環境許可,esp也可挪來用 58.114.66.74 05/07 20:00
105F:→ oopFoo: 。但就算6>16>32。16還是比10多啊。 58.114.66.74 05/07 20:01
106F:推 soem: 可惜X86S各方沒共識,能移除一些舊時代的指 1.34.10.55 05/07 20:04
107F:→ soem: 令集的話也算是有進步 1.34.10.55 05/07 20:04
108F:推 oopFoo: 移除沒有意義,因為空間佔很少。現代cpu的 58.114.66.74 05/07 20:08
109F:→ oopFoo: 瓶頸在branch,在cache,在memory,這都不 58.114.66.74 05/07 20:10
110F:→ oopFoo: 是指令集的問題。x86雖然丑,但相容性100% 58.114.66.74 05/07 20:11
111F:→ friedpig: 相容性100%除了少數老舊工業軟體沒再更 114.32.196.169 05/07 21:48
112F:→ friedpig: 新以外 真的那麼重要嗎? 114.32.196.169 05/07 21:48
113F:→ friedpig: 真的必須的舊軟體沒剩多少了八 114.32.196.169 05/07 21:49
114F:推 smallreader: 編譯器框架很在意相容性吧223.139.162.224 05/07 22:21
115F:→ smallreader: 有一些萬年不變的程式碼還活在底層223.139.162.224 05/07 22:24
116F:推 oopFoo: 編譯器,直譯器不需要重新再來。軟體生態 58.114.66.74 05/08 04:05
117F:→ oopFoo: 重新再來,就算相似也是超大工程。遠望 58.114.66.74 05/08 04:06
118F:→ oopFoo: riscv。 58.114.66.74 05/08 04:07
119F:推 athraugh: 請教各位高人. CPU 對RAM 的頻寬要 39.12.109.188 05/08 08:48
120F:→ athraugh: 增加,到VRAM (GPU的)那樣大頻寬, 是 39.12.109.188 05/08 08:48
121F:→ athraugh: 需要增加指令集 還是 對連接的實體線數 39.12.109.188 05/08 08:48
122F:→ athraugh: 量? 目前都不做的困難點是什麼. 39.12.109.188 05/08 08:48
123F:推 oopFoo: 頻寬增加要實體線數量增加+高速ram。困難 36.224.222.169 05/08 09:39
124F:→ oopFoo: 點在於"貴"。之前高階pc的需求主要來自於 36.224.222.169 05/08 09:40
125F:→ oopFoo: 遊戲,遊戲吃"大快取",對頻寬要求反而不 36.224.222.169 05/08 09:41
126F:→ oopFoo: 高。現在ai興起,狂吃頻寬。所以之後的pc 36.224.222.169 05/08 09:42
127F:→ oopFoo: 也會在這方面加強。 36.224.222.169 05/08 09:42
128F:推 athraugh: 謝謝回復 39.12.109.188 05/08 10:58
129F:推 Rollnmeow: X86s始終沒共識只有Intel提倡而已 49.214.1.195 05/08 12:08
130F:→ Rollnmeow: 這個APX才是共識下的產物 49.214.1.195 05/08 12:10
131F:推 roseritter: VRAM一般都是高速,比起MB上的RAM 223.139.62.6 05/08 12:51
132F:推 atelier: x86陣營包袱多權力也分散 改架構難度太高 101.10.218.47 05/08 13:24
133F:→ atelier: 蘋果軟硬體一把抓 單純多了 又有信仰 101.10.218.47 05/08 13:25
134F:→ atelier: 換架構駕輕就熟Motorola 68000->PowerPC 101.10.218.47 05/08 13:26
135F:→ atelier: x86->Apple Silicon 101.10.218.47 05/08 13:27
136F:→ atelier: 以前PowerPC轉x86 軟體支援說斷就斷 101.10.218.47 05/08 13:28
137F:→ atelier: 蘋果的使用者還不是就摸摸鼻子買新的 101.10.218.47 05/08 13:28
138F:→ xxtomnyxx: 現在似乎很多call都把資料陣列用ecx/120.126.106.155 05/08 13:46
139F:→ xxtomnyxx: rcx指向,PUSH和POP功能增加有用嗎?120.126.106.155 05/08 13:47
140F:→ xxtomnyxx: 是說,以前自學組合語言時一直沒弄清楚120.126.106.155 05/08 13:48
141F:→ xxtomnyxx: ,stack資料調用的速度會比offset快嗎120.126.106.155 05/08 13:48
142F:→ xxtomnyxx: ?120.126.106.155 05/08 13:49
143F:推 tn601374: 哦豁 36.224.223.120 05/08 16:15
144F:→ dildoe: 起碼reg 相依關係會打斷一些 阿公級isa有 36.229.169.173 05/09 06:18
145F:→ dildoe: 在改 算好事吧 36.229.169.173 05/09 06:18
146F:→ dildoe: 反正主要客戶是大廠 大廠homebrew多 對re 36.229.169.173 05/09 06:22
147F:→ dildoe: build 重編譯 沒啥感覺吧 36.229.169.173 05/09 06:22
148F:→ dildoe: 對常見calling conventions 會摸reg有什 36.229.169.173 05/09 06:26
149F:→ dildoe: 麼疑問 直接google問ai 回答都不錯吧 36.229.169.173 05/09 06:26
150F:推 demintree: reg數增加,實際應用的效能不知多少 73.252.153.154 05/09 14:31
151F:推 demintree: DRAM優勢在低延遲,而VRAM在於吞吐量 73.252.153.154 05/09 14:35
152F:→ xxtomnyxx: 沒想過可以直接問AI,拿去問了之後覺得120.126.106.155 05/09 18:04
153F:→ xxtomnyxx: 當時自學如果有AI肯定學得更好120.126.106.155 05/09 18:05