Tag: amd

Amazon EC2 推出 m7a 系列的機種

上一篇完全讀錯段落了，重寫...

Amazon EC2 推出了新的 m7a 的機種：「New – Amazon EC2 M7a General Purpose Instances Powered by 4th Gen AMD EPYC Processors」。

號稱與 m6a 相比有 50% 效能上的提升：

Today, we’re announcing the general availability of new, general purpose Amazon EC2 M7a instances, powered by the 4th Gen AMD EPYC (Genoa) processors with a maximum frequency of 3.7 GHz, which offer up to 50 percent higher performance compared to M6a instances.

不過查了一下價錢，us-east-1 的 m6a.large 是 $0.0864/hr，m7a.large 則是 $0.11592/hr (都是 2 vCPU + 8GB RAM)，漲了 34% 左右，如果計算 price performance 的話大約是 10%～15%？的確是不高所以不提 price performance，不過這次 m7a 提供了更小台的 m7a.medium (1 vCPU + 4GB RAM) 來補這塊 (m6a 最小的是 m6a.large)，$0.05796/hr。

這樣看起來新的機種對於需要單核效能的應用應該會不錯？

再來是可以租到的區域，目前看起來只有歐美的傳統大區有，亞洲區還要再等等：

Amazon EC2 M7a instances are now available today in AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), and EU (Ireland).

AMD 平台上的 LLM 計算

前幾天在 Hacker News 上看到的文章：「Making AMD GPUs competitive for LLM inference (mlc.ai)」，原文在「Making AMD GPUs competitive for LLM inference」這邊。

Nvidia 在 GPU 上的各種運算這塊進來的很早，除了本家開發了很多工具以外，社群的支援度也很好。而 AMD 這邊就差了不少，但這也反應在顯卡的售價上面。

作者整理了同樣是 24GB VRAM 的顯卡出來，分別是 AMD 的 7900XTX，以及 Nvidia 的 3090 Ti 與新的 4090：

可以看出來縮然同樣 fp16 對應到的功耗差蠻多的，但單價低很多，對於業餘玩家偶而用來說，其實是個可以考慮的方案。

而他們的成果可以看出來效果其實不差，跑 Llama 2 的 model 可以看到 CP 值相當高：

看起來支援的主力在 ROCm 上，就效能與功耗的筆直來說其實是超越的？(或者保守一點的說，是在同一個水平上的)

現在算是 AMD 顯卡在追趕的過程，社群的力量看起來會是主力...

AWS 新推出的 m7a 宣稱比 m6a 多 50% 效能？

AWS 在「Introducing Amazon EC2 M7a instances (Preview)」這邊看到 m7a 會比 m6a 快 50% 的宣稱：

These instances deliver up to 50% greater performance on average compared to M6a instances.

目前還是 preview 階段，需要申請才有機會用，所以還不知道他的真實性能是怎麼樣？另外一方面，價錢也還沒查到... 但如果價錢不要漲太多的話，算一下好像有可能跟上 ARM 的 m7g 了？

另外這樣也就蠻值得期待會不會有 t4a？

Intel 用 AVX-512 加速 NumPy 的排序演算法被整合進主線了

Intel 用 AVX-512 加速 NumPy 排序的實做被整合進主線了：「「Intel Publishes Blazing Fast AVX-512 Sorting Library, Numpy Switching To It For 10~17x Faster Sorts」」。

GitHub 的 PR 在「ENH: Vectorize quicksort for 16-bit and 64-bit dtype using AVX512 #22315」這邊，可以看到相關的留言：

This patch adds AVX512 based 64-bit on AVX512-SKX and 16-bit sorting on AVX512-ICL. All the AVX512 sorting code has been reformatted as a separate header files and put in a separate folder. The AVX512 64-bit sorting is nearly 10x faster and AVX512 16-bit sorting is nearly 16x faster when compared to std::sort. Still working on running NumPy benchmarks to get exact benchmark numbers

16-bit int sped up by 17x and float64 by nearly 10x for random arrays. Benchmarked on a 11th Gen Tigerlake i7-1165G7.

有點「有趣」的情況是，AVX-512 在新的 Intel 消費級 CPU 被拔掉了，只有伺服器工作站的 CPU 有保留。而 AMD 的 Zen 4 則是跳下去支援 AVX-512...

另外在「Intel Publishes Fast AVX-512 Sorting Library, 10~17x Faster Sorts in NumPy (phoronix.com)」這邊當然也有人提到，如果用更廣泛的 AVX2 (寬度是 256bits) 加速的話應該也會有很大的進步才對？幾乎這十年的 CPU 都有 AVX2 了... 不過看起來沒有什麼深入的討論？

Netflix 的 Open Connect 機器往 800Gbps 推進

2021 年的時候曾經提過 Netflix 試著用單機推出 400Gbps 的流量 (用在 Netflix 的 Open Connect)：「Netflix 在單機服務 400Gbps 的影音流量」，快一年後的目前，Netflix 的人已經成功推到接近 800Gbps 了：「Serving Netflix Video Traffic at 800Gb/s and Beyond」。另外在 Hacker News 上的討論「Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] (nabstreamingsummit.com)」也可以看看。

