幹壞事是進步最大的原動力
在 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。
真的是沒注意到...
在 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 去換記憶體，算是特化的版本...
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
bfloat16data 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 應該在之後完整公開後會有更多消息出來...
在「Memcached vs Redis - More Different Than You Would Expect」這邊看到對 Memcached 與 Redis 的分析。
這兩套軟體都很常被拿來用作 cache 機制，所以一般來說比較時就是比兩邊都有的東西 (如果你要 pub-sub 之類的東西，在這兩套裡面只有 Redis 有)。
最前面還是先講了對使用者 (開發者) 的差異，很明顯的是 Redis 對各種不同的資聊結構都有支援，這點可以從 Redis 被官方被稱作 Data Structures Server 就可以知道 (在「An introduction to Redis data types and abstractions」這篇可以看到)，而 Memcached 只支援了 key-value 架構。
不過如果是以 cache 來說，的確 key-value 架構就還蠻好用的。
後面就開始比較硬的主題了，提到了 Memcached 與 Redis 內部是怎麼使用記憶體的。
Memcached 的部份先提了 page/slab/chunk 的架構以及產生的效能限制與浪費，接著有提到 2020 年 refactor 的部份 (太久沒有看 Memcached 的消息，去年沒跟到這個部份)，讓多 CPU 的支援度更好。
Redis 則是靠 jemalloc 來處理這個部份，另外加上 background thread 的機制降低 fragment。
然後是比較 cache expiration 的部份，可以看到兩者用的演算法在現實世界中都夠用 (尤其是當作 cache 來用)，這部份跟印象中的架構差不多，應該是沒有太大變化。
最後是比較 cluster 的部份，Memcached 是 share nothing，所以沒什麼好說的，主要是靠 client library 實做 consistent hash 之類的架構打散；而 Redis 的話看起來有實做新的機制出來 (也沒跟到)，之後有機會再看看可以做到什麼程度。
不過好像沒提到 proxy 之類的架構，基本上各大公司都有自己幹：
少了這塊對於 cluster 架構的完整性差蠻多的。
文章最後沒有下定論一定要用哪個比較好，兩者都有強項與弱項，還是得看情況來處理。不過我自己還是很喜歡用 Memcached 就是了...
在「Heatshrink – An ultra-lightweight compression library for embedded systems」這邊看到的演算法 Hearshrink，可以看到主打是在記憶體的用量受限的環境下壓縮。
在 2013 年的資料就有壓縮率的比較了：「heatshrink: An Embedded Data Compression Library」。
像是目前常被拿來使用的 ESP32 就只有 320KB 記憶體，gzip 就明顯太肥大了，HS 在這邊就可以犧牲壓縮率來換效能...
另外找了一下資料，發現有 lowzip 這個東西，走 ZIP 格式，記憶體用量也不高，不過軟體本身還掛 alpha：
Current x64 code footprint (for lowzip.c, excluding the test program) is about 3.2kB and RAM footprint is about 1.1kB.
如果之後打算要透過 LPWAN 之類的網路傳東西的話好像有可能會用到，先寫下來...
Java 17 (JDK 17) 釋出，這是 Oracle 本家新的 LTS 版本，引用的是 jdk-dev 的 mailing list：「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下：「Java 17 / JDK 17: General Availability (java.net)」。
上一個 LTS 版本是 Java 11，所以很自然的也會有從 Java 11 之後的新功能說明：「JEPs in JDK 17 integrated since JDK 11」。
對於只是拿來用，而不是拿來開發的人來說，我的重點都放在 JVM 的 GC 效能以及特性。
從 Java 11 預設的 G1GC 來看，可以看到一些改善，從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能，不過看起來有 -XX:+UseNUMA 這個參數要加。
再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。
接下來是兩個新的 GC (相較於 11 版)，一個是 ZGC，另外一個是 Shenandoah，都沒有取代 G1GC，但兩個都有對應使用的場景。
ZGC 有列兩個 JEP：「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」，目標是讓 GC pause time 盡可能的低，另外在 wiki 上面的說明則是有提到目標在 1ms 以下：
The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.
Sub-millisecond max pause times
Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」，不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細，目標是希望 GC 不影響目前正在執行的程式：
Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.
可以看出來兩個新的 GC 都是希望降低 pause time，對於 latency 敏感的應用應該都可以測試看看，可以預期整體的 throughput 會低一些。
回頭來看 G1GC，有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異：「How much faster is Java 17?」。
可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少，不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC，這邊就不提了，可以自己看...
等各家 build 出來後來測看看 Cassandra 的效能影響如何...
這次 Amazon EC2 的機器又推出一些新規格了：「Amazon EC2 High Memory Instances now available for on-demand usage」。
然後每次推這些機器的時候都會提到 SAP HANA，都沒有其他的例子可以說... 話說業界就只剩下這套系統是完全都沒在考慮分散式架構嗎 XDDD (完全沒用過)
SAP customers continue to leverage AWS as their platform of choice and innovation. Some are in the early stages of their SAP cloud journeys and are focused on executing their migration. Others have hardened their SAP systems on AWS and are innovating around their core business processes with advanced AWS services.
另外他有提到 24TB 的機器，在 Amazon EC2 Instance Types 這邊可以翻到 u-24tb1.metal：
In 2018, we released High Memory Instances in response, which now offer up to 24TB of memory in a single instance.
不過你會發現在 Amazon EC2 On-Demand Pricing 這邊翻不到 24TB 的價錢，先前在「EC2 推出 18TB 與 24TB 的機器...」這邊有過這些機器買三年 RI 才能用，所以這次推出來 12TB 的機器算是隨時租用的機器裡面記憶體最多的了...
u-12tb1.112xlarge 在 us-east-1 的價錢是 USD$109.2/hour，想要玩的人可以測試看看，至少應該玩的動 XD
AWS 推出了 X2gd 機種，用 ARM 的 CPU，然後給更少顆，disk 也更小，但換來的就是價錢更低：「New Amazon EC2 X2gd Instances – Graviton2 Power for Memory-Intensive Workloads」。
把兩個用 ARM 的主機拿出來看看 us-east-1 的價錢，第一個是這次的 x2gd.medium，只有 1 vCPU + 59 GB SSD，但有 16 GB RAM，現在的價錢是 $0.0835/hr。
另外一個 r6g.large 則是 2 vCPU + 16 GB RAM，然後 EBS only，則是 $0.1008/hr。
再來是 Intel 的 x1e.xlarge，這邊是 4 vCPU + 12 GB RAM + 120 GB SSD，單價也差不多，不過記憶體少了點，$0.834/hr。
另外 Intel 也有 r5.large，2 vCPU + 16 GB RAM + EBS only，$0.126/hr。
最後一個是 AMD 的 r5a.large，跟 Intel 的 r5.large 也很像，2 vCPU + 16 GB RAM + EBS only，$0.113/hr。
這次推出的 X2gd 機種提供了只要記憶體的極端選擇，而且依照先前的經驗，Graviton2 真的很快，1 vCPU 未必會不夠用... 至少我 blog 的 PHP 與 MariaDB 都是跑在 t4g 上面，看起來比之前放在 VPS 上快不少 :o
我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2 的 t4g.small 上 (2GB RAM + 20% CPU credit)，跑了一陣子把 CPU usage 拉出來看：
當初估大約要 20% 的 CPU credit，結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB，這個量可以看出來一些沒在用的 process 會被丟到 swap：
total used free shared buff/cache available Mem: 952Mi 380Mi 79Mi 110Mi 492Mi 368Mi Swap: 511Mi 152Mi 359Mi
把條件綜合起來計算，就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。
另外新機種比較不用擔心淘汰速度，就看了一下 Reserved Instances 的價錢，一年 USD$44，三年 USD$84，看起來只要有用兩年就算是 OK，直接買三年解決掉...
在 Hacker News Daily 上看到個有趣的 troubleshooting 過程，AT&T 的線路會造成 random bit flipping 的問題，另外在 Hacker News 上的討論野蠻熱鬧的：「AT&T Fiber in the SF Bay Area is flipping bits (twitter.com/catfish_man)」。
More evidence that my ongoing internet woes are at AT&T’s endhttps://t.co/QurZdHBNz3
— David Smith (@Catfish_Man) December 5, 2020
有人生了一個 script 出來測試，這隻 script 會抓 www.example.com 的 HTTP 與 HTTPS 結果比較，從下面大家的留言回報，可以看出來有 random bit flipping 的問題：「bmastenbrook/example-test.sh」。
然後總算是解決了：
I’m hearing AT&T got their shit together and things are working now. Big thanks to @vikxin and @bmastenbrook for doing the heavy lifting here.
— David Smith (@Catfish_Man) December 8, 2020
可惜看不到 AT&T 的回應，大家只能猜測是 memory 相關的問題，也許壞的部份有多個地方，造成 ECC 機制在某些情況下不夠用...