Tag: intel

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」。

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

Amazon EC2 上的一些小常識

在 Twitter 上看到 Laravel News 轉發了「Mistakes I've Made in AWS」這篇，講 Amazon EC2 上面的一些小常識。

在 EC2 中，T 系列的機器 (目前主要是 t2/t3/t3a/t4g) 對於開發很好用，甚至對於量還不大的 production system 也很好用，加上 Unlimited 模式可以讓你在 CPU credit 用完時付錢繼續 burst。

文章裡面有討論到，使用 T 系列機器時，常常是不怎麼需要大量 CPU 資源的情境，這時候 AMD-based 的 t3a 通常都是個還不錯的選擇，大概會比 Intel-based 的 t3 省 10% 的費用。另外如果可以接受 ARM-based 的話，t4g 也是個選項，價錢會更便宜而且在很多應用下速度會更快。不過同事有遇到 Python 上面跑起來的行為跟 x86-64-based 的不同，這點就得自己琢磨了...

另外就是目前的 EBS 預設還是會使用 gp2，而在 gp3 出來後其實大多數的情況下應該可以換過去，主要就是便宜了 20%，加上固定的 3000 IOPS。

不過也是有些情境下是不應該換的，主要是 gp2 可以 burst 到 250MB/sec，但 gp3 只給了 125MB/sec。雖然 gp3 可以加價買 throughput，但加價的費用不低，這種需求改用 gp2 應該會比較划算。

不過這邊推薦比較技術的作法，可以掛兩個 gp3 (也可以更多) 跑 RAID0 (像是在 Linux 上可以透過 mdadm 操作)，這樣 IOPS 與 throughput 都應該可以拉上來...

Amazon EC2 推出 m6i 的機器

AWS 給了公告，在 Amazon EC2 上面推出了 m6i 的 Intel-based 新機種：「New – Amazon EC2 M6i Instances Powered by the Latest-Generation Intel Xeon Scalable Processors」。

這好像是第一次看到 Intel-based 機種加上了 i 的 suffix...

這次比較大的兩個差異，與 m5 相比，多出了 m6i.32xlarge：

A larger instance size (m6i.32xlarge) with 128 vCPUs and 512 GiB of memory that makes it easier and more cost-efficient to consolidate workloads and scale up applications.

另外看了一下 us-east-1 上的單價，看起來與 m5 系列的機器價錢一樣，但是效能提昇了 15% (然後很假掰的寫了 price/performance？)：

Up to 15% improvement in compute price/performance.

單以數字看起來的話還是 m6g 系列會比較香？當然如果只有 x86-64 binary 的話看起來還是可以考慮換到 m6i 上跑...

又再次看到了 Spectre Mitigation 的效能損失...

Hacker News 首頁上看到的文章，講 Spectre Mitigation 的效能損失：「Spectre Mitigations Murder *Userspace* Performance In The Presence Of Frequent Syscalls」，對應的討論串在「Spectre Mitigations Murder Userspace Performance (ocallahan.org)」。

看起來作者是在調校 rr 時遇到的問題，幾年前有提到過 rr：「Microsoft 的 TTD 與 Mozilla 的 RR」。

對此作者對 rr 上了一個 patch，減少了 mitigation code 會在 syscall 時清掉 cache 與 TLB，這個 patch 讓執行的速度大幅提昇：「Cache access() calls to avoid syscalls」。

另外作者提到了他的硬體是 Intel 的 Skylake，他又再跑一次 pre-patch 與 post-patch 的速度，可以看到在 pre-patch 前，mitigation 會讓系統慢超多 (從 2m5.776s 到 3m19.648s)，而 post-patch 後大幅降低 syscall 的使用，就不會影響那麼多 (從 0m33.422s 到 0m36.160s)。

就目前知道的 mitigation 方式來說，這個猜測應該是對的...

從調校 HTTP Server 的文章中學各種奇技淫巧

在「Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance」這篇文章裡面，作者在示範各種奇技淫巧調教校 HTTP server。

在 Hacker News 上的討論也蠻有趣的：「Extreme HTTP Performance Tuning (talawah.io)」。

雖然是在講 HTTP server，但裡面有很多東西可以拿出來獨立用。

想特地拿出來聊的大項目是「Speculative Execution Mitigations」這段，作者有些說明，除非你真的知道你在做什麼，不然不應該關掉這些安全相關的修正：

You should probably leave the mitigations enabled for that system.

而作者是考慮到 AWS 有推出 AWS Nitro Enclaves 的前提下決定關掉，但我會建議在 *.metal 的機器上才這樣做，這樣可以避免這台機器上有其他 AWS 帳號的程式在跑。