翻了一下投影片，最後衝到 720Gbps，主要是因為 NIC output drop，而非其他部份。

裡面還是把之前的故事也都講了一遍 (不然簡報的時間會太短？)，如果有看過前面的內容可以快速看一下就好，這次新的東西從 page 89 開始：

  • Asynchronous Sendfile (2014)
  • Kernel TLS (2016)
  • Network-centric NUMA (2019)
  • Inline Hardware (NIC) kTLS (2022)
  • 800G initial results

最後面幾張投影片裡面有提到往 800Gbps 衝的硬體平台：

  • AMD (EPYC 7713 CPUs)
  • Dell (PowerEdge R7525)
  • Mellanox/NVIDIA (ConnectX-6 Dx NICS)
  • Intel (P5316 NVME)

下個目標不知道是什麼，看起來目前已經壓榨到 memory bandwidth 也有點極限的感覺了...

Amazon EC2 推出 r6a 的機種

Amazon EC2 推出了 r6a (AMD) 的機種：「New – Amazon EC2 R6a Instances Powered by 3rd Gen AMD EPYC Processors for Memory-Intensive Workloads」。

看了一下美東的價錢，r6a 比 r5a 貴了一點點，其中 r6a.24xlarge 是 US$5.4432/hour，而 r5a.24xlarge 則是 US$5.424/hour。

官方宣稱與 r5a 相比有 35% 的 C/P 值改善：

Up to 35 percent higher price performance per vCPU versus comparable R5a instances

然後可以提供更大的機器，之前 r5a 的最大台機器是 r5a.24xlarge (96 vCPU + 768GB RAM)，但 r6a 則是拉到了 r6a.48xlarge 或是 r6a.metal (192 vCPU + 1536GB RAM)。

不過目前看起來支援的地區還有限，目前工作用到的 ap-southeast-1 看起來還要再等一下：

You can launch R6a instances today in the AWS US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai) and Europe (Frankfurt, Ireland) as On-Demand, Spot, and Reserved Instances or as part of a Savings Plan.

從三角函數 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.

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!

Netflix 在單機服務 400Gbps 的影音流量

在 Hacker News 首頁上看到 Netflix 在 EuroBSDCon 2021 上發表的投影片：「Serving Netflix Video at 400Gb/s on FreeBSD」，對應的討論則是在「Serving Netflix Video at 400Gb/s [pdf] (freebsd.org)」這邊可以翻到，投影片的作者有在上面回答一些問題。

投影片在講的應該就是 Netflix 的 Open Connect。

主要是因為 Open Connect 的伺服器是放到各家 ISP 機房，在單一 IP 且單一伺服器的限制下，要想辦法壓榨出最高的效能。

硬體是 AMD 的 EPYC，在先前的版本可以達到 240Gbps，經過分析與嘗試解決了一堆問題後，最後是在原來的 AMD 機器上跑到了 380Gbps (另外有測 ARM 以及 Intel 的數字)，然後之後機房有可能會有 800Gbps 的標準，他們又要繼續煩惱...

有看到 Mellanox ConnectX-6 Dx (CX6-DX) 這個東西，看起來很有趣啊，有 200Gbps 的能力，而且可以把 TLS 的事情推到卡上面處理... 然後這家公司被 Nvidia 買走了。

另外當然也會有人問為什麼不用 Linux，作者在討論串裡面也有回答一些，有興趣的可以自己去搜一下。

Intel 與 AMD 在 RSQRTSS 的不同

看到「rr Trace Portability: Diverging Behavior of RSQRTSS in AMD vs Intel」這個，作者因為在 rr 上發現 replay 不正確，發現是 SSE 裡面的 RSQRTSS 這個指令在 Intel 與 AMD 平台上會有不同的值出現導致的。

RSQRTSS 是計算平方根倒數，也就是計算 1 / \sqrt{x}，另外比較特別的是，這個指令不保證正確性，是允許有誤差產生的。

提到平方根倒數，這個演算法更有名的應該是「反平方根快速演算法」這個用到 0x5f3759df 這個魔術數字的奇技淫巧，不過這不是這次的重點...

作者發現 RSQRTSS 在 Intel 與 AMD 平台的值不一定一樣，像是 256 的平方根導數是 1/16 (0.0625)，但兩個平台跑出來不同：

On Intel Skylake I get
out = 3d7ff000, float = 0.062485

On AMD Rome I get
out = 3d7ff800, float = 0.062492

在這邊的 case 可以看出來 AMD 算的比較正確 (誤差值比較低)，但都還是在 spec 允許的誤差範圍。

後來作者還發現有其他不同的指令也有類似的問題，為了解決在 rr 上可以正確 replay 的問題，他生了對應的 mapping table 來解：「Emulating AMD Approximate Arithmetic Instructions On Intel」。

苦啊... 不過這個主題還蠻有趣的。