Tag: cpu

CPU Core 之間溝通的時間成本

在 Hacker News 上看到「Measuring CPU core-to-core latency (github.com/nviennot)」這篇，專案在「Measuring CPU core-to-core latency」這裡，看起來是個有趣的研究，測試許多不同 CPU 內，跨 core 之間溝通的時間花費。

依照專案的說明，測試的方式是利用 cache coherence 來來量測：

We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.

By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.

裡面已經測了很多不同的 CPU，然後可以看到一些有趣的結果。

像是第一張圖片的「Intel Core i9-12900K @ 8+8 Cores (Alder Lake, 12th gen) 2021-Q4」這組，大家還蠻好奇 CPU #8 到底是怎麼一回事，跨 core 溝通的 latency 特別低，還特別找了 CPU 的 die 圖片看看：

另外一個是 AWS 上的 c6a.metal，機種是「AMD EPYC 7R13 @ 48 Cores (Milan, 3rd gen) 2021-Q1」，可以看到被分成了六個區塊：

接下來在 ARM 平台，在更多 CPU core 的 c7g.16xlarge 上，機種「AWS Graviton3 @ 64 Cores (Arm Neoverse, 3rd gen) 2021-Q4」，會看到更多不平均的現象：

早一點的 c6gd.metal 雖然也還是 ARM 的 64 cores 機種「AWS Graviton2 @ 64 Cores (Arm Neoverse, 2nd gen) 2020-Q1」，但可以看到很不一樣的 latency pattern：

大致上可以感覺到當 core 數愈多就會有很多技術上的瓶頸，導致不同 core 之間的溝通成本不一樣... 這個感覺跟當初學到 NUMA 的情況有點像。

Amazon EC2 有 Mac (M1) 機種可以租用了

2020 年年底的時候 AWS 推出用 Mac mini 配合搭建出 Mac (Intel) 機種：「Amazon EC2 推出 Mac Instance」，當初有計畫在 2021 年推出 M1 的版本：

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021.

不過就沒什麼意外的 delay 了，這次則是推出了 M1 的版本：「New – Amazon EC2 M1 Mac Instances」。

依照說明看起來還是 Mac mini，掛上 AWS Nitro System：

EC2 Mac instances are dedicated Mac mini computers attached through Thunderbolt to the AWS Nitro System, which lets the Mac mini appear and behave like another EC2 instance.

然後跟 Intel 版本一樣，因為是掛進 Dedicated Hosts 的計價方式，雖然是以秒計費，但還是設定最低 24 小時的租用時間限制：

Amazon EC2 Mac instances are available as Dedicated Hosts through both On Demand and Savings Plans pricing models. The Dedicated Host is the unit of billing for EC2 Mac instances. Billing is per second, with a 24-hour minimum allocation period for the Dedicated Host to comply with the Apple macOS Software License Agreement. At the end of the 24-hour minimum allocation period, the host can be released at any time with no further commitment.

Intel 版本代號是 mac1，只有一種機種 mac1.metal，M1 版本代號是 mac2，也只有一種機種 mac2.metal。

以最經典的美東一區 us-east-1 來看，mac1.metal 的 on-demand 價錢是 US$1.083/hour，mac2.metal 則是 US$0.65/hour，差不多是 60% 的價錢，便宜不少，大概是反應在硬體攤提與電費成本上了。

另外目前大家用 M1 的經驗來看，Rostta 2 未必會比原生的機器慢多少，雖然 mac1.metal 是 12 cores，mac2.metal 是 8 core，但以雲上面一定要用 Mac 跑的應用來說，馬上想的到的還是綁在 Apple 環境裡 CI 類的應用？

目前看起來主要的問題還是 24 小時的最小計費單位讓彈性低不少...

這次 OpenSSL 的兩個 CVE

難得在 Hacker News 首頁上看到 OpenSSL 的 CVE：「OpenSSL Security Advisory [5 July 2022]」，相關的討論在「OpenSSL Security Advisory (openssl.org)」。

第一個 CVE 是 RCE 等級，但觸發條件有點多：

