Nvidia CUDA 的 EULA 禁止跑在模擬層上面

Hacker News 上看到「Nvidia bans using translation layers for CUDA software to run on other chips (tomshardware.com)」這個討論串,原報導「Nvidia bans using translation layers for CUDA software — previously the prohibition was only listed in the online EULA, now included in installed files」。

文章最上面更新的這段把重點講完了,在 11.6 之後的版本就有加入這段文字了:

[Edit 3/4/24 11:30am PT: Clarified article to reflect that this clause is available on the online listing of Nvidia's EULA, but has not been in the EULA text file included in the downloaded software. The warning text was added to 11.6 and newer versions of the installed CUDA documentation.]

主要是這條:

You may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements for the purpose of translating such output artifacts to target a non-NVIDIA platform.

從「CUDA Toolkit Archive」這邊可以看到 11.6.0 是 2022 年一月的事情:

CUDA Toolkit 11.6.0 (January 2022), Versioned Online Documentation

看起來跟 ZLUDA 有關 (參考「IntelAMD GPU 直接跑 CUDA 程式的 ZLUDA」)。

時間軸看起來有對起來,2021 年的時候被 Intel 找去聊,2022 年的時候改跟 AMD 簽約,然後 AMD 後來也放掉:

In 2021 I was contacted by Intel about the development of ZLUDA. I was an Intel employee at the time. While we were building a case for ZLUDA internally, I was asked for a far-reaching discretion: not to advertise the fact that Intel was evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After some deliberation, Intel decided that there is no business case for running CUDA applications on Intel GPUs.

Shortly thereafter I got in contact with AMD and in early 2022 I have left Intel and signed a ZLUDA development contract with AMD. Once again I was asked for a far-reaching discretion: not to advertise the fact that AMD is evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs.

IntelAMD GPU 直接跑 CUDA 程式的 ZLUDA

先前提過「在 Intel 內顯上面直接跑 CUDA 程式的 ZLUDA」,結果後來事情大翻轉,AMD 跑去贊助專案,變成支援 AMD GPU 了:「AMD Quietly Funded A Drop-In CUDA Implementation Built On ROCm: It's Now Open-Source」,專案在 GitHubvosen/ZLUDA 這邊,而這包支援 AMD GPU 的 commit log 則是在 1b9ba2b2333746c5e2b05a2bf24fa6ec3828dcdf 這包巨大的 commit:

Nobody expects the Red Team

Too many changes to list, but broadly:
* Remove Intel GPU support from the compiler
* Add AMD GPU support to the compiler
* Remove Intel GPU host code
* Add AMD GPU host code
* More device instructions. From 40 to 68
* More host functions. From 48 to 184
* Add proof of concept implementation of OptiX framework
* Add minimal support of cuDNN, cuBLAS, cuSPARSE, cuFFT, NCCL, NVML
* Improve ZLUDA launcher for Windows

其中的轉折以及後續的故事其實還蠻不知道怎麼說的... 作者一開始在 Intel 上班,弄一弄 Intel 覺得這沒前景,然後 AMD 接觸後贊助這個專案,到後面也覺得沒前景,於是依照後來跟 AMD 的合約,如果 AMD 覺得沒前景,可以 open source 出來:

Why is this project suddenly back after 3 years? What happened to Intel GPU support?

In 2021 I was contacted by Intel about the development od ZLUDA. I was an Intel employee at the time. While we were building a case for ZLUDA internally, I was asked for a far-reaching discretion: not to advertise the fact that Intel was evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After some deliberation, Intel decided that there is no business case for running CUDA applications on Intel GPUs.

Shortly thereafter I got in contact with AMD and in early 2022 I have left Intel and signed a ZLUDA development contract with AMD. Once again I was asked for a far-reaching discretion: not to advertise the fact that AMD is evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs.

One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.

這個其實還蠻好理解的,CUDA 畢竟是 Nvidia 家的 ecosystem,除非你反超越後自己定義一堆自家專屬的功能 (像是當年 MicrosoftIE 上的玩法),不然只是幫人抬轎。

Phoronix 在 open source 前幾天先拿到軟體進行測試,而他這幾天測試的結果給了「頗不賴」的評價:

Andrzej Janik reached out and provided access to the new ZLUDA implementation for AMD ROCm to allow me to test it out and benchmark it in advance of today's planned public announcement. I've been testing it out for a few days and it's been a positive experience: CUDA-enabled software indeed running atop ROCm and without any changes. Even proprietary renderers and the like working with this "CUDA on Radeon" implementation.

另外為了避免測試時有些測試軟體會回傳到伺服器造成資訊外洩,ZLUDA 在這邊故意設定為 Graphics Device,而在這次 open source 公開後會改回正式的名稱:

In my screenshots and for the past two years of development the exposed device name for Radeon GPUs via CUDA has just been "Graphics Device" rather than the actual AMD Radeon graphics adapter with ROCm. The reason for this has been due to CUDA benchmarks auto-reporting results and other software that may have automated telemetry, to avoid leaking the fact of Radeon GPU use under CUDA, it's been set to the generic "Graphics Device" string. I'm told as part of today's open-sourcing of this ZLUDA on Radeon code that the change will be in place to expose the actual Radeon graphics card string rather than the generic "Graphics Device" concealer.

作者的測試看起來在不同的測試項目下差異頗大,但如果依照作者的計算方式,整體效能跟 OpenCL 版本差不多:

Phoronix 那邊則是做了與 Nvidia 比較的測試... 這邊拿的是同樣都有支援 Nvidia 與 AMD 家的卡的 Blender 測試,然後跑出來的結果讓人傻眼,透過 ZLUDA 轉譯出來的速度比原生支援的速度還快,這 optimization 看起來又有得討論了:(這是 BMW27 的測試,在 Classroom 的測試也發現一樣的情況)

但即使如此,CUDA over AMD GPU 應該還是不會起來,官方會儘量讓各 framework 原生支援,而大多數的開發者都是在 framework 上面開發,很少會自己從頭幹...

AMD 在 AM4 腳位上再出四顆 CPU...

看到 AMD 的新聞稿楞了一下:「AMD Reveals Next-Gen Desktop Processors for Extreme PC Gaming and Creator Performance」。

出了四顆 5000 系列的 CPU 在 AM4 主機板上使用:

New AMD Ryzen™ 5000 Series Desktop Processors Bring More Performance to Legacy Socket AM4 Platforms

其中 5700X3D 這顆價錢算是很殺的 (US$249),對於吃 CPU cache 很重的遊戲會是個有趣的選擇,先前 X3D 最便宜的是 5800X3D (US$449),這顆算是個有趣的玩具...

另外 5500GT 這顆 US$125 也是個蠻有趣的產品,剛剛翻了一下原價屋上的 5600G 是 $4970,換算大約是 US$160,不確定是不是屬於輕量機種的範圍... (像是組給家裡老人家用?)

意外的讓 AM4 平台又多了一些硬體可以玩?

AMD 推出 16GB 的 RX 7600 XT

看到「AMD Unveils AMD Radeon RX 7600 XT Graphics Card – Incredible Gaming at 1080p and Beyond for Under $350」這篇,16GB VRAM 官方的定價在 US$329...

剛好昨天寫的「Mixtral 8x7B 的論文出來了」提到了 Nvidia 的 3060 Ti 的 16GB 版本是跑 LLM 的窮人選擇,因為 12GB VRAM 的卡官方訂在 US$329,目前售價大約在 NT$9000 (~US$300) 左右。

這次 AMD 這張 16GB VRAM 美國定價是 US$329,剛好跟 3060 Ti 12GB 版本相同,這下 entry level 的市場就瞬間變得有趣了起來,雖然說 AMD 這邊的軟體支援度是差了一些,但最近算是急起直追,對於想要追求 CP 值的群眾來說還蠻有吸引力的?

後續來追看看台灣的售價...

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇:「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」,原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報,提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal(),透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal(),直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy()memmove() 類的地方,算是很常見備用到的功能,這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到:「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」,所以後續應該也會有些改善的討論...

Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這,上游的 glibc 也有對應的追蹤:「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息,因為 patch space 的大小限制,AMD 可能無法提供 CPU microcode 上的 patch,直接解決問題:

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround,回到原來沒有 FSRM 的方式處理:

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境,得拿出不同的 profiling 工具出來用,所以也還蠻值得看過一次有個印象:

一開始的 timeit 算是 Python 裡面簡單的 benchmark library:

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑),查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+):

