Tag: go

Russ Cox 從 Go 的 tech lead 身分交棒出來

在「Russ Cox is stepping down as the Go tech lead (groups.google.com)」看到的，Russ Cox 要將 tech lead 身分交棒出來，原討論串在 Google Groups 上面：「passing torches to Austin and Cherry」。

交棒本身算是階段性任務，倒是沒什麼特別的，讓人討論起來的是這段，批評 BDFL 模式並且直接點名 Python 的情況：

In particular, I don’t believe that the “BDFL” (benevolent dictator for life) model is healthy for a person or a project. It doesn’t create space for new leaders. It’s a single point of failure. It doesn’t give the project room to grow. I think Python benefited greatly from Guido stepping down in 2018 and letting other people lead, and I’ve had in the back of my mind for many years that we should have a Go leadership change eventually.

Go 從一開始就是很純正的由商業公司開發出來的程式語言，所以本來就不會有 BDFL 的角色，這樣的批評其實蠻有趣的...

KataGo 推出了人類棋譜訓練出來的 model

KataGo v1.15.0 的「New Human-like Play and Analysis」推出了用人類棋譜訓練出來的 model：

This release adds a new human supervised learning ("Human SL") model trained on a large number of human games to predict human moves across players of different ranks and time periods! Not much experimentation with it has been done yet and there is probably low-hanging fruit on ways to use and visualize it, open for interested devs and enthusiasts to try.

lightvector 列出的一些 screenshot 看起來像是試著去猜測人類的棋力可能會選擇的點，列出了同樣的棋局在 20 級、1 段與 9 段會考慮的點的差異，算是一種幫助人類理解的方式？

Raspberry Pi Ltd 上市

Raspberry Pi Ltd 在 LSE 上市了，代碼 RPI：「Raspberry Pi IPO」。

LSE 上的資料在「RASPBERRY PI HOLDINGS PLC」這邊，但這網頁開的速度... 有點... 感人？

上市後公司的走向通常都會有不少變化，接著看看 Raspberry Pi 6 的計畫吧？雖然 N100 的實用度會更好...

Go 的 net/http 在 1.22 的 routing 新功能

Go 的 net/http 在 1.22 引入了更方便的 pattern matching：「Routing Enhancements for Go 1.22」。

用官方的範例，現在可以處理路徑裡的參數了：

http.Handle("GET /posts/{id}", handlePost2)

後續可以透過 PathValue() 取出來：

idString := req.PathValue("id")

而優先順序則是依照吻合度定義：

The precedence rule is simple: the most specific pattern wins. This rule matches our intuition that posts/latests should be preferred to posts/{id}, and /users/{u}/posts/latest should be preferred to /users/{u}/posts/{id}. It also makes sense for methods. For example, GET /posts/{id} takes precedence over /posts/{id} because the first only matches GET and HEAD requests, while the second matches requests with any method.

但是當有重疊卻無法判斷相對吻合度的 rule 被加進去時，會直接 panic()：

What if two patterns overlap but neither is more specific? For example, /posts/{id} and /{resource}/latest both match /posts/latest. There is no obvious answer to which takes precedence, so we consider these patterns to conflict with each other. Registering both of them (in either order!) will panic.

這的確是種方法啦... 而且留有之後處理的空間，真的有好的方法就可以把 panic() 的邏輯改成新的共識。

KataGo 1.12.0 與 UEC 杯用的 model：b18c384nbt-uec.bin.gz

剛剛看到 KataGo 出了 1.12.0，同時也放出了在 2022 年十一月 UEC 比賽時用的 model：「New Neural Net Architecture!」。

1.12.0 比較特別的新的類神經網路架構：

This version of KataGo adds support for a new and improved neural net architecture!

這個新的架構以及其他的改善讓訓練的速度改善：

The new neural nets use a new nested residual bottleneck structure, along with other major improvements in training. They train faster than KataGo's old nets and learn more effectively.

另外一個是他把 UEC 比賽時用的 model 放出來了，很特別的是採用 b18c384，而 KataGo Distributed Training 這邊目前主要是 b40c256 與 b60c320，看起來是為了比賽而一次性訓練出來的。

依照他的說法這個 b18c384 版本跟目前訓練網站上的 b60c320 有差不多強度，但計算速度會比 b60c320 快不少，甚至在一些機器上會跟 b40c256 差不多快：

Attached to this release is a one-off net b18c384nbt-uec.bin.gz that was trained for a tournament in 2022, which should be of similar strength to the 60-block nets on http://katagotraining.org/, but on many machines will run much faster, on some machines between 40-block and 60-block speed, but on some machines even as fast as or faster than 40-block.

另外一個大改變是他把訓練工具從 TensowFlow 跳槽到 PyTorch：

The training code has been all rewritten to use pytorch instead of tensorflow.

在 release note 裡沒有提到原因，但這個頗讓人好奇的...

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) 都一起拉進來幫你裝。

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