Google Chrome 對 CPU bug 的 patch

既然有方向了,後續應該會有人去找底層的問題...

先是在 Hacker News 上看到「Speculative fix to crashes from a CPU bug」這個猜測性的修正,這是因為他們發現在 IntelGemini Lake 低功耗晶片組上會發生很詭異的 crash:

For the last few months Chrome has been seeing many "impossible" crashes on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes only happen with 64-bit Chrome and only happen in the prologue of two functions. The crashes come and go across different Chrome versions.

然後依照 crash log 猜測跟 alignment 有關,所以決定用 gcc/clang 都有支援的 __attribute__ 強制設定 alignment 來避開,但看起來手上沒有可以重製的環境,所以只能先把實做丟上來...

Windows 上的 Chrome 改用 Clang 編譯

這應該是上個禮拜蠻熱鬧的一件事情 (i.e. 很多人看熱鬧 XD),就是 Google ChromeVisual C++ 改成用 Clang 編譯:「Clang is now used to build Chrome for Windows」。

文章裡推敲效能應該不是主要的因素,因為在不同項目測試下各有千秋,而且差距都不大:

We conducted extensive A/B testing of performance. Performance telemetry numbers are about the same for MSVC-built and clang-built Chrome – some metrics get better, some get worse, but all of them are within 5% of each other.

後面有猜測換過去的原因,可以看出因為 open source 加上 Google Chrome 團隊有強大的技術能力下,用 open source 軟體可以對 compiler 大量客製化各種功能,另外也是因為一個 compiler 就可以吃多個平台,可以省下一些跨平台的力氣 (像是相容性語法)。

而 Visual C++ 在商業支援與文件兩方面比較好的優勢,在這個情況下就顯得不是那麼重要了...

Branchless UTF-8 解碼器

看到「A Branchless UTF-8 Decoder」這篇,先來回憶一下「非常經典的 UTF-8...」這篇,以及裡面提到的 encoding:

因為當初在設計 UTF-8 時就有考慮到,所以 decoding 很容易用 DFA 解決,也就是寫成一堆 if-then-else 的條件。但現代 CPU 因為 out-of-order execution 以及 pipeline 的設計,遇到 random branch 會有很高的效能損失,所以作者就想要試著寫看看 branchless 的版本。

成效其實還好,尤其是 Clang 上說不定在誤差內:

With GCC 6.3.0 on an i7-6700, my decoder is about 20% faster than the DFA decoder in the benchmark. With Clang 3.8.1 it’s just 1% faster.

而後來的更新則是大幅改善,在 Clang 上 DFA 版本比 branchless 的快:

Update: Björn pointed out that his site includes a faster variant of his DFA decoder. It is only 10% slower than the branchless decoder with GCC, and it’s 20% faster than the branchless decoder with Clang. So, in a sense, it’s still faster on average, even on a benchmark that favors a branchless decoder.

所以作者最後也有說這是個嘗試而已 XD:

It’s just a different approach. In practice I’d prefer Björn’s DFA decoder.

GCC 的警告參數

在「Useful GCC warning options not enabled by -Wall -Wextra」這邊提到 GCC 如果把這些參數放入 -Wall-Wextra 裡會產生出太多的誤判,但有些參數還是很有用。

不過這邊介紹的參數蠻多都需要 GCC 6+ 甚至 GCC 7+,翻了 Ubuntu 16.04 是 GCC 5.4。

這是文章介紹的參數的整理:

-Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict -Wnull-dereference -Wold-style-cast -Wuseless-cast -Wjump-misses-init -Wdouble-promotion -Wshadow -Wformat=2

另外一個比較特別的問題是,其實愈來愈多專案搬到 clang 上,這幾年可以看出能量的消長蠻明顯的...

Android NDK 宣佈向 Clang 靠攏...

Hacker News Daily 上看到 Android NDK 宣佈向 Clang 靠過去的消息:「Changelog for NDK Build 2490520」。

Android NDK 做為效能的加速手段而使用到 C 或是 C++,所以會使用對應的 compiler suite:

The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++. Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation.

而粗體的兩段則說明了遷移:

PSA: Everyone should be switching to Clang.

以及:

GCC in the NDK is now deprecated.

FreeBSD 10 的改變...

Zite 上看到 FreeBSD 10 的改變:「FreeBSD 10's New Technologies and Features」。

最耀眼的當然是對 GCC 的宣戰達到高潮,第一個將預設編譯器換掉的 major release。同樣的,也把 GNU 的 libstdc++ 換成 MIT license 實作的 libc++。

再來是 ISCBIND 被換掉,改用 Unbound 以及 LDNS

然後 UFS 檔案系統可以透過 growfs(8) 線上長大... XDDD

其他的改善包括了 iSCSI stack 重寫,PF 防火牆可以善用 SMP 資源,以及 ZFS 的更新。等正式出版後應該還是會等到 10.1 再上 production 吧?感覺 compiler 一換不知道會有多少雷啊 XD

FreeBSD 預設的 compiler 從 GCC 換成 clang

FreeBSD 預設的 compiler (/usr/bin/cc/usr/bin/c++/usr/bin/cpp) 從 GCC 4.2.1 換成 clang 了:「Revision 242624」。

目前只有 CURRENT 裡的 amd64 與 i386 版本換過去,如此一來,FreeBSD 10.0 會是第一個使用 clang 作為預設編輯器的正式版本 (看起來不像會 back port 回 FreeBSD 9)。接下來是 Ports 大混戰了,應該會有一卡車的 ports 用 USE_GCC=yes 來解?

從 2009 年的努力到現在三年多了 (參考「[ANNOUNCE]: clang/llvm can compile booting FreeBSD kernel on i386/amd64」這封公告信),離拔掉 GCC 4.2.1 又進了一大步...

FreeBSD 將在 10.0 時將預設編譯器從 GCC 換成 clang

FreeBSD 預定在今年十一月將 amd64 與 i386 版本的 C 與 C++ 預設編譯器從 GCC 4.2.1 換成 clang,也就是下一個 major release (10.0) 就會是預設編譯器:「Clang as default compiler November 4th」。

自從 GCC 決定要換成 GPLv3 後整個計畫才活起來,到現在走了三年,看起來明年應該有機會看到預設是使用 clang 的 FreeBSD?

接下來的工作是解決 Ports 裡面一堆用 clang 編不過的軟體,以目前「Ports and Clang」這邊列出來的數量,看起來把幾個大的傢伙解決掉就差不多了?(不過應該是不怎麼好解,不然這種大目標物應該早就解決了...)

clang 的進展...

OSnews 上看到 clang 2.8 與其他幾個 compiler 的比較:「Compiler Benchmarks of GCC, LLVM-GCC, DragonEgg, Clang」。

以測試結果來說,如果改用 Clang,有些會變得比較快,但也有些變得比較差。不過以 license 以及後勁來看,還蠻看好發展的。六月的時候在 FreeBSD 的 -HEAD 裡面變成 default compiler,預定 9.0-RELEASE 會是 FreeBSD 上第一個用 clang 的版本... (感謝 lwhsu 戳中)