再來是用 strace 追問題,這個算是經典工具了,可以拿來看 syscall 被呼叫的時間點:

到後面出現了 perf 可以拿來看更底層的資訊,像是 CPU 內 cache 的情況:

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式,不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析:

而文章裡的則是可以看到已經到 assembly 層級了:

差不多就這些...

Amazon EC2 推出 m7a 系列的機種

上一篇完全讀錯段落了,重寫...

Amazon EC2 推出了新的 m7a 的機種:「New – Amazon EC2 M7a General Purpose Instances Powered by 4th Gen AMD EPYC Processors」。

號稱與 m6a 相比有 50% 效能上的提升:

Today, we’re announcing the general availability of new, general purpose Amazon EC2 M7a instances, powered by the 4th Gen AMD EPYC (Genoa) processors with a maximum frequency of 3.7 GHz, which offer up to 50 percent higher performance compared to M6a instances.

不過查了一下價錢,us-east-1m6a.large 是 $0.0864/hr,m7a.large 則是 $0.11592/hr (都是 2 vCPU + 8GB RAM),漲了 34% 左右,如果計算 price performance 的話大約是 10%~15%?的確是不高所以不提 price performance,不過這次 m7a 提供了更小台的 m7a.medium (1 vCPU + 4GB RAM) 來補這塊 (m6a 最小的是 m6a.large),$0.05796/hr。

