幹壞事是進步最大的原動力
Cloudflare 推出了自己的 Speed Test 服務：「Test your home network performance」。
這個服務跟 Netflix 推出的 fast.com 類似，測試的是使用者端到 Netflix (或是 Cloudflare) 中間的速度，主要的目的還是公關 (PR)，所以看看就好，實際上用 Speedtest 測出來會比較有參考價值，而且可以選擇不同的點測試...
不過這讓我想到之前有人測出來遠傳會對偵測使用者要使用 Speedtest 測試時開放速限的情況 (像是「遠傳吃到飽只有 Speedtest 沒限速」這篇)，然後就有各種定時去打 Speedtest 觸發開放速限的方法...
目前好像只剩下這篇活著，內文提到的是 Android 上的方法，另外推文有人提到 iOS 下的方法：「[心得] 在Android破解遠X限速」，如果有遇到的可以用看看...
esbuild 是個 JavaScript bundler & minifier，在 GitHub 上的副標提到了重點在於速度：
An extremely fast JavaScript bundler and minifier
從壓縮時間可以看出來優勢：
另外從最終的檔案大小也可以看出來，與最小的 rollup + terser 組合沒有差太多：
實際拿個 jQuery 跑看看，可以看出來壓縮的效果還行：
-rw-r--r-- 1 gslin staff 89228 Feb 19 06:03 jquery-3.4.1-esbuild.min.js -rw-r--r-- 1 gslin staff 280364 May 2 2019 jquery-3.4.1.js -rw-r--r-- 1 gslin staff 88145 May 2 2019 jquery-3.4.1.min.js
速度主要是透過 Golang 並且平行化運算達到的：
不過作者有提到這個專案畢竟比較新，還沒有被時間磨練過，可能會有些 bug：
This is a hobby project that I wrote over the 2019-2020 winter break. I believe that it's relatively complete and functional. However, it's brand new code and probably has a lot of bugs. It also hasn't yet been used in production by anyone. Use at your own risk.
可以先放一陣子看看，讓一些先賢先烈把比較大的 bug 踩一踩修一修...
Amazon Aurora 宣佈支援快速複製：「Amazon Aurora Fast Database Cloning」。
對於 2TB 的資料大約五分鐘就完成了：
This means my 2TB snapshot restore job that used to take an hour is now ready in about 5 minutes – and most of that time is spent provisioning a new RDS instance.
主要是得力於後端 storage 的部份可以實做 copy-on-write 架構：
By taking advantage of Aurora’s underlying distributed storage engine you’re able to quickly and cheaply create a copy-on-write clone of your database.
可以快速複製就可以很快的驗證一些事情，像是可以直接測試 ALTER TABLE 需要的時間，或是事前演練...
Dgraph 在推銷自家發展出來的 Badger：「Introducing Badger: A fast key-value store written natively in Go」。
標靶是 RocksDB，號稱比 RocksDB 快好幾倍：
Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.
不過我覺得有些重要的功能在 Badger 不提供，這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction，而 Badger 則是直接講明他們不打算支援 Transaction：
Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.
在「Glob Matching Can Be Simple And Fast Too」這邊看到在分析 (a.*)nb 這樣的 pattern 的效能 (像是 a.*a.*a.*b 這樣的東西)，第一波先測 shell，結果發現有趣的現象：
那個 csh 是怎麼了 XDDD
Looking at the source code, it doesn’t attempt to perform glob expansion itself. Instead it calls the C library implementation glob(3), which runs in linear time, at least on this Linux system. So maybe we should look at programming language implementations too.
再來是看各程式語言：
各家實做方式不一樣 XD
然後文章裡有提到這個方式是之前蠻常見的 DoS 技巧，用很少的資源就可以吃光你的 CPU resource... 另外也提到了可能的解法，就是限制星號的數量：
At the very least, most FTP servers should probably reject glob patterns with more than, say, 3 stars.
後面演算法的部份也是很有趣的主題...
看到「Announcing Alacritty, a GPU-accelerated terminal emulator」這個用 GPU 加速 rendering 的 terminal emulator：「Alacritty」。
Alacritty is a blazing fast, GPU accelerated terminal emulator. It’s written in Rust and uses OpenGL for rendering to be the fastest terminal emulator available.
全螢幕全文字的情況下可以到 500 fps：
Alacritty’s renderer is capable of doing ~500 FPS with a large screen full of text. This is made possible by efficient OpenGL usage.
現在支援 Linux 與 macOS，不過要自己編，會比較麻煩一點：
Alacritty currently supports macOS and Linux, and Windows support is planned before the 1.0 release.
在「Enabling TCP Fast Open for NGINX on CentOS 7」這邊看到 nginx 對 TCP Fast Open (TFO，RFC 7413) 的支援早在 1.5.8 就有了，而 Linux Kernel 也是 3.7 之後就全面支援了。
TCP Fast Open 利用第一次連線後產生的 TCP cookie，在第二次連線時可以在 3-way handshake 的過程就開始傳輸，藉此大幅降低 latency。
設定方法不難，先在 kernel 設定 net.ipv4.tcp_fastopen=3，再加上 fastopen=number 就可以了，像是這樣：
listen 80 fastopen=256
不過目前 NGINX Mainline 上的版本好像沒有編進去，暫時沒辦法測...
跑 openssl speed ecdh 的時候發現很特別的現象：
Doing 160 bit ecdh's for 10s: 40865 160-bit ECDH ops in 9.99s Doing 192 bit ecdh's for 10s: 34169 192-bit ECDH ops in 9.99s Doing 224 bit ecdh's for 10s: 60980 224-bit ECDH ops in 9.99s Doing 256 bit ecdh's for 10s: 34298 256-bit ECDH ops in 10.00s Doing 384 bit ecdh's for 10s: 9602 384-bit ECDH ops in 10.00s Doing 521 bit ecdh's for 10s: 9127 521-bit ECDH ops in 9.99s
原因是 Google 這篇論文的貢獻：「Fast Elliptic Curve Cryptography in OpenSSL」，開頭就提到：
We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224.
而實際成果：
full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster.
在 OpenSSL 的 CHANGES 也可以看到對應的修改，不只是 NIST-P224 有被改善，其他的 NIST-P256 與 NIST-P521 也都有被改善：
Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs.
頗特別的...
中文稱為「平方根倒數速演算法」，英文則是「Fast Inverse Square Root」。
好像是在 Twitter 還是 Facebook 上看到的 (還是是在其他管道？)，仔細看中文版維基百科條目，發現中文版的資料相當完整了 (看了一下歷史記錄，是去年 2012 年 6 月的時候從英文版翻出來的)。
當時很有名的 magic hack，比查表法快：
在1990年代初（也即該演算法發明的大概時間），軟體開發時通用的平方根計算方法多是從尋找表中取得近似值，而這段代碼取近似值耗時比之更短，達到精確度要求的速度也比通常使用的浮點除法計演算法快四倍，
然後還比 CPU 指令集快 XD
由於演算法所生成的用於輸入牛頓法的首次近似值已經相當精確，此演算法所得近似值的精度已可接受，而若使用與《雷神之鎚III競技場》同為1999年發行的Pentium III中的SSE指令rsqrtss計算，則計算平方根倒數的收斂速度更慢，精度也更低。
Update：請參考 comment，看起來中文版有誤譯...
我本來以為我之前寫過，找了找沒翻到... 補記錄下來 :p