?1.5 TFlops 到底有何魅力？首先，這是在電池供電的單核 MacBook Air 2020 上運行；
其次，這會以每條指令約 0.5 納秒的延遲運行。
那些強大的加速器或 GPU 張量核不在我們的考慮范疇。我們這里討論的是與 CPU 寄存器相隔一個周期的實際線性代數性能。
奇怪的是，蘋果一直在向我們隱瞞這一點。在本文中，我們將通過一些代碼來揭開迷霧。
什么是 AMX 協處理器？
它可以說是 SIMD 的典范。一個重要的區別是 AMX:CPU 比率不是 1:1；并非每個內核都有自己的 AMX 協處理器。
以下是用于加載或存儲值的規格：
最小值與完整的 AVX512 寄存器一樣寬
但這些值是從哪里加載或存儲的？顯然，這樣的大小會很快用完整個 NEON 寄存器文件。不過 AMX 有一個單獨的寄存器文件，這有些奇怪。
寄存器分為三組：X、Y 和 Z。對每個指令，X 和 Y 組保存輸入，Z 組保存輸出。
如我們所見，X 和 Y 相當大。二者之間有一個完整的 KB。Z 則令人稱奇，然后是一些：
（劇透：一條 AMX 指令可以填充 1024 字節（Z 寄存器的 1/4）。）
那么如何從 X 和 Y 到 Z？方法很多，以至于它不那么適合 ISA 編碼。所以蘋果決定將大部分指令信息編碼在通用寄存器中。事實證明，這個決定很贊，因為可以在 AMX 上執行代碼的運行時（動態）配置。
這篇文章旨在提高協處理器利用效率。有一些 vector-vector 指令可以輸出長度相同的向量，但不會使芯片的計算能力飽和。反而必須借助外積來進行。?
何為外積？假設有兩個輸入向量 u 和 v：
外積是一個矩陣，包含各元素可能組合對的乘積。（這里給出一些提示，說明為什么 Z 寄存器組比 X 和 Y 大得多。）
在 AMX 芯片上，可歸結為一個非常簡單的指令，就像這樣：
可以設置一個標志，使其從上一個結果中累加：
這樣，我們就完全具備了編寫矩陣乘法所需：從輸入矩陣中重復加載 16 個浮點數，并將它們的外積累加成 16x16 輸出。縮小 K 尺寸甚至無關緊要！
我們簡化一下這個問題，并隱式轉置矩陣乘法。A 和 B（輸入）都將 K（縮減維度）作為主導維度。這在實踐中并不重要，但它大大簡化了我們的代碼。
這里有一個參考，可用來檢查我們提出的解決方案：
void reference_16x16xK (float *A, float *B, float *C, uint64_t K) {
for (uint32_t m = 0; m < 16; ++m) {
for (uint32_t n = 0; n < 16; ++n) {
C [n * 16 + m] = 0;
for (uint32_t k = 0; k < K; ++k) {
C [n * 16 + m] += A [k * 16 + m] * B [k * 16 + n];
}
}
}
}下面是我們在 AMX 中的實現方法：
/only set for k == 0uint64_t reset_z = 1ull << 27;
for (uint32_t k = 0; k < K; ++k) {
uint64_t idx = k % 4;
// 64 bytes = 16 floats
AMX_LDX ((uint64_t) A + k * 64);
AMX_LDY ((uint64_t) B + k * 64);
//now we do 4 indepedent outer products (avoiding pipeline hazards)
AMX_FMA32 (reset_z);
reset_z = 0;
}
神奇的是，我們沒有處理任何寄存器，但卻悄悄做了些處理。以同樣的方式將 reset_z 編碼為位掩碼，寄存器地址也編碼在傳遞給 AMX_* 的參數中。指向 A 和 B 的指針最多只能使用 56 位，因此蘋果工程師將信息存儲在其他 8 位中。我們只是意外將其全部設置為 0。因此，在本例中，對 X 和 Y 我們將寄存器置 “0”。
將 Z 寄存器存儲到內存的代碼有點復雜，因為我們只填充了第一列。所以需要獲取寄存器 0、4、8 等：
for (uint64_t i = 0; i < 16; ++i) {
const uint64_t z_register = (i * 4ull) << 56;
AMX_STZ (z_register | (uint64_t) C + i * 64);
}但你會發現，運行上面的代碼非常慢。只有區區幾百 GFlops。
為什么會這樣？有兩個原因。
開始的減速是流水線冒險。每個 AMX_FMA32 都依賴于前一個，因為全都累積到寄存器文件的一個子集中。我們最終只達到了寄存器文件全節流的 25%，剩余部分閑置，未能實現指令級并行。
接下來的問題是從內存中加載的效率很低。我們其實可以一次加載 128 個字節，但上面的代碼只能加載 64 個字節。類似地，可以加載到其他寄存器，不必每次都加載到相同的寄存器。也可以實現一定程度的指令級并行。
那么計劃是什么？
我們將向 X 和 Y 加載 128 個字節，然后計算一個 32x32 塊。這將涉及 16x16 塊的 4 次獨立計算，形成指令級并行，可以更高效利用加載的內存（每個 64 字節寄存器使用兩次）。
void mm32x32xK (float* A, float* B, float* C, uint64_t K) {
//flag to load/store 128 bytes
const uint64_t load_store_2 = 1ull << 62;
const uint64_t load_store_width = 128; //in bytes
//only set for k == 0
uint64_t reset_z = 1ull << 27;
for (uint32_t k = 0; k < K; ++k) {
uint64_t idx = k % 4;
//load to X, Y (skipping every other index because we're loading 128 bytes)
AMX_LDX (load_store_2 | (idx * 2) << 56 | (uint64_t) A + k * load_store_width);
AMX_LDY (load_store_2 | (idx * 2) << 56 | (uint64_t) B + k * load_store_width);
//offset into X and Y registers is byte-wise
const uint64_t offset = idx * load_store_width;
//now we do 4 indepedent outer products (avoiding pipeline hazards)
AMX_FMA32 (reset_z | (0ull << 20) | ((offset + 0ull) << 10) | ((offset + 0ull) << 0));
AMX_FMA32 (reset_z | (1ull << 20) | ((offset + 64ull) << 10) | ((offset + 0ull) << 0));
AMX_FMA32 (reset_z | (2ull << 20) | ((offset + 0ull) << 10) | ((offset + 64ull) << 0));
AMX_FMA32 (reset_z | (3ull << 20) | ((offset + 64ull) << 10) | ((offset + 64ull) << 0));
reset_z = 0;
}
for (uint64_t i = 0; i < 16; ++i) {
//store interleaved
AMX_STZ (load_store_2 | ((i * 4ull + 0) << 56) | (uint64_t) C + i * load_store_width);
AMX_STZ (load_store_2 | ((i * 4ull + 2) << 56) | (uint64_t) C + (16 + i) * load_store_width);
}
}void mm32x32xK (float* A, float* B, float* C, uint64_t K){
//flag to load/store 128 bytes const uint64_t load_store_2 = 1ull << 62; const uint64_t load_store_width = 128; //in bytes
//only set for k == 0 uint64_t reset_z = 1ull << 27;
for (uint32_t k = 0; k < K; ++k) { uint64_t idx = k % 4; //load to X, Y (skipping every other index because we're loading 128 bytes) AMX_LDX (load_store_2 | (idx * 2) << 56 | (uint64_t) A + k * load_store_width); AMX_LDY (load_store_2 | (idx * 2) << 56 | (uint64_t) B + k * load_store_width);
//offset into X and Y registers is byte-wise const uint64_t offset = idx * load_store_width;
//now we do 4 indepedent outer products (avoiding pipeline hazards) AMX_FMA32 (reset_z | (0ull << 20) | ((offset + 0ull) << 10) | ((offset + 0ull) << 0)); AMX_FMA32 (reset_z | (1ull << 20) | ((offset + 64ull) << 10) | ((offset + 0ull) << 0)); AMX_FMA32 (reset_z | (2ull << 20) | ((offset + 0ull) << 10) | ((offset + 64ull) << 0)); AMX_FMA32 (reset_z | (3ull << 20) | ((offset + 64ull) << 10) | ((offset + 64ull) << 0)); reset_z = 0; }
for (uint64_t i = 0; i < 16; ++i) { //store interleaved AMX_STZ (load_store_2 | ((i * 4ull + 0) << 56) | (uint64_t) C + i * load_store_width); AMX_STZ (load_store_2 | ((i * 4ull + 2) << 56) | (uint64_t) C + (16 + i) * load_store_width); }}我在上面添加了注釋，關于說明性標志有些有趣的細節。Corsix 在解釋這一點上做得很好，所以我要留下鏈接：
- 加載和存儲標志：https://github.com/corsix/amx/blob/main/ldst.md
- FMA 標志：https://github.com/corsix/amx/blob/main/fma.md
那么我們到底能有多快？這一定程度上取決于 K，但我們達到了 1.5TFlops 處理的問題更大相對來說會獲得更好的性能，這也不足為奇，因為緩存可以更好地預熱，CPU 有更多時間交錯指令。
總的來說，在當今大型神經網絡競相追逐通用 AI 的背景下，這類問題顯得微不足道，然而卻為小型神經網絡在現實計算中找到一席之地。如果一個預測模型可于幾十納秒內在電池供電的筆記本上運行，或將為原本可能使用探試算法的地方帶來更多價值。你怎么看？
原文鏈接：https://jott.live/markdown/1.5tflop_m1?
