Jump to...
redirecting...

Log for Ubuntu 台灣社群

anon
tokyo
BarraCUDA:鎖定 AMD GPU 的開源 CUDA 編譯器 (★ 205 分)

BarraCUDA 是一個以 C99 撰寫、約 1.5 萬行程式碼的開源 CUDA(NVIDIA 的 GPU 平行運算程式設計平台與語言擴充)編譯器,目標是把 .cu 原始碼直接編譯成 AMD RDNA 3(gfx1100/GFX11)可執行的機器碼,輸出為 ELF(Executable and Linkable Format,可執行與連結格式).hsaco(HSA Code Object,AMD GPU 可載入執行的程式物件)檔案。專案主打「零 LLVM(Low Level Virtual Machine,編譯器基礎建設)相依性」、不走 HIP(Heterogeneous-computing Interface for Portability,AMD 的 CUDA 類介面)轉譯層,也不要求先把 CUDA 改寫成其他語言或 API;作者形容這是試圖打破 NVIDIA「圍牆花園」的實作挑戰。雖然不使用 LLVM 來產出程式,但作者會用 `llvm-objdump` 交叉驗證指令解碼,宣稱目前做到「零解碼失敗」。建置流程也刻意維持極簡:直接 make,幾乎無外部套件相依。

其編譯流程包含前處理器(處理 #include、巨集與條件編譯)、詞彙分析、遞迴下降剖析器(產生 AST,抽象語法樹)、語意分析(型別檢查與作用域解析),再轉成自家的 BIR(BarraCUDA Intermediate Representation,中介表示)並以 SSA(Static Single Assignment,靜態單一指派)形式表達,接著做 mem2reg(將堆疊變數提升為暫存器的常見轉換),再由手寫的指令選擇將 BIR 對映到 AMDGPU 指令,完成暫存器配置(VGPR/SGPR,向量/純量暫存器),最後把 GFX11 指令編碼並輸出 ELF。作者也強調其實作風格偏向可預期與可控:資料結構多用預先配置的固定大小陣列、在熱路徑避免 malloc、避免遞迴並盡量使用有界迴圈,並在 README 分享多個 GFX11 編碼踩坑細節,反映 AMD ISA(Instruction Set Architecture,指令集架構)文件存在不一致之處。

就功能面而言,BarraCUDA 已能編譯相當多 CUDA 常用語法與特性到「可跑起來」的 GFX11 機器碼,包括 __global__/__device__/__host__、threadIdx/blockIdx 等內建索引、C 的各種控制流程、部分 C++ 範本(template)實例化、共享記憶體(__shared__,對應到 AMD 的 LDS)、__syncthreads()、多種原子操作、warp 相關內建(如 shuffle 與投票)、向量型別、半精度 __half、__launch_bounds__ 與 cooperative groups 等;編譯器本身也具備完整 C 前處理器與錯誤復原能力。作者同時列出尚未補齊的缺口(例如 const、複合指定運算子、__constant__、紋理/表面、動態平行、跨多個編譯單元與主機端程式產出等),並規劃接下來會先補齊語言缺口與強化最佳化(指令排程、更好的暫存器配置、常數折疊、死程式碼刪除、迴圈不變式外提與 occupancy 調校),長期則希望把同一套 BIR 後端延伸到 Tenstorrent、Intel Arc 乃至 RISC-V 向量延伸等其他架構。

在 Hacker News 的討論中,不少人稱讚它「make 就能建置」與整體完成度,認為更像是「從零打造 GPU 編譯器」的高含金量練功專案;但也有人指出,實務上多數 CUDA 專案倚重大量 C++ 特性與生態函式庫(如 BLAS,Basic Linear Algebra Subprograms;DNN,Deep Neural Network 相關函式庫),因此 BarraCUDA 目前更難直接取代機器學習工作負載的主流堆疊。多位留言者提到 ZLUDA(讓 CUDA 程式在非 NVIDIA GPU 上執行的相容層/轉譯專案)在「幾乎不改程式就能跑」的路線上更務實;也有人補充 AMD 其實長期以 ROCm(Radeon Open Compute,AMD 的 GPU 計算軟體堆疊)與 LLVM 後端耕耘生產環境,只是支援矩陣龐大且容易踩到相容性與效能問題。另有觀點認為 AMD 未必想「完整支援 CUDA」,因為那可能反而加深 NVIDIA 的平台護城河;也有人提醒 BarraCUDA 目前鎖定 GFX11(偏消費級 RDNA 3)而非資料中心常見的 CDNA,短期很難成為「CUDA 護城河終結者」。討論串也出現商標風險提醒(專案名稱含 CUDA 可能引來律師函),以及關於 AI 的爭論:有人把 LLVM 誤讀成 LLM(Large Language Model,大型語言模型)被其他人糾正;也有人從 README 的文字風格與 ASCII 圖質疑有大量 AI 痕跡,而作者親自回應承認會用 Ollama、Claude/ChatGPT 協助測試摘要、樣板程式與 ASCII 圖,並認為在熟練開發者手上屬合理用途。

👥 65 則討論、評論 💬
https://news.ycombinator.com/item?id=47052941
15 年後,微軟用 AI 抄壞了我的 GitFlow 分支示意圖(morged) (★ 233 分)

一篇 2010 年的經典文章〈A successful Git branching model〉讓 Git(分散式版本控制系統)的分支流程「GitFlow」廣為人知,作者當年還用 Apple Keynote 細緻設計了一張分支示意圖,反覆調色、調曲線與版面,讓不同分支隨時間推進的關係一目了然,並公開原始檔方便他人改作。這 15 年來,那張圖出現在書籍、演講、部落格、團隊 Wiki 甚至 YouTube 影片裡,他一直都不介意,因為本意就是分享知識。

但他近日被人在 Bluesky 與 Hacker News 標記,指向 Microsoft Learn(微軟官方學習文件入口)上的一張圖,外形明顯「很像」他的作品,卻看起來像是被丟進 AI 影像產生器後再輸出,頁面也沒有任何來源標註或連結回原文。更離譜的是,圖上把「continuously merged」變成 ` continvoucly morged ` 這種明顯的拼字崩壞,還伴隨箭頭缺漏或方向錯誤、註記消失、視覺對齊被弄亂等問題;作者形容這不是再創作,而是把原本好用的東西「洗掉指紋」後做得更差。他最沮喪的點在於流程與品質:為什麼學習資源可以在幾乎沒校對的情況下上線?他希望至少補上出處連結與署名,也想知道這頁文件與圖表到底是怎麼被產出、審閱並發布的;同時他也擔心,未來更多不那麼知名的內容會被更「像樣」地改寫或偽裝,讓抄襲更難辨識。

在 Hacker News 討論裡,最多人先把 ` continvoucly morged ` 當成迷因,甚至提議把「morge」當新動詞:指用 AI 產出「看得出來在抄、但品質很糟」的內容,或把垃圾內容硬塞進專案裡;也有人打趣延伸出「post morgem」。同時也出現技術面的糾正:有人把這種拼字錯誤歸咎於 LLM(Large Language Model,大型語言模型)「幻覺」不夠精準,因為這更可能是影像生成模型在畫字形時並不真正理解拼字與語意的結果。另有留言補充微軟後續已把該圖下架並換成另一張(但被嫌同樣不清楚),原版本則被網友用網頁存檔保留下來。

更多留言把事件拉到「AI 垃圾內容(AI slop)」與組織治理:有人引用微軟內部人士 Scott Hanselman(微軟開發者布道者)在 Bluesky 的說法,稱可能是外包廠商交付、團隊會做事後檢討並盡快移除;但不少人認為這種說法反而凸顯系統性問題,因為在大公司裡,能讓未署名、且肉眼一看就錯得離譜的素材進入官方文件,代表審稿與 QA(Quality Assurance,品質保證)關卡失靈。也有人類比到 LinkedIn 上常見的「拿別人的投影片叫 ChatGPT 改更好」卻不校對、導致文字與圖表意義被扭曲;甚至分享電商賣家用 AI 仿製圖樣印到商品上、字母全壞但仍照賣的案例,並擔憂這些錯誤內容會回流成新一輪訓練資料,形成越訓練越失真的惡性循環。少數人則提出較溫和的解釋:也可能是作者只要求 AI 畫出概念圖,模型因「過度擬合(overfitting)」而吐出近似記憶的圖樣,導致未必知道原作存在;也有人認為該圖太常見,讓人誤以為近似公領域,但反駁者指出即便如此,至少應該忠實重繪並標註來源。討論尾聲也有人順帶重提 GitFlow 本身在實務上頗具爭議,但整體情緒仍集中在:當「求快產出」凌駕署名與校對,官方文件也可能被「continvoucly morged」成一場公關與信任危機。

👥 75 則討論、評論 💬
https://news.ycombinator.com/item?id=47057829