首先是 RSA 2048bits，這個條件應該算容易發生的。

第二個是，因為這個安全問題是因為 OpenSSL 3.0.4 才引入的程式碼，而 OpenSSL 3.0.4 是 2022/06/21 發表的，未必有很多人有升級。

第三個是，因為這次出包的段落是用到了 AVX-512 指令集，一定要 Intel 或是 Centaur 的 CPU，後面這家公司前身就是威盛 (VIA) 的一員，去年賣給了 Intel (然後發現連官網用的 domain 都沒續約...)。

而 AMD 雖然在 Zen 4 架構上支援 AVX-512，但還沒推出產品，所以直接閃避 XD

另外第三個還有額外的限制，因為這次用到的是 IFMA 指令集，所以也不是所有有支援 AVX-512 的 CPU 都會中獎：

只看 Intel 的部份，第一個支援 IFMA 的是 2018 年推出的 Cannon Lake，這個架構只有一顆行動版的 Intel® Core™ i3-8121U Processor。

真正大量支援 IFMA 的是 2019 後的 Intel CPU 了，但到了去年推出的 Alder Lake 因為 E-core 不支援 AVX-512 的關係 (但 P-core 支援)，預設又關掉了。

所以如果問這個 bug 嚴不嚴重，當然是很嚴重，但影響範圍就有點微妙了。

接下來講第二個 CVE，是 AES OCB 的實做問題，比較有趣的地方是 Hacker News 上的討論引出了 Mosh 的作者跳出來說明，他居然提到他們在二月的時候試著換到 OpenSSL 的 AES OCB 時有測出這個 bug，被 test case 擋下來了：