這樣看起來新的機種對於需要單核效能的應用應該會不錯?

再來是可以租到的區域,目前看起來只有歐美的傳統大區有,亞洲區還要再等等:

Amazon EC2 M7a instances are now available today in AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), and EU (Ireland).

AMD 平台上的 LLM 計算

前幾天在 Hacker News 上看到的文章:「Making AMD GPUs competitive for LLM inference (mlc.ai)」,原文在「Making AMD GPUs competitive for LLM inference」這邊。

Nvidia 在 GPU 上的各種運算這塊進來的很早,除了本家開發了很多工具以外,社群的支援度也很好。而 AMD 這邊就差了不少,但這也反應在顯卡的售價上面。

作者整理了同樣是 24GB VRAM 的顯卡出來,分別是 AMD 的 7900XTX,以及 Nvidia 的 3090 Ti 與新的 4090

可以看出來縮然同樣 fp16 對應到的功耗差蠻多的,但單價低很多,對於業餘玩家偶而用來說,其實是個可以考慮的方案。

而他們的成果可以看出來效果其實不差,跑 Llama 2 的 model 可以看到 CP 值相當高:

看起來支援的主力在 ROCm 上,就效能與功耗的筆直來說其實是超越的?(或者保守一點的說,是在同一個水平上的)

現在算是 AMD 顯卡在追趕的過程,社群的力量看起來會是主力...

AWS 新推出的 m7a 宣稱比 m6a 多 50% 效能?

AWS 在「Introducing Amazon EC2 M7a instances (Preview)」這邊看到 m7a 會比 m6a 快 50% 的宣稱:

These instances deliver up to 50% greater performance on average compared to M6a instances.

目前還是 preview 階段,需要申請才有機會用,所以還不知道他的真實性能是怎麼樣?另外一方面,價錢也還沒查到... 但如果價錢不要漲太多的話,算一下好像有可能跟上 ARMm7g 了?

另外這樣也就蠻值得期待會不會有 t4a

Intel 用 AVX-512 加速 NumPy 的排序演算法被整合進主線了

IntelAVX-512 加速 NumPy 排序的實做被整合進主線了:「「Intel Publishes Blazing Fast AVX-512 Sorting Library, Numpy Switching To It For 10~17x Faster Sorts」」。

GitHub 的 PR 在「ENH: Vectorize quicksort for 16-bit and 64-bit dtype using AVX512 #22315」這邊,可以看到相關的留言:

This patch adds AVX512 based 64-bit on AVX512-SKX and 16-bit sorting on AVX512-ICL. All the AVX512 sorting code has been reformatted as a separate header files and put in a separate folder. The AVX512 64-bit sorting is nearly 10x faster and AVX512 16-bit sorting is nearly 16x faster when compared to std::sort. Still working on running NumPy benchmarks to get exact benchmark numbers

16-bit int sped up by 17x and float64 by nearly 10x for random arrays. Benchmarked on a 11th Gen Tigerlake i7-1165G7.

有點「有趣」的情況是,AVX-512 在新的 Intel 消費級 CPU 被拔掉了,只有伺服器工作站的 CPU 有保留。而 AMDZen 4 則是跳下去支援 AVX-512...

另外在「Intel Publishes Fast AVX-512 Sorting Library, 10~17x Faster Sorts in NumPy (phoronix.com)」這邊當然也有人提到,如果用更廣泛的 AVX2 (寬度是 256bits) 加速的話應該也會有很大的進步才對?幾乎這十年的 CPU 都有 AVX2 了... 不過看起來沒有什麼深入的討論?

Netflix 的 Open Connect 機器往 800Gbps 推進

2021 年的時候曾經提過 Netflix 試著用單機推出 400Gbps 的流量 (用在 Netflix 的 Open Connect):「Netflix 在單機服務 400Gbps 的影音流量」,快一年後的目前,Netflix 的人已經成功推到接近 800Gbps 了:「Serving Netflix Video Traffic at 800Gb/s and Beyond」。另外在 Hacker News 上的討論「Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] (nabstreamingsummit.com)」也可以看看。

翻了一下投影片,最後衝到 720Gbps,主要是因為 NIC output drop,而非其他部份。

裡面還是把之前的故事也都講了一遍 (不然簡報的時間會太短?),如果有看過前面的內容可以快速看一下就好,這次新的東西從 page 89 開始:

  • Asynchronous Sendfile (2014)
  • Kernel TLS (2016)
  • Network-centric NUMA (2019)
  • Inline Hardware (NIC) kTLS (2022)
  • 800G initial results

最後面幾張投影片裡面有提到往 800Gbps 衝的硬體平台:

  • AMD (EPYC 7713 CPUs)
  • Dell (PowerEdge R7525)
  • Mellanox/NVIDIA (ConnectX-6 Dx NICS)
  • Intel (P5316 NVME)

下個目標不知道是什麼,看起來目前已經壓榨到 memory bandwidth 也有點極限的感覺了...