幹壞事是進步最大的原動力
昨天把手上所有的 Amazon EBS 從 gp2 換到 gp3 了：「Amazon EBS 的 gp3 可以用在開機磁碟了」，今天早上來看一下狀態，整體看起來是還 OK，不過有些地方值得注意的，像是標題寫到的 latency。
我抓了跑 GitLab 的機器來看，可以很明顯看到讀寫的 latency 都變高了：
但 AWS 又有提到這些數字資料有經過轉換，看起來是 gp2 與 gp3 的數字意義本來就不一樣，所以他必須想辦法轉換，所以也有可能是因為這個轉換導致的？
This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.
不過其他的數字倒是沒什麼變化，系統的負荷量其實也還好，就先丟著跑...
Amazon EBS 的另外一個新推出的東西，是針對 io2 的改善：
前面兩則消息可以一起看，主要是推出了 EBS Block Express，有著效能上的提昇：
Built on our new EBS Block Express architecture that takes advantage of some advanced communication protocols implemented as part of the AWS Nitro System, the volumes will give you up to 256K IOPS & 4000 MBps of throughput and a maximum volume size of 64 TiB, all with sub-millisecond, low-variance I/O latency. Throughput scales proportionally at 0.256 MB/second per provisioned IOPS, up to a maximum of 4000 MBps per volume. You can provision 1000 IOPS per GiB of storage, twice as many as before. The increased volume size & higher throughput means that you will no longer need to stripe multiple EBS volumes together, reducing complexity and management overhead.
目前因為是 preview 階段，想要用的人需要申請測試。要注意目前支援的區域有限 (不像這次推出 gp3 的時候就是全區)，而且需要搭配 r5b 的機器：
The preview is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Europe (Frankfurt) Regions. During the preview, we support the use of R5b instances, with support for other Nitro-powered instances in the works.
第三則消息則是在講 io2 的 IOPS 的折扣，針對購買 32K IOPS 以上的部份會有 30% 折扣：
Now, with the new tiered pricing structure, the first 32,000 IOPS provisioned on a volume are charged at the current base rate ($0.065 per provisioned IOPS-mo) and the second tier between 32,001 and 64,000 is charged at a 30% lower rate ($0.046 per provisioned IOPS-mo).
針對前面提到的 preview 版本 (EBS Block Express)，因為可以超過 64K IOPS，這個部份的價錢會更低，再疊一次 30% 的折扣：
Furthermore, for customers who have even higher performance requirement than currently supported by a single io2 volume today, we are previewing io2 volumes that run on EBS Block Express, the next generation of our block storage architecture. io2 Block Express volumes can be provisioned to deliver peak IOPS of 256,000. For these volume, any IOPS provisioned over 64,000 IOPS will be charged at a further 30% lower rate than the second tier ($0.032 per provisioned IOP-mo for IOPS over 64,000). This lowers the effective rate to $0.038 per provisioned IOPS on a volume provisioned with 256,000 IOPS.
算是要衝效能的人用的，目前平常應該還是會用 gp2 或是 gp3 的 SSD...
今年的 AWS re:Invent 又開始了，不過因為疫情的關係，這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。
首先是推出了新的 gp3 類型，也是 SSD 類：「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。
每 GB 單位成本比 gp2 低 20%：
Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.
然後直接給你 3000 IOPS 與 125MB/sec，有需要更高的話可以「加購」：
gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.
但照「Amazon EBS volume types」這邊的列表可以看到，要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。
也因為這樣，可以把一些 random access 比較多的 /data 這類的 EBS 換過去，但如果是要大量 sequential access 的也許就不適合了。
IOPS 的部份，1TB 以下的 gp2 換過去應該是沒什麼太大問題，因為在 gp2 的時候是 1GB 給 3IOPS，所以 1TB 以下的 gp2 都低於 3000IOPS。
轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3：
If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.
像是這樣：
但照「Amazon EBS volume types」這邊的列表，gp3 可以是開機硬碟
Update：剛剛發現文件被修正了，看起來不能當開機硬碟...
不知道哪邊搞錯了，過幾天看看吧 XDDD
算是做個記錄...
差不多是 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 一定會變，就比較麻煩了，之後再看看機會...
在 Hacker News Daily 上看到 Apple M1 為什麼這麼快又省電的解釋，可以當作一種看法：
1/ In case you were wondering: Apple's replacement for Intel processors turns out to work really, really well. Some otherwise skeptical techies are calling it "black magic". It runs Intel code extraordinarily well.
— Robᵉʳᵗ Graham?, provocateur (@ErrataRob) November 25, 2020
可以在 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 版本壓在地上磨蹭的結果了...
在 Hacker News 看到 Raspberry Pi 400 的使用心得：「I've now played with a Raspberry Pi 400 for a week and here are my conclusions」，先前在「Raspberry Pi 400」這邊有提到 Raspberry Pi 400，主要就是一台 Raspberry Pi 4 Model B 的主機，但跟鍵盤整合在一起。
在文章裡提到了 Raspberry Pi 4 可以 USB Boot 後帶來的改變 (參考之前寫的「Raspberry Pi 4 可以透過 USB 開機了」這篇)，主要是透過 USB3 外接硬碟可以讓讀寫速度大幅提昇 (尤其是 SSD)，這一直都是 Raspberry Pi 上面用 SD card 的問題，看起來唯一的問題還是 CPU 的速度還是沒有像目前常見的 x86-64 強。
If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.
另外討論裡面也有人希望 Raspberry Pi 考慮引入 eMMC 或是提供 M.2 界面改善讀寫速度，不過我覺得 SD card 的設計算是 Raspberry Pi 當初的方向，本來就有取捨，不太可能什麼都做進去...
回到作者的心得，雖然 USB3 轉 SSD 看起來 i/o 速度快不少，但我好像主要不是遇到 i/o 速度問題，反倒是最近 chromium 的硬體解碼好像有些進度，也許看影片有機會用硬體處理 (至少一部份？)，希望至少可以輕鬆看 1080p60 啊...
Python 3.9.0 出了：「Python 3.9.0 is now available, and you can already test 3.10.0a1!」。
下一個版本是 3.10 而非 Python 4：
OK, boring! Where is Python 4?
Not so fast! The next release after 3.9 will be 3.10. It will be an incremental improvement over 3.9, just as 3.9 was over 3.8, and so on.
在「What’s New In Python 3.9」裡面的「Optimizations」這段有測一些基本操作的效能，可以看到 Python 3.9 其實比 Python 3.8 慢了一些？好像也沒有提到原因就是了...
這幾年 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 的遊戲的情況...
在 Cloudflare 的「Speeding up HTTPS and HTTP/3 negotiation with... DNS」這篇裡面提到了一個新的標準 (目前是 draft)：「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」。
從文件上可以看到這個標準是由 Google 與 Akamai 的人提出來的，想要透過 DNS 的方式告訴瀏覽器這個網站可以直接用 HTTPS 連線 (以及其他資訊)。
這樣有兩個好處，第一個是安全性上的好處，HSTS 只保證了第二次以及之後的連線會強制用 HTTPS，但不能保證第一次連線時是 HTTPS。透過 DNS 查到後可以第一次就用 HTTPS 連線。
第二個是效能上的好處，降低了一個 3xx redirect 的時間，雖然 DNS 多了一些查詢，但 DNS 查詢這邊通常會比 TCP connection 建立連線來說快不少，再加上 HTTP protocol 需要先等瀏覽器端送出 HTTP header 後才有回應，這樣應該是快蠻多的。
文章裡有提到 iOS 14 好像有開始在嘗試，但我好像沒看到其他資料：
We began investigating and found these to be a part of Apple’s iOS14 beta release where they were testing out a new SVCB/HTTPS record type.
先繼續觀望看看標準怎麼發展...
Hacker News 上看到「Lessons Learned from Running Postgres 13: Better Performance, Monitoring & More」這篇文章，其中有提到 PostgreSQL 13 因為 B-Tree 支援 deduplication，所以有機會縮小不少空間。
搜了一下源頭是「Add deduplication to nbtree.」這個 git commit，而 PostgreSQL 官方的說明則是在「63.4.2. Deduplication」這邊可以看到。
另外值得一提的是，這個功能在 CREATE INDEX 這頁可以看到在 PostgreSQL 13 預設會打開使用。
依照說明，看起來本來的機制是當 B-Tree index 內的 key 相同時，像是 key1 = key2 = key3 這樣，他會存 {key1, ptr1}、{key2, ptr2} 與 {key3, ptr3}。
在新的架構下開啟 deduplication 後就會變成類似 {key1, [ptr1, ptr2, ptr3]} 這樣的結構。可以看出來在 key 重複的資料很多的時候，可以省下大量空間 (以術語來說的話，就是 cardinality 偏低的時候)。
這樣看起來可以降低不少壓力...