Tag: go

25Gbps 下 HTTPS 的效率

作者家裡拉了 25Gbps 的 Internet 後 (可以參考先前寫的「25Gbps 的家用 Internet」這篇)，然後發現 Internet 上好像拉不動 25Gbps 的量，所以自己在家裡先測試了現在 HTTPS 的極限速度：「25 Gbit/s HTTP and HTTPS download speeds」。

Client 是 AMD 的 5600X，算是目前最新的世代；Server 則是 Intel 的 9900K，目前最新應該是 12 代；測試用 35GB 的檔案來測，然後使用 TCP BBR (這邊沒有特別講，目前 kernel 內建的還是 v1)。

在單條 HTTP 的情況下 curl + nginx 與 curl + caddy 都可以直接跑滿 (23.4Gbps)，Go 的 net/http 會卡在 20Gbps 左右。

如果是多條 HTTP 的話都可以跑滿 23.4Gbps。

但到了 HTTPS 的情況下最快的是 Go + net/http，可以跑到 12Gbps；curl + nginx 剩下 8Gbps；接下來 curl + caddy 的部份只有 7.5Gbps，而 go + caddy 只有 7.2Gbps。

上到多條 HTTPS 的情況大家都可以跑滿 23.4Gbps，除了 go + caddy 只能跑到 21.6Gbps。

另外作者試著用 kTLS 把 TLS 的工作丟進 kernel，就不需要全部在 nginx 內處理，速度基本上沒有太大變化，主要是降低了 CPU loading：

In terms of download speeds, there is no difference with or without KTLS. But, enabling KTLS noticeably reduces CPU usage, from ≈10% to a steady 2%.

算是一個有趣的發現，如果目前的 HTTPS 想要在 25Gbps 上面單線直接跑滿，還需要再 tune 不少東西...

Libmill：在 C 裡面仿造 Go 的 concurrency 架構

Hacker News 首頁上看到的專案：「Libmill is a library that introduces Go-style concurrency to C.」。

使用上的設計可以看到就是用 Golang 裡面的設計，另外在網頁下方也有提到「libdill: Structured Concurrency for C」，就不是用 Golang 的設計，但是有同樣的功能性...

兩者都是 MIT/X11 license，大多數的專案用起來應該沒什麼問題，底層應該都是用 select() 或是 poll() 來實做就是了？

MariaDB Corporation Ab 透過 SPAC 上市

MariaDB Corporation Ab 透過 SPAC 上市：「MariaDB Corporation Ab to Become a Publicly Traded Company via Combination with Angel Pond Holdings Corporation」。

Upon closing of the transaction, the combined company will be named MariaDB plc and led by MariaDB’s CEO Michael Howard.

Hacker News 上有一些對 MariaDB 的討論可以看一下 (是對軟體討論，不是對公司討論)：「MariaDB to go public at $672M valuation (mariadb.com)」。

大多數用 MariaDB 的人其實都只是在用 MySQL 的功能，不常用到 MariaDB 的特殊功能，像是 Aria (MyISAM 的 crash-safe 版本) 還是沒有 transaction，而 InnoDB 的效能其實相當好，就找不太到理由去用 Aria...

另外從 Google Trends 的 volume 也可以看出來趨勢是往下降而非向上爬升，這時候趕快脫手 (而且還是透過 SPAC) 看起來是最好的時機？

Windows 上現成的 KataGo + Lizzie 安裝程式

本來花了一些功夫整理了一下 KataGo + Lizzie 純 CPU 版本在 Windows 上的安裝方式 (在「KataGo/Windows」這邊)，後來找了一下發現早就有人做的更簡單了：「BadukMegapack」。

底層的部份除了可以選擇裝 KataGo 外，也可以選擇目前已經停止維護的 Leela Zero，或是 SAI、AQ 與 Ray。

而界面的部份除了可以用 Lizzie 外 (而且還是改過的加強版 XD)，還可以選其他的界面... 除此之外還連 JVM (Java 8) 都一起拉進來幫你裝。

看起來算是包的好好的... 看起來最困難的應該是弄一張高階顯卡了？

KataGo 的分散式訓練計畫啟動了