測試中關了一卡車 mitigation，得到了 28% 的效能提昇：

Disabling these mitigations gives us a performance boost of around 28%.

這其實比預期中多了不少，這對於自己擁有實體機房跑 Intel 平台的使用者來說，很吸引人啊...

Let's Encrypt 升級資料庫伺服器 (AMD YES？)

Let's Encrypt 升級了 MariaDB 資料庫的伺服器 (跑 InnoDB)，特地寫了一篇文章出來講：「The Next Gen Database Servers Powering Let's Encrypt」。

CPU 的部份從本來的 2x Intel Xeon E5-2650 (Total 24 cores / 48 threads) 換成了 2x AMD EPYC 7542 (Total 64 cores / 128 threads)，這點在本來就是 CPU 滿載的情境下改善很大：

而本來的瓶頸一解決，也使得 API 的 latency 直接降下去：

回頭看一下架構，可以看到他們提到沒有使用分散式的資料庫，而是單台 database 硬撐，驗證了即使到了 Let's Encrypt 這種規模，以暴制暴還是很有效的：

We run the CA against a single database in order to minimize complexity. Minimizing complexity is good for security, reliability, and reducing maintenance burden. We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary.

除了 CPU 暴力外，2TB RAM 與 24 顆 NVMe SSD 的搞法也是很讚的，擺明就是用記憶體拼 cache 的量，以及用大量的 NVMe SSD 疊 IOPS。

然後硬體還在成長，看起來暴力解應該會變成以後的基本答案了...

Amazon EC2 的新機種：R5b、D3 (D3en)、C6gn、M5zn、G4ad

Amazon EC2 除了昨天放出 Mac mini 消息打頭陣以外，其他機種的更新消息也陸陸續續公佈了：

比較有趣的 (對我而言)，第一個是 ARM 架構的機器也推出 100Gbps 的 n 版本 c6gn，看起來很適合跑大流量的東西，馬上想到的就是自架的 memcached？

另外是 m5zn，使用高頻率的 Intel Xeon，主打需要單核效率的程式，不過這是掛在 m 系列下，而不是 c 系列...

再來是使用 AMD GPU 的 g4ad，官方宣稱跟 NVIDIA 的 g4dn 比起來，將會有 45% 的 C/P 值提昇，是個蘇媽跟老黃的對決：

However, when compared to G4dn the new G4ad instances enable up to 45% better price performance for graphics-intensive workloads, including the aforementioned game streaming, remote graphics workstations, and rendering scenarios. Compared to an equally-sized G4dn instance, G4ad instances offer up to 40% improvement in performance.

看起來 ARM 的消息沒有想像中的多...

升級跳板機

算是做個記錄...

差不多是 2014 年的時候，因為 xDSL 網路的頻寬拉起來比較夠用了，加上當時發生一些事情，而且 HiNet 的 PPPoE 可以申請發一個固定 IP (即「非固固 IP」)，所以就用這個功能架了一台小的 server，這樣一來就有一台小的 server 可以用，另外很多 firewall 之類的操作就方便很多。

當時買的機子是 Gigabyte 的 GB-XM12-3227，Intel i3-3227 + 4GB RAM + 128GB mSATA SSD：

幾年前 CPU 風扇掛過一次，去淘寶上挖了一顆回來後又可以繼續用。

不過後來在上面跑的東西愈來愈多，加上現在的軟體開發愈來愈吃各種資源 (就算只是 command line 環境)，i3-3227 的 CPU Benchmarks 跑分也才 1274，記憶體也只裝了 4GB，跑起來還是愈來愈吃力... 大概在年初的時候就有打算要換，直到看到了這個機殼的影片：

我買了一個機殼回來 (還找到 $350 含運的店家)，在客廳裝了一台 Intel J1900 + 8GB RAM 的機器接電視用 (不過這又是另外一個故事了)，對這款機殼還算滿意，就再去下了一顆回來...

接下來就是湊其他的零件了，既然這次要拿來當半個開發機用，上面的等級要好一點，但又不希望太吃電 (畢竟是一直開著的機器)，所以就找了一顆二手的 Intel i3-8100T (35W，CPU Benchmarks 分數 5319)，然後在 PChome 24h 上面找了張 H310 的主機板，一個全新的 350W 電源供應器，以及 2*16GB RAM + 500GB SATA SSD。風扇的話是之前 Intel E3-1230 v3 留下來的風扇 (現在上面是掛水冷)，扣具的位置是相同的 (LGA115x)，就直接拿來用了。

