Tag: go

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 的消息，看起來作者也在裡面一起討論，應該會有一些結果出來...

日本圍棋界使用 AWS 分析棋局的情況

看到「圍棋ＡＩ與ＡＷＳ」這篇譯文，原文是「囲碁AIブームに乗って、若手棋士の間で「AWS」が大流行 その理由とは？」。

沒有太意外是使用 Leela Zero + Lizzle，畢竟這是 open source project，在軟體與資料的取得上相當方便，而且在好的硬體上已經可以超越人類頂尖棋手。

由於在 Lizzle 的介面上可以看到勝率，以及 Leela Zero 考慮的下一手 (通常會有多個選點)，而且當游標移到這些選點上以後，還會有可能的變化圖可以看，所以對於棋手在熟悉操作介面後，可以很快的擺個變化圖，然後讓 Leela Zero 分析後續的發展，而棋手就可以快速判斷出「喔喔原來是這樣啊」。

網路上也有類似的自戰解說，可以看到棋手對 Lizzle 的操作與分析 (大約從 50:50 開始才是 Lizzle 的操作)：

不過話說回來，幹壞事果然是進步最大的原動力... 讓一群對 AWS 沒什麼經驗的圍棋棋手用起 AWS，而且還透過 AMI 與 spot instance 省錢... XD

Cloudflare 自己用 Rust 寫了一套相容 WireGuard 協定的軟體

Cloudflare 發現目前符合他們條件的 WireGuard 軟體效能不夠好，所以就用 Rust 寫了一套出來：「BoringTun, a userspace WireGuard implementation in Rust」，軟體在「BoringTun」這邊可以看到。

Cloudflare 的條件是 userspace 以及多平台，市面上有 wireguard-go 符合這兩個條件，但效能不太好，所以就下去寫了。

GitHub 的頁面上可以看出還在剛開始的階段，很多頁面都還只有個雛型... 等這幾天陸陸續續更新後再回來看好了。

GitHub 上的軟體授權分佈

雖然 GitHub 有提供 license 相關的 API 可以查，但因為準確度不高 (只要稍微改到，GitHub 就無法偵測到正確的 license)，所以有人決定用 machine learning 的方式另外分析：「Detecting licenses in code with Go and ML」。當然這邊是分析公開的部份：

最大包的是 MIT License，次之是 Apache-2.0 (問號那群先不管)，再來是 GPL 家族的各版本。沒有太特別的意外發生...

Google 推出 gVisor 強化 Container 的安全性

Google 發表了 gVisor，針對 Linux 所使用的 container 技術強化安全的部份：「Open-sourcing gVisor, a sandboxed container runtime」。

依照 Google 的說法，一般 container 的架構是這樣：

而具有強隔離性的 VM 技術則是這樣：

在 VM 的 overhead 偏重，但一般的 container 安全性又不夠。而 gVisor 則是這樣：

對於目前最常見的 Docker 系統上，在安裝 gVisor 後只需要指定 --runtime=runsc 就可以使用 (預設是 --runtime=runc)，像是這樣：

$ docker run --runtime=runsc hello-world
$ docker run --runtime=runsc -p 3306:3306 mysql

其中 runsc 的意思是「run Sandboxed Container」。

另外而因為 gVisor 卡在中間，不認識的 syscall 都會被擋下來，所以目前並不是所有的應用程式都可以跑，但開發團隊已經測了不少應用程式可以在上面運作，算是堪用的程度：

gVisor implements a large part of the Linux system API (200 system calls and counting), but not all. Some system calls and arguments are not currently supported, as are some parts of the /proc and /sys filesystems. As a result, not all applications will run inside gVisor, but many will run just fine, including Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB, and many more.

值得一提的是，雖然是處理 syscall，但是是用 Go 開發的，而不是 C 或是 C++，這點頗特殊的...

在 TeX 上輸出圍棋棋譜的套件 psgo_emitter

忘記是在哪邊看到 avysk/psgo_emitter 這個套件，提供 TeX 語法輸出成圍棋棋盤的圖示，不過說明裡說只支援 Windows 平台：

psgo_emitter is a (Windows) console utility to create go diagrams for go life-and-death problems (tsumego).

可以只輸出角部，像是這段語法：

    begin{psgopartialboard}{(1,1)(8,6)}
            stone{black}{b}{3}
            stone{black}{d}{3}
            stone{black}{b}{4}
            stone{white}{d}{5}
            stone{white}{g}{2}
            stone{black}{d}{2}
            stone{white}{b}{5}
            stone{white}{c}{4}
            stone{white}{e}{4}
            stone{white}{e}{3}
            stone{white}{e}{2}
            stone{black}{e}{1}
    end{psgopartialboard}

會輸出這樣的圖：

另外也可以把手順放進去：

    begin{psgopartialboard}{(1,1)(8,6)}
            stone{black}{b}{3}
            stone[marklb{1}]{black}{a}{2}
            stone{black}{d}{3}
            stone{black}{b}{4}
            stone[marklb{8}]{white}{f}{1}
            stone[marklb{6}]{white}{d}{1}
            stone{white}{e}{2}
            stone{white}{g}{2}
            stone{black}{d}{2}
            stone{white}{b}{5}
            stone[marklb{7}]{black}{b}{2}
            stone[marklb{9}]{black}{a}{1}
            stone{white}{c}{4}
            stone[marklb{4}]{white}{c}{2}
            stone{white}{e}{4}
            stone[marklb{5}]{black}{c}{3}
            stone{white}{e}{3}
            stone[marklb{2}]{white}{b}{1}
            stone{white}{d}{5}
            stone[marklb{3}]{black}{a}{4}
            stone{black}{e}{1}
    end{psgopartialboard}

就會輸出：

套件還很新，不知道之後會發展成什麼樣子...

AlphaGo 的電影將會上在 Netflix

Twitter 上看的消息，2018 年上到 Netflix：

沒幾天了，來等吧...