KataGo 應該是目前 open source 領域裡面數一數二強的圍棋引擎，在去年就一直在開發可以讓大家參與的分散式訓練計畫，最近釋出了 v1.8.0 版，算是公開啟動了：「KataGo Distributed Training」，作者在「KataGo distributed training is open!」這邊也有大概寫一下。

基本上照著官方網站上面的說明做就可以了，可以下載 precompiled binary 或是自己編，自己編的時候注意不能直接拿 master branch 裡面編 (client hash 會不對)，我自己目前是用 v1.8.0 這個版本編出來跑。

在 Reddit 上面的「KataGo's new run is open for public contributions!」也可以看到說明的圖片 (要注意圖上的 X 軸不是線性)，算是接著本來的 g170 訓練下去，另外也標示了 ELFv2 與 Leela Zero 大致上的強度：

目前看起來陸陸續續有人開始參與了...

另外在 CGOS 上面也可以看到 kata1 開頭的 bot 在跑，而且看起來會一直把新的 training 成果更新上去跑。

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式，結合了 Golang 的執行效率與 JavaScript 的操作語法，讓使用者可以很簡單的進行壓力測試，在 Hacker News 上也有蠻正向的反應：「K6: Like unit testing, for performance (github.com/loadimpact)」，我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊，看起來「Load Impact」是公司名稱，「LoadImpact」則是產品名稱，然後現在要改名變成「k6」與「k6 Cloud」：

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念，如同字面上的意義，VU 是虛擬的使用者，就技術上來說，每個 VU 都是在獨立的 JavaScript runtime 裡跑：

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了，所以就不需要一堆 callback & promise 架構，用起來就爽很多：

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼，看起來 JavaScript runtime 這部份是用 Golang 寫的 goja。

文件裡面給了不少範例，像是在「Running k6」這邊有直接給出怎麼壓測，10 個 VU 跑 30 秒：

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面，「samples」這個目錄下有不少範例，可以直接先看過一次從裡面學到不少功能，之後再回去翻一次 manual，應該就會更熟悉...

隨便測了一下還蠻容易上手的，加上有 apt repository 可以直接納入系統管理，看起來應該會放著跑，之後找機會用看看，也許打 API 之類的...

KataGo 最近的進展

KataGo 是目前 open source 裡最強的計算引擎了，不過先前的缺點就是得透過 OpenCL 或是 CUDA 才能跑，所以基本上得有張夠力的顯示卡才行。

如果要想要在 CPU 上跑 (不透過硬體顯示卡)，一種方式是透過 OpenCL 的方式模擬，在 Linux 下可以透過 pocl 達成，效能就普普通通，但算是會動的東西，不過 Windows 下好像不太好弄... 這也是先前蠻多人還是繼續使用 Leela Zero 的原因。

最近 KataGo 在 1.5 版實做了純 CPU 版本的程式碼，是透過 Eigen 這套 library 達成的，不過大家測過以後發現慢到爆炸 XDDD

因為作者沒有提供 CPU 版本的 binary，我自己在 Linux 下抓程式碼 compile 後測試發現只會用一個 CPU (沒有 multi threading)，對比於在 1080Ti 上跑 OpenCL 版本大約 150 visits/sec (40b)，但 CPU 版本是 0.0x visits/sec 啊 XDDD

作者自己在 GitHub 上討論時也有提到這個版本只有確認正確性，完全沒有考慮效能...

不過就有其他人跳出來改善了，在「Optimization of Eigen backend #288」這邊可以看到 kaorahi 拋出了不少修改，可以看到從一開始的 eigen_naive_loop (對比 1.5 版有 13x 的成長) 一路到 borrow_tensorflow (1400x) 的版本，使得在 CPU 上面跑 15b 也有 10 visits/sec 了：

"borrow_tensorflow" version: x1400 speed up from 1.5.0 (70% of libtensorflow backend). Now 15b net is usable for me. I get 19 visits/s in benchmark and 10 visits/s in GUI with 15b net.

這樣看起來已經快了不少，這樣子 Leela Zero 應該會逐漸淡出了，CPU-only 算是最後一塊 Leela Zero 還可以爭的地盤...

在 EC2 上面跑 Lizzie + KataGo

