用 x86 組語寫的 web forum

另外一個在週末看到的奇怪東西,用 x86 組語寫的 web forum:「AsmBB – a lightweight web forum engine written in assembly language (asmbb.org)」,官網在 asmBB 這邊,說明則是在「What is AsmBB?」這頁。

是個 x86 assembly + SQLite 的組合:

AsmBB is fully written in assembly language and uses SQLite as a database back-end. That is why it can work on really weak hosting and in the same time serve huge amount of visitors without lags and delays.

程式碼是用 Fossil 管的,不過作者有 mirror 到 GitHub 上:「johnfound/asmbb」。

SQlite 的部分用了 SQLeet,可以在 sqleet.inc 這個檔案裡面看到引用了 libsqleet.so

AsmBB uses SQLite with SQLeet extension as a back-end storage database and FastCGI interface to the web server.

組語的部分看起來是用 fasm 寫的,看程式碼 (像是 encryption.asm) 可以看到一些好用的語法,像是自動處理 function 參數的部分 (應該有設定某種 convention),跟當年寫 MASM 的用法方便不少:

stdcall TextCreate, sizeof.TText
mov     edx, eax

stdcall TextCat, edx, <"Content-type: text/html; charset=utf-8", 13, 10, 13, 10>
stdcall RenderTemplate, edx, 'crypto.tpl', 0, esi

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 層級了:

差不多就這些...

Windows 10 的 IE 將會有 asm.js 支援

Twitter 上看到的:「Bringing asm.js to the Chakra JavaScript engine in Windows 10」。

這樣只剩下 Safari 還沒支援,其他幾個主流瀏覽器都支援了:(出自維基百科「asm.js」條目)

Mozilla Firefox was the first web browser to implement asm.js-specific optimizations, starting with Firefox 22. The optimizations of Google Chrome's V8 JavaScript engine in Chrome 28 made asm.js benchmarks more than twice as fast as prior versions of Chrome.