Mosh uses AES-OCB (and has since 2011), and we found this bug when we tried to switch over to the OpenSSL implementation (away from our own ocb.cc taken from the original authors) and Launchpad ran it through our CI testsuite as part of the Mosh dev PPA build for i686 Ubuntu. (It wasn't caught by GitHub Actions because it only happens on 32-bit x86.) https://github.com/mobile-shell/mosh/issues/1174 for more.

So I would say (a) OCB is widely used, at least by the ~million Mosh users on various platforms, and (b) this episode somewhat reinforces my (perhaps overweight already) paranoia about depending on other people's code or the blast radius of even well-meaning pull requests. (We really wanted to switch over to the OpenSSL implementation rather than shipping our own, in part because ours was depending on some OpenSSL AES primitives that OpenSSL recently deprecated for external users.)

Maybe one lesson here is that many people believe in the benefits of unit tests for their own code, but we're not as thorough or experienced in writing acceptance tests for our dependencies.

Mosh got lucky this time that we had pretty good tests that exercised the library enough to find this bug, and we run them as part of the package build, but it's not that farfetched to imagine that we might have users on a platform that we don't build a package for (and therefore don't run our testsuite on).

這有點有趣 XDDD

AWS 推出 c7g 機種

AWS 在 Amazon EC2 產品線上推出了新一代的 ARM 產品，AWS Graviton3 架構，c7g 系列機種：「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」。

Graviton3 宣稱比 Graviton2 多 25% 的一般性效能，以及多了一倍的浮點效能，還有 DDR5 的頻寬優勢：

Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.

在「FreeBSD on the Graviton 3」這邊也可以看到一些效能數據 (雖然是跑在 FreeBSD 上)，可以看到基本上符合 AWS 的宣稱。

目前只有 us-east-1 與 us-west-2 有這個機種，不過 Graviton 系列一直都是 AWS 的強主打項目，其他區域應該很快就會看到：

C7g instances are initially available in US East (N. Virginia) and US West (Oregon) AWS Regions; other Regions will be added shortly after launch.

價位上比 c6g 貴了一些，在 us-east-1 上 c7g.16xlarge (64 vCPU + 128 GB RAM) 是 US$2.32/hour，而 c6g.16xlarge 是 US$2.176/hour，大約貴了 6.6%，但如果是 CPU bounded 的應用來說，應該還是蠻划算的。

另外一方面是等後續的 m7g 與 r7g 系列出現...

用 objdump 學到的一些東西...

在 Hacker News 首頁上看到「Hand-optimizing the TCC code generator (briancallahan.net)」這則，原始文章在「Hand-optimizing the TCC code generator」這邊。

主要是在文章內看到 objdump 這個東西，作者用這兩個指令看組語：

tcc -c true.c
objdump -d true.o

另外同樣道理也可以用 gcc -c true.c 看 GCC 轉出來的版本。

倒出來的組語是 AT&T 語法，但我熟悉的是 Intel 語法，對我的直覺上需要習慣... 另外我看了一下 GCC 編出來的組語：

0000000000000000 <main>:
   0:   f3 0f 1e fa             endbr64 
   4:   55                      push   %rbp
   5:   48 89 e5                mov    %rsp,%rbp
   8:   b8 00 00 00 00          mov    $0x0,%eax
   d:   5d                      pop    %rbp
   e:   c3                      retq

第一行的那個 endbr64 指令沒看過，查一下發現原來是 Intel 在 CPU 層設計出來的安全機制，標示這個地方可以被 indirect call 進來：「What does the endbr64 instruction actually do?」。

至於文章裡面主要提到的 mov $0x0, %eax 可以用 xor %eax, %eax 代替 (或是 sub %eax, %eax) 算是很久前就會的東西了...

Pointer tagging

在 Hacker News 上看到「Pointer Tagging for x86 Systems (lwn.net)」這篇，在講目前的 64 bits 環境下還不可能提供整個 64 bits 可以定位的位置，所以 pointer 裡面比較高的那些位置就可以被拿來挪去其他用的想法。

先算了一下數字，如果以 8 bits 為一個單位來算，之前經典的 32 bits 定位空間是 4GB，40 bits 是 1TB，這兩個都已經有機器可以做到了 (AWS 提供的 u-12tb1.112xlarge 是 12TB)。

接下來的 48 bits 的時候可以到 256TB，這個不確定目前有沒有單一機器可以做到 (印象中 IBM 好像很喜歡幹這個？)，56 bits 則是到 64PB，最後的 64 bits 則是 16EB。

真的是沒注意到...

從三角函數 cosine 的實做問題學一些週邊知識...

前幾天在 Hacker News 上看到「Implementing Cosine in C from Scratch (2020) (austinhenley.com)」這篇 2020 的文章，原文是「Implementing cosine in C from scratch」，裡面內在講自己刻三角函數的 cosine 所遇到的一些嘗試。

cosine 是很基本的函數，所以可以使用的地方很多。另外一方面，也因為他不是那麼直覺就可以實做出來，在現代的實做裡面其實藏了超多細節...

不過真的有趣的是在翻 Hacker News 上的討論時陸陸續續翻其他的資料看到的知識。

第一個看到的是 Intel 對於 FPU-based 指令集內的 FSIN 因為 π 的精度不夠而導致誤差超大 (尤其是在 0 點附近的時候)：「Intel Underestimates Error Bounds by 1.3 quintillion」，然後 AMD 是「相容」到底，所以一樣慘：「Accuracy of FSIN and other x87 trigonometric instructions on AMD processors」。

這個就是有印象，但是太久沒有提到就會忘記...

第二個是 musl libc 裡的 cosine 實做 (看註解應該是從 FreeBSD 的 libc 移植過來的？)：「__cos.c\math\src」與「cos.c\math\src」(話說 cgit 在 html 內 title 的內容對路徑的表達方式頗有趣，居然是反過來放...)。

拆開的部份是先將範圍限制在 [-\pi/4, \pi/4] 後 (這個部份看起來是透過 __rem_pio2.c 處理)，再丟進公式實際運算。

另外帶出來第三個知識，查資料的時候翻到 binary64 (這也是 C 語言裡面的 double) 與 binary128 的差異：

而大家很常拿來惡搞的 double double 則是利用兩個 double 存放，形式是 v = head + tail，利用不同的 exponent 表示來不同部份的值，以提高經度：

A common software technique to implement nearly quadruple precision using pairs of double-precision values is sometimes called double-double arithmetic.

不過這樣的精確度只能到 106 bits，雖然跟 binary128 能達到的 113 bits 相比低了一些，但在大多數的情況下也還算夠用：

Using pairs of IEEE double-precision values with 53-bit significands, double-double arithmetic provides operations on numbers with significands of at least[4] 2 × 53 = 106 bits (...), only slightly less precise than the 113-bit significand of IEEE binary128 quadruple precision.

Mac 上 sprintf 的 scalability 問題

在 Hacker News 上看到個有趣的 scalability 問題，在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題：「Curious lack of sprintf scaling (aras-p.info)」。

作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題，要注意到這邊的 Y 軸是對數比例：

用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」)：

然後用了 Instruments 跑 profiling 找問題，可以看到看起來跟 locale 有關：

一般的情況下應該不會是問題，但如果是需要大量 sprintf() 組字串的人就會比較要注意了。

在「What else can we do?」這段有提到一些解法，包括了 stb_sprintf 當作替代品，以及 {fmt} 作為 iostreams 的替代品，然後另外是利用 to_chars 來解決，如果只是要把數字轉成字串。

算是蠻有趣的 bug hunting 過程，對於開發者來說，一般性的重點還是在 profiling，找到對的問題然後再往下提出解法...

Amazon EC2 推出 c6a 的機器

Amazon EC2 以新的 AMD 架構 (雖然也推出一陣子了) 的機器推出 c 系列的機種，代號為 c6a：「New – Amazon EC2 C6a Instances Powered By 3rd Gen AMD EPYC Processors for Compute-Intensive Workloads」。

價位上與 c5a 相比便宜一點點，是真的一點點：在 us-east-1 的 c5a.24xlarge 是 US$3.696/hr，而 c6a.24xlarge 是 US$3.672，差 0.65% 左右... (千分之六點五 XD)

所以宣稱的 15% 基本上都是從 CPU 效能提昇貢獻的：

Up to 15 percent improvement in compute price performance.

然後機器可以提供的範圍比較大台，c5a 最大到 c5a.24xlarge，而 c6a 支援了 c6a.32xlarge 與 c6a.48xlarge。

目前亞洲區都還沒上，要再等等了：

C6a instances are available today in three AWS Regions: US East (N. Virginia), US West (Oregon), and EU (Ireland). As usual with EC2, you pay for what you use. For more information, see the EC2 pricing page.

另外這次推出後，EC2 的機種超過 500 種了，主要是靠排列組合弄出來的：

PS – With the launch of C6a instances there are now officially more than 500 Amazon EC2 instances for customers to choose from!

Raspberry Pi OS 64-bit 與 32-bit 的效能差異

前幾天提過「Raspberry Pi OS 64-bit 版本正式推出」，而 Phoronix 實際拿正式版測試 64-bit 與 32-bit 的系統差異了，在「Raspberry Pi OS 32-bit vs. 64-bit Performance」這邊可以看到每一個測試項目的結果。

測試的硬體是 Raspberry Pi 400，這台機器基本上就是 4GB 版本的 Raspberry Pi 4 加上週邊配件：

Using a Raspberry Pi 400 keyboard computer with 4GB of RAM, I ran some fresh benchmarks of Raspberry Pi OS in its default 32-bit build and then again with the new 64-bit build.

先講結果，在 Phoronix 的 33 個測試裡面，64-bit 全部都比 32-bit 好，而且是很明顯的差異：

Across the few dozen different workloads tested, switching Raspberry Pi OS 11 for the 64-bit version improved the performance on average by about 48%. See all the 32-bit vs. 64-bit Raspberry Pi benchmarks over on OpenBenchmarking.org.

之前 64-bit OS 還在 beta 的時候就已經知道這個情況了，所以不會覺得太意外。當時提出的解釋是指令集的差異，aarch64 提供的指令集比 armv6 有效率多了，這點在 2016 年的文章「64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions」這邊可以看到說明。

所以正式版出來以後，只要硬體有支援，基本上都建議裝 64-bit OS 了...