作者：Christopher Seidl，Arm
Arm Helium技術是Arm Cortex-M處理器產品系列的向量擴充(MVE)，它可以為小型的嵌入式裝置，針對機器學習(ML)與數位訊號處理(DSP)應用，帶來顯著的效能提升。Helium可協助克服許多應用項目的運算挑戰，例如音訊裝置、感測器中樞(sensor hubs)、關鍵詞辨識與語音指令控制、電力電子、通訊與靜態影像處理。在本文截稿前，有三款的Arm處理器支援Helium技術：Cortex-M52、Cortex-M55與Cortex-M85。
之前Arm曾發表多篇關於Helium以及該技術在實務上如何運作的文章。若想瞭解更多內容，歡迎閱讀這些系列文章，以及可用材料的綜合概述：從Armv8.1-M架構的處理器開始上手。
全新的架構特色可為市場帶來動力，至於如何運用這股力量，則又是另外一回事。許多年來，Cortex-M領域的軟體開發人員一直都擁有數個工具鏈選項。他們可以使用Arm的編譯器與其它商用的工具鏈，或是使用開源的GNU工具鏈(GCC)。Arm的晶片夥伴經常在出貨那些運用整合開發環境(IDE)開發的產品時，會順便附上GCC。因此，為次世代裝置實作Helium的合作夥伴可能要問：「那GCC的Helium支援性又如何？」
一個複雜的故事
由於Arm嵌入式編譯器(ACfE)是架構在LLVM工具鏈之上，首先我們也持續專注在為LLVM增添優異的自動向量化功能與通用的Helium支援性。關於這點，我們並未悄悄進行，反而是把我們的作業向上游分享給LLVM專案。因此，尋求免費工具鏈的合作夥伴與客戶在對具備Helium功能的裝置作業時，可以查看LLVM (或者直接使用我們的工具鏈)。
我們也正在努力強化Helium對GCC的支援性，儘管這部份需要時間；對於Helium來說，GCC可能也無法達到足以媲美LLVM的成熟度。
相關性能數據
我們已經使用不同的編譯器，以打造並執行不同的評量基準應用與實例專案。例如，AudioMark基準在Arm Cortex-M55上會顯示下列結果：
AudioMark的分數顯示， ACfE 6.21的性能與GCC13相比，高出了15%。LLVM17的分數只比ACfE 6.21低了6%。
諸如關鍵詞辨識等實際使用實例，也顯示出類似的結果：
在這張圖表中，柱狀部份是越短越好，原因是推論消耗更少的運算週期。GCC13與ACfE 6.21相比，幾乎額外耗用了16%的週期；LLVM17則是慢了5%。
最後，針對物件偵測也出現類似的結果：
GCC13比ACfE 6.21慢上了22%，至於LLVM17則是相當接近，只多使用了3%的運算週期。
結語
當我們推出Helium時，我們專注於最佳化LLVM架構的工具鏈，因為它是我們自己編譯器工具鏈的技術基礎。總結而言，倘若你有意要從搭載Helium技術的Arm核心獲取最佳的效能，建議您使用Arm嵌入式編譯器，或是免費的LLVM工具鏈。
我們將努力提升GCC的性能數據，但這將需要一些時間，而且它的成效或許永遠無法變得跟LLVM一樣。對於微控制器來說，LLVM是GCC之外一個可行且與時俱進的替代方案。
(參考原文：Which toolchain should I use for Helium?；中文版校閱者為Arm主任應用工程師林宜均；責編：Judith Cheng)
- 【Arm的AI世界】以Neoverse架構CPU解放RAG技術實力 - 2025/07/03
- 【Arm的AI世界】輕鬆運用虛擬平台與嵌入式評估套件加速終端AI應用開發 - 2025/06/06
- 【Arm的AI世界】以ExecuTorch和KleidiAI執行LLM推論 充分釋放行動端AI潛力！ - 2025/05/02
訂閱MakerPRO知識充電報
與40000位開發者一同掌握科技創新的技術資訊！