弄好後裝個 Ubuntu 20.04，然後在只有兩顆風扇的環境下 (電源供應器的風扇與 CPU 風扇)，CPU idle 只有 35 度上下，壓測也只有 55 度上下，本來還在糾結後方要不要還是裝個 8cm 系統風扇，後來決定還是放一顆上去好了，用負壓的方式把熱帶出來。

如果之後真的遇到灰塵太多的問題，再考慮用先前在「無風扇系統的 CPU 散熱片」提到的方案來換：

接下來就是搭車把機器帶老家裝，就順便被老人家餵食：

回家升級跳板機，然後就被餵食了...

換完後當然如同預期的速度快不少，接下來應該會考慮把線路升級到 300M/100M (現在只有 100M/40M)，不過看起來 IP 一定會變，就比較麻煩了，之後再看看機會...

Apple M1 的效能與省電原因

在 Hacker News Daily 上看到 Apple M1 為什麼這麼快又省電的解釋，可以當作一種看法：

可以在 Thread reader 上面讀：「Thread by @ErrataRob on Thread Reader App – Thread Reader App」。

看起來 Apple 在規劃的時候就有考慮 x86 模擬問題，所以在記憶體架構上直接實做了對應的模式，大幅降低了當年 Microsoft 在 Surface 上遇到的問題：

3/ The biggest hurdle was "memory-ordering", the order in which two CPUs see modifications in memory by each other. It's the biggest problem affecting Microsoft's emulation of x86 on their Arm-based "Surface" laptops.

4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering.

另外一個比較有趣的架構是，Apple M1 上面的兩個 core 有不同的架構，一顆對效能最佳化，另外一顆對效率最佳化：

13/ Apple's strategy is to use two processors: one designed to run fast above 3 GHz, and the other to run slow below 2 GHz. Apple calls this their "performance" and "efficiency" processors. Each optimized to be their best at their goal.

在 wikipedia 上的介紹也有提到這兩個 core 的不同，像是 L1 cache 的差異 (128KB 與 192KB)，以及功耗的差異：

The M1 has four high-performance "Firestorm" and four energy-efficient "Icestorm" cores, providing a configuration similar to ARM big.LITTLE and Intel's Lakefield processors. This combination allows power-use optimizations not possible with Apple–Intel architecture devices. Apple claims the energy-efficient cores use one tenth the power of the high-performance ones. The high-performance cores have 192 KB of instruction cache and 128 KB of data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB instruction cache, 64 KB data cache, and a shared 4 MB L2 cache. The Icestorm "E cluster" has a frequency of 0.6–2.064 GHz and a maximum power consumption of 1.3 W. The Firestorm "P cluster" has a frequency of 0.6–3.204 GHz and a maximum power consumption of 13.8 W.

再加上其他架構上的改善 (像是針對 JavaScript 的指令集、L1 的提昇，以及用 TSMC 最新製程)，累積起來就變成把 Intel 版本壓在地上磨蹭的結果了...

AMD 的 Ryzen 5000 系列

這幾年 Intel 在 CPU 市場上被 AMD 打的不是很像樣，但因為單核效能高不少 (看起來是利用高時脈拼)，勉強在遊戲市場上還能打 (程式最佳化問題 XD)。

但前幾天蘇媽家發表了新的 CPU，看起來這次 AMD 十一月要推出的 Ryzen 5000 系列 (Zen 3 架構) 會打破這個平衡：「AMD Ryzen 5000 and Zen 3 on Nov 5th: +19% IPC, Claims Best Gaming CPU」。

官方宣稱每個 clock 會有 19% 的效能成長，這表示在單顆核心上面的速度會增加：

The key element of the new product is the core design, with AMD’s latest Zen 3 microarchitecture, promising a 19% raw increase in performance-per-clock, well above recent generational improvements.

不過看了一下，同樣是 8c16t 的規格下，Zen 2 的 3700X 只要 65W，但同樣規格到 Zen 3 上就到了 5800X 的 105W，但一路上到 16c32t 的 5950X 也都還是 105W 就是了...

3700X 的頻率是 3.6/4.4 (Base/Turbo)，對比的 5800X 則上拉一些到 3.8/4.7，而頂規 5850X 則是幹到了 3.4/4.9，這離 Intel 的 5.2 愈來愈近了。

另外官方分析的 19% 是這些累積出來的：

+2.7% Cache Prefetching
+3.3% Execution Engine
+1.3% Branch Predictor
+2.7% Micro-op Cache
+4.6% Front End
+4.6% Load/Store

對市場是個好消息，而且還是 AM4 腳位，現有主機板有推出韌體更新就有機會直接支援...

等真的有評測的時候再來看看各個吃 CPU 的遊戲的情況...