我用 Packer 包了一個將 Lizzie (界面) + KataGo (引擎) 打包成 Amazon EC2 AMI 的設定：「packer-katago」。

這個組合應該是目前圍棋棋手最常拿來分析棋譜的工具，與之前常用的 Lizzie + Leela Zero 的差異在於 KataGo 可以分析勝率與目數，而 Leela Zero 則只能分析勝率。(參考之前寫的「用更少訓練時間的 KataGo」這篇)

早期的 KataGo 強度還沒有很強，一般還是會與 Leela Zero 交叉換著分析，但最近幾個版本的強度比之前好很多，目前看起來已經超過 Leela Zero 了 (可以參考 CGOS Whole Period Ratings for 19x19 Board 這邊列出來的排名)，另外就 YouTube 上看起來，蠻多棋手應該都是改用 KataGo 了...

不過不管是 Leela Zero 還是 KataGo 都需要夠強的 GPU 運算，之前就算用 GTX 1080 Ti 也還是覺得不夠快，就丟到 AWS 上面用看看，順便練一下手，熟悉 Packer 怎麼用。

我是設計成用 IceWM + VNC，連進去後左下的選單裡面就會有 Lizzie 可以選：

第一次跑起來會比較久，我在 p3.2xlarge 的機器上大約要等個三四分鐘，然後就會出現數字了：

看了一下運算的速度還不錯，用 spot instance 開的話，成本上應該還可以接受 (剛剛的 p3.2xlarge 是 USD$0.918/hr)。

JavaScript 的壓縮器 esbuild

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 並且平行化運算達到的：

  • It's written in Go, a language that compiles to native code
  • Parsing, printing, and source map generation are all fully parallelized
  • Everything is done in very few passes without expensive data transformations
  • Code is written with speed in mind, and tries to avoid unnecessary allocations

不過作者有提到這個專案畢竟比較新，還沒有被時間磨練過，可能會有些 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 踩一踩修一修...

用更少訓練時間的 KataGo

最近開始在不同的地方會看到 KataGo 這個名字 (Twitter 與 YouTube 上都有看到)，翻了一下資料發現是在訓練成本上有重大突破，依照論文的宣稱快了五十倍...

在第一次跑的時候，只用了 35 張 V100 跑七天就有 Leela Zero 第 130 代的強度：

The first serious run of KataGo ran for 7 days in Februrary 2019 on up to 35xV100 GPUs. This is the run featured in the paper. It achieved close to LZ130 strength before it was halted, or up to just barely superhuman.

而第二次跑的時候用了 28 張 V100 跑 20 blocks 的訓練，跑了 19 天就已經超越 Facebook 當初提供的 ELFv2 版本，而對應到 Leela Zero 大約是第 200 代左右的強度 (要注意的是在 Leela Zero 這邊已經是用 40 blocks 的結構訓練了一陣子了)：

Following some further improvements and much-improved hyperparameters, KataGo performed a second serious run in May-June a max of 28xV100 GPUs, surpassing the February run after just three and a half days. The run was halted after 19 days, with the final 20-block networks reaching a final strength slightly stronger than LZ-ELFv2! (This is Facebook's very strong 20-block ELF network, running on Leela Zero's search architecture). Comparing to the yet larger Leela Zero 40-block networks, KataGo's network falls somewhere around LZ200 at visit parity, despite only itself being 20 blocks.

從論文裡面可以看到，跟 Leela Zero 一樣是逐步提昇 (應該也是用 Net2Net)，而不是一開始就拉到 20x256：

In KataGo’s main 19-day run, (b, c) began at (6, 96) and switched to (10, 128), (15, 192), and (20, 256), at roughly 0.75 days, 1.75 days, and 7.5 days, respectively. The final size approximately matches that of AlphaZero and ELF.

訓練速度上會有這麼大的改善，分成兩個類型，一種是一般性的 (在「Major General Improvements」這章)，另外一類是特定於圍棋領域的改進 (在「Major Domain-Specific Improvements」這章)。

在 Leela Zero 的 issue tracking 裡面也可以看到很多關於 KataGo 的消息，看起來作者也在裡面一起討論，應該會有一些結果出來...