AWS 推出 c7g 機種

AWSAmazon 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-1us-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-1c7g.16xlarge (64 vCPU + 128 GB RAM) 是 US$2.32/hour,而 c6g.16xlarge 是 US$2.176/hour,大約貴了 6.6%,但如果是 CPU bounded 的應用來說,應該還是蠻划算的。

另外一方面是等後續的 m7gr7g 系列出現...

用 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.cGCC 轉出來的版本。

倒出來的組語是 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-1c5a.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.32xlargec6a.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 了...

Ribbon filter

RocksDB 的 blog 上看到「Ribbon Filter」這個,主要是 RocksDB 從 6.15 開始支援 Ribbon filter,取代本來的 Bloom filter 機制。

RocksDB 的 wiki 上面是說用 CPU 資源換 memory 的使用量:

A new Bloom filter alternative is available as a drop-in replacement (since version 6.15.0), saving about 30% of Bloom filter space (most importantly, memory) but using about 3-4x as much CPU on filters. Most of the additional CPU time is in the background jobs constructing the filters, and this is usually a good trade because it is common for SST filters to use ~10% of system RAM and well under 1% of CPU.

論文則是在「Ribbon filter: practically smaller than Bloom and Xor」這邊可以看到,Facebook 之前也有提到 Ribbon filter:「Ribbon filter: Practically smaller than Bloom and Xor」,在 Hacker News 上有對應的討論可以翻:「Ribbon filter: Practically smaller than Bloom and Xor (fb.com)」。

在 Ribbon filter 的資料裡面都提到了 Xor filter 當作比較,先前在「比 Bloom filter 與 Cuckoo filter 再更進一步的 Xor filter」這邊有提到 Xor filter。

用 CPU 去換記憶體,算是特化的版本...

在 Minecraft 裡面幹出一台完整的電腦

Lobsters Daily 上看到有強者在 Minecraft 實做邏輯電路,幹出一台完整的電腦出來 (CPU 的部份應該是 turing-complete 了):

PCWorld 有報導:「This 8-bit processor built in Minecraft can run its own games」。

把影片裡的描述截圖出來:

連分支預測器都出現了:

記憶體就 Minecraft 來說也是超大的 256 bytes:

然後還做了 cache 層,這邊提到的是 data cache:

然後這邊是 instruction cache:

也因為已經相當的 powerful,很多經典遊戲都可以玩,像是俄羅斯方塊:

貪食蛇:

打磚塊:

Connect Four

AWS 要推出 Graviton3 的機種了

AWS 打算要推出 Graviton3 的機種了,目前還在 preview 階段:「Join the Preview – Amazon EC2 C7g Instances Powered by New AWS Graviton3 Processors」。

目前是宣稱與前一代的 Graviton2 相比有 25% 的效能提昇,另外在浮點數與密碼相關的運算上面也會有改善 (這個效能提昇的數字應該是有指令集的幫助):

In comparison to the Graviton2, the Graviton3 will deliver up to 25% more compute performance and up to twice as much floating point & cryptographic performance. On the machine learning side, Graviton3 includes support for bfloat16 data and will be able to deliver up to 3x better performance.

另外提到了 signed pointer,可以避免 stack 被搞,不過這邊需要 OS 與 compiler 的支援,算是針對 stack 類的攻擊提出的防禦方案:

Graviton3 processors also include a new pointer authentication feature that is designed to improve security. Before return addresses are pushed on to the stack, they are first signed with a secret key and additional context information, including the current value of the stack pointer. When the signed addresses are popped off the stack, they are validated before being used. An exception is raised if the address is not valid, thereby blocking attacks that work by overwriting the stack contents with the address of harmful code. We are working with operating system and compiler developers to add additional support for this feature, so please get in touch if this is of interest to you.

然後是使用 DDR5 的記憶體:

C7g instances will be available in multiple sizes (including bare metal), and are the first in the cloud industry to be equipped with DDR5 memory. In addition to drawing less power, this memory delivers 50% higher bandwidth than the DDR4 memory used in the current generation of EC2 instances.

現在還沒看到價錢,不過有可能是跟 c6g 一樣的價位?但考慮到記憶體換架構,也有可能是貴一些的?

另外翻了一下資料,ARM 有發表過新聞稿提到 Graviton2 是 ARM 的 Cortex-M55 機種:「Designing Arm Cortex-M55 CPU on Arm Neoverse powered AWS Graviton2 Processors」,這次的 Graviton3 應該在之後完整公開後會有更多消息出來...