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

差不多就這些...

Firefox 宣布從 Mercurial 換到 Git

Firefox 宣佈從 Mercurial 換到 Git:「Firefox Development Is Moving From Mercurial To Git」。

目前是 Mercurial 與 Git 都支援,理由是不想要維持兩套:

For a long time Firefox Desktop development has supported both Mercurial and
Git users. This dual SCM requirement places a significant burden on teams which
are already stretched thin in parts. We have made the decision to move Firefox
development to Git.

不過不知道決策的過程到底是怎麼產生的,算是 Mozilla 的老問題了...

OpenTF 開張

前陣子有提到因為 HashiCorp 沒有正面回應 (如預期的) 授權的爭議,所以決定將最後一個 open source 版本的 Terraform 給 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」。

剛剛在 Hacker News 上看到「OpenTF repository is now public (github.com/opentffoundation)」這個,OpenTF 正式開張了。

瞄了一下 issues,初期還有蠻多雜事得處理的,但跨出第一步了,可以看看社群的能量到底有沒有超過 HashiCorp 自家的能量...

Rocky Linux 提出兩個方法取得 RHEL 的 source code

在「AlmaLinux 與 Rocky Linux 看起來都暫時無解」這邊提到了檯面上目前沒有好方法穩定取得 source code 後,Rocky Linux 提出了兩個方法,在不需要同意 RHEL 的條款下取得 RHEL 的 source code:「Keeping Open Source Open」。

中間還有一些小插曲可以提一下,在社群不少抗議聲後,IBM & Red Hat 的 VP 出來直接說他們認為 RHEL rebuild 沒有任何價值,而且是故意讓 rebuilder 更難實作 RHEL rebuild:「Red Hat’s commitment to open source: A response to the git.centos.org changes」。

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

回到 Rocky Linux 的文章,他們提出來的兩個方法都是基於 GPL 的重要性質:如果你可以合法拿到 binary,那麼散佈者就有義務要提供 source code。

第一個方法是透過 RHEL 目前公開提供的 container image:

One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.

另外一種方式是透過雲端服務的 cloud instance 跑 RHEL:

Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.

這兩個方法都不需要同意 RHEL 目前在網站上的 TOS 與 EULA,而且短時間內應該不好防堵:前者要關掉的話,應該有一堆既有 RHEL 客戶在用會直接抱怨,真的要硬幹的話得給這些客戶時間從 public repository 轉移到要認證的 repository 上;而後者要堵的話,除非 IBM & Red Hat 決定直接不做雲端生意?

看起來 Rocky Linux 與 AlmaLinux 用這套方法可以撐一陣子,直到 IBM & Red Hat 想出新方法來搞?

AlmaLinux 與 Rocky Linux 看起來都暫時無解

昨天提到的「IBM 決定停止公開發布 RHEL 的 source code」有了另外一邊的說明了:

如同 AlmaLinux 所說的,重新散佈程式碼是受限的:

Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.

所以目前 AlmaLinux 的意思是沒有什麼好解法,而 Rocky Linux 的公告文章只有幹話,沒有實質內容。

但我猜既有的客戶裡面有不受這個條款影響的族群,像是直接跟 IBM 談授權合約的公司,有可能會有排除單方面修改授權的條款,這個應該會是目前 RHEL 8/9 的破口,但後續再釋出的版本應該會被 IBM 的法務給補上?

IBM 決定停止公開發布 RHEL 的 source code

Hacker News 首頁上看到的新聞,IBM 決定停止公開發布 RHEL 的 source code:「Red Hat cutting back RHEL source availability」,原始的文章在「Furthering the evolution of CentOS Stream」這邊。

可以猜測這與 Rocky LinuxAlmaLinux 有關。

有購買 RHEL 的人 (取得 binary 的人) 可以在 Red Hat Customer Portal 上取得 source code,這部份應該是遵守 GPL 的關係。

但不確定後續 Rocky Linux 與 AlmaLinux 會怎麼處理,看了看 GPLv2 裡面的條文,不是很確定是否可以限制散佈 source code 的行為...

透過 ControlNet 產生出來的 QR code

Hacker News Daily 上看到「Redditor creates working anime QR codes using Stable Diffusion」這個,Reddit 的原討論串在「ControlNet for QR Code」這邊。

透過 ControlNet 產生出來的 QR code 超出一般對客製化 QR code 的想像... 這邊就不解釋直接上圖了:





改善 Wikipedia 的 JavaScript,減少 300ms 的 blocking time

