The Controversy of std::simd in C++26

C++26 的到來帶來了一個新的標準化 SIMD (Single Instruction, Multiple Data) 函式庫 std::simd。雖然向量化 (vectorization) 的標準化是一個追求了十多年的目標，但其實現方式卻讓許多高效能運算 (HPC) 社群感到懷疑。核心的緊張關係在於對可移植性、高階抽象的需求，與進行嚴肅 SIMD 工作時所需的極致優化必要性之間的衝突。

The Promise of Portable Vectorization

多年來，C++ 開發者必須在依賴編譯器的自動向量化 (autovectorization)——這通常是不可預測且脆弱的——與編寫硬體特定的內建函式 (intrinsics) 之間做出選擇。內建函式提供最高的可能效能，但它們會將程式碼與特定架構綁定（例如 x86 AVX-512 或 ARM NEON/SVE）。

std::simd 旨在透過提供一個可移植的介面來彌補這一差距。其目標是讓開發者只需編寫一次向量程式碼，即可將其映射到目標硬體上最高效的指令。理論上，這能減輕可移植性的負擔，並允許編譯器處理類型與寬度到特定微架構的映射。

The Case Against: Why Abstractions Fail SIMD

批評者認為，通用型函式庫不可能捕捉到現代硬體的細微差別。SIMD 的效能不僅僅是將 load 或 add 操作映射到向量暫存器；它還涉及理解特定微架構的延遲 (latency)、吞吐量 (throughput) 以及特定的指令集。

正如一位經驗豐富的 SIMD 開發者所指出的：

Every abstraction, including autovectorization, is universally pretty poor outside of narrow cases because they don’t (and mostly can’t) capture what is possible with intrinsics and their rather extreme variation across microarchitectures. If I want good results, I have to write intrinsics.

從這個角度來看，std::simd 提供的可移植性是一個會放大效能損失的「差距」。對於從事「嚴肅工作」的 SIMD 開發者來說，精確控制硬體的能力是首要需求，而一個隱藏這些細節的可移植層會與高效能的目標根本性地背道而馳。

A History of Failed Proposals

C++ 標準中對 SIMD 的推動並非單一努力，而是一系列嘗試。早在 2011 年的提案就基於最終演變成 Eve 等函式庫的概念，但當時被委員會 rejected 拒絕了，原因與今日所引用的理由相同：難以映射到像 ARM 的 SVE 等架構，以及在向量操作中表達控制流的困難。

委員會甚至曾考慮過將類似 ISPC 的語義（一種用於 SIMD 編程的獨立語言）直接整合進 C++。然而，那條路徑被放棄了，轉而採用目前的函式庫方法。這表明了一種模式，即委員會試圖透過添加滿足理論上對可移植性需求的功能來維持「現代」形象，而非解決向量化中的根本性架構挑戰。

Who is std::simd For?

這引出了關鍵問題：std::simd 的目標受眾是誰？

• The High-Performance Expert: Likely will continue to use intrinsics, as the portability layer introduces an unacceptable performance penalty and the accuracy of the mapping is insufficient for optimal results.
• The Casual User: Developers who do not currently use SIMD because intrinsics are too difficult or intimidating may not be inclined to suddenly adopt std::simd just because it is a library.

最終，關於 std::simd 的爭論點出了 C++ 中的一個根本性衝突：在標準函式庫的可移植性與「零開銷抽象」之間取得平衡的掙扎。