Hacker News 首頁上看到「300ms Faster: Reducing Wikipedia's Total Blocking Time」這篇,作者 Nicholas RayWikimedia Foundation 的工程師,雖然是貼在自己的 blog 上,但算是半官方性質了... 文章裡面提到了兩個改善都是跟前端 JavaScript 有關的。

作者是透過瀏覽器端的 profiling 產生火焰圖,判讀裡面哪塊是大塊的問題,然後看看有沒有機會改善。

先看最後的成果,可以看到第一個 fix 讓 blocking time 少了 200ms 左右,第二個 fix 則是少了 80ms 左右:

第一個改善是從火焰圖發現 l._enable 吃掉很多 blocking time:

作者發現是因為 find() 找出所有的連結後 (a 元素),跑去每一個連結上面綁定事件造成的效能問題:

The .on("click") call attached a click event listener to nearly every link in the content so that the corresponding section would open if the clicked link contained a hash fragment. For short articles with few links, the performance impact was negligible. But long articles like ”United States” included over 4,000 links, leading to over 200ms of execution time on low-end devices.

但這其實是 redundant code,在其他地方已經有處理了,所以解法就比較簡單,拔掉後直接少了 200ms:

Worse yet, this behavior was unnecessary. The downstream code that listened to the hashchange event already called the same method that the click event listener called. Unless the window’s location already pointed at the link’s destination, clicking a link called the checkHash method twice — once for the link click event handler and once more for the hashchange handler.

第二個改善是 initMediaViewer 吃掉的 blocking time,從 code 也可以看到問題也類似,跑一個 loop 把事件掛到所有符合條件的元素上面:

這邊的解法是 event delegation,把事件掛到上層的元素,就只需要掛一個,然後多加上檢查事件觸發的起點是不是符合條件就可以了,這樣可以大幅降低「掛」事件的成本。

這點算是常用技巧,像是 table 裡面有事件要掛到很多個 td 的時候,會改成把一個事件掛到 table 上面,另外加上判斷條件。

算是蠻標準的 profiling 過程,直接拉出真實數據來看,然後調有重大影響的部分。

提議 OpenJDK 的程式碼 UTF-8 化

Hacker News 上看到提議把 OpenJDK 的程式碼 UTF-8 化:「Make JDK source code UTF-8 (openjdk.org)」,原始的 jira ticket 在「Make JDK source code UTF-8」這邊。

主要是現在的 source code 沒有統一標準:

Currently, the source code in the JDK is in an ill-defined encoding. There is no official declaration of the encoding used. It is "mostly ASCII", but the relatively few non-ASCII characters used are not well-defined. In many cases, it is latin-1, but I am pretty certain other encodings are used for e.g. Asian translations.

而 mailing list 上看起來還是有想要維持 ASCII 的討論:「Making the source code utf-8」,不過他提出來的理由我覺得不太行,在 console 跑 vi 或是 emacs 我覺得不太是個好理由...

GitHub 自己開發的搜尋引擎

前陣子 GitHub 發了一篇文章,說明自己開發搜尋引擎的心路歷程:「The technology behind GitHub’s new code search」。

看了一下其實就是自己幹了一套 search engine cluster,然後針對 code search 把一些功能放進去。

目前這套 search enginer 還是 beta 版本,全站兩億個 repository 只包括了 4500 萬 (大概 22% 左右),然後已經有 115TB 的程式碼了;另外也題到了先前導入 Elasticsearch 時的數字是 800 萬個 repository:

GitHub’s scale is truly a unique challenge. When we first deployed Elasticsearch, it took months to index all of the code on GitHub (about 8 million repositories at the time). Today, that number is north of 200 million, and that code isn’t static: it’s constantly changing and that’s quite challenging for search engines to handle. For the beta, you can currently search almost 45 million repositories, representing 115 TB of code and 15.5 billion documents.

目前是 32 台機器,沒有特別提到記憶體大小,也沒有提到 replication 之類的數字:

Code search runs on 64 core, 32 machine clusters.

然後各種 inverted index 與各種資料在壓縮後只有 25TB:

There are some big wins on the size of the index as well. Remember that we started with 115 TB of content that we want to search. Content deduplication and delta indexing brings that down to around 28 TB of unique content. And the index itself clocks in at just 25 TB, which includes not only all the indices (including the ngrams), but also a compressed copy of all unique content. This means our total index size including the content is roughly a quarter the size of the original data!

換算一下,就會發現現在已經是「暴力」可以解很多事情的年代了,而這已經是全世界最大的 code hosting。

以前隨便一個主題搞大一點就會撞到 Amdahl's law,現在輕鬆不少...