Category: Library

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 還可以爭的地盤...

GPU.js

前幾天在 Hacker News Daily 上看到的專案：「GPU.js - GPU accelerated JavaScript」，對應的 GitHub 頁面在 gpujs/gpu.js 這邊。

看起來是用 WebGL 接進去的，不過他用來 benchmark 的硬體頗暴力啊：

Hardware: Xeon Gold 5217 + 8 x RTX 2080ti

這邊用了八張 2080Ti，如果一張就大約是 1/8 效能的話，看起來好像還好... 一張 2080Ti 跟 Xeon Gold 5217 跑出來差不多？價錢也在同一個範圍區間...

暫時不知道用途...

莎士比亞風格的 UUID

UUID 是個長 128 bits 的數字，轉成 16 進位也有 32 個字要記，對於人類記憶來說不太友善。

前幾天在 Hacker News 上看到的東西，把這 128 bits 的資訊轉成類莎士比亞的句子，相比前面 32 個 16 進位的數字來說好記不少：「uuid-readable」。

Generate Easy to Remember, Readable UUIDs, that are Shakespearean and Grammatically Correct Sentences

給的輸出範例包括了：

Loren Chariot Addy the Titbit of Cholame questioned Cele Garth Alda and 16 windy frogs

Drucill Hubert Lewse the Comer of Avera rejoices Fiann Craggy Florie and 5 hard trouts

Jacquette Brandt John the Pectus of Barnsdall doubted Glenn Gay Gregg and 12 noisy stoats

我不覺得有變簡單啊 XDDD 也許對於英文母語的人來說會簡單一些... 吧？

Mass Effect 的 3D 場景黑塊問題一路追到 Intel/AMD 的 SSE2 指令集...

Mass Effect 是個 2007 在 Xbox 上推出的遊戲，並且在 2008 推出 Windows 版，這個遊戲在 2011 年 AMD 推出的 CPU 上 (Bulldozer)，某些場景會產生人物黑塊的 bug，社群有些猜測但一直都沒被證實，作者一路追出不少問題，並且給了一個還算乾淨的 workaround：「Fixing Mass Effect black blobs on modern AMD CPUs」，另外在 Hacker News 上有很精彩的討論：「Fixing Mass Effect black blobs on modern AMD CPUs (cookieplmonster.github.io)」。

這篇主要是看趣味的，裡面的狀況有點複雜。

社群有一些 workaround 可以避開這個問題，作者後來是從關閉 PSGP (Processor Specific Graphics Pipeline) 的方法找問題，然後發現在計算時會產生出 NaN 的問題，所以導致貼出來的圖就變成黑塊了...

一路追下去，發現遊戲本身好像沒什麼大問題，但跟 Direct3D 裡面的 D3DXMatrixInverse 有關，會依照 CPU 的支援度決定怎麼跑：

  • Disabling PSGP makes both Intel and AMD take a regular x86 code path.
  • Intel CPUs always take an intelsse2 code path.
  • AMD CPUs supporting 3DNow! take a amd_mmx_3dnow or amd3dnow_amdmmx code path, while CPUs without 3DNow take an intelsse2 code path.

會有這些邏輯是因為 AMD 在 2010 後決定放生 3DNow!，所以會需要這樣判斷。

接著寫了一隻小程式測試，用 memcmp() 判斷是不是一樣，結果發現 AMD 的 SSE2 跑出來的程式不被遊戲接受：(不一樣是正常的，因為這些指令本來就沒有要求完全正確，是可以接受誤差的)

接著就是翻資料，可以知道 XMMatrixInverse 算是接班人：

I figured that since we were to replace that matrix function anyway, I could try replacing it with XMMatrixInverse being a “modern” replacement for D3DXMatrixInverse. XMMatrixInverse also uses SSE2 instructions so it should be equally optimal to the D3DX function, but I was nearly sure it would break the same way.

所以就弄個一個 DLL，把本來呼叫 D3DXMatrixInverse 的部份用 XMMatrixInverse 改寫換掉：「SilentPatchME/source/D3DXMatrix.cpp」，這個方式算是乾淨的 workaround 掉，保持 API 相容性，以及該有的加速能力 (由 XMMatrixInverse 提供)。

Hacker News 上有討論到 Intel 與 AMD 這些指令在 SSE2 上的誤差值，都是在規格要求的範圍內：

Const-me 14 hours ago [–]

Here’s Intel versus AMD relative error of RCPPS instruction: http://const.me/tmp/vrcpps-errors-chart.png AMD is Ryzen 5 3600, Intel is Core i3 6157U.
Over the complete range of floats, AMD is more precise on average, 0.000078 versus 0.000095 relative error. However, Intel has 0.000300 maximum relative error, AMD 0.000315.

Both are well within the spec. The documentation says “maximum relative error for this approximation is less than 1.5*2^-12”, in human language that would be 3.6621E-4.

Source code that compares them by creating 16GB binary files with the complete range of floats: https://gist.github.com/Const-me/a6d36f70a3a77de00c61cf4f6c17c7ac

至於為什麼會生出 NaN 的原因，沒找出來還是有點可惜，不過這個解法還行，就是「新版的 library 既然沒問題，就大家也不要太計較舊版的問題」的概念...

libtorrent 要支援 WebTorrent 協定了

一開始是看到「Libtorrent Adds WebTorrent Support, Expanding the Reach of Browser Torrenting」這篇，但看的時候發現裡面把 libtorrent 與 libTorrent 搞混 (這兩套不一樣，libTorrent 是 rTorrent 作者開發的)，就暫時沒管這篇文章了...

剛剛看到「libtorrent adds support for the WebTorrent protocol」這篇，然後回頭去看本來 TorrentFreak 上的文章，發現已經拿掉本來提到的 rTorrent 了。(可以參考 Internet Archive 上的存檔資料 20200709223911)

WebTorrent 的支援對於 BitTorrent 社群算是很大的進展，主要是因為瀏覽器內就算用上 WebRTC 也沒有辦法模擬出 BitTorrent 的協定，所以只能調整協定，也就是這邊提到的 WebTorrent。

但訂了新的協定，最大的問題還是現有的 BitTorrent 程式都不支援 WebTorrent，所以沒辦法享用現有的 ecosystem，變成獨立的系統，對於推廣上面很不利...

而 libtorrent 算是第一個夠大的 library (對應到 client 的數量) 宣佈支援 WebTorrent，這樣用瀏覽器的人就會有更多機會透過 WebTorrent 協定對通了，接下來等更加發佈新版後應該就可以在 WebTorrent 上看到更多節點了...

Python 上的 OCR

這個 OCR 專案是在 Python 包好，讓你很快就可以上手用：「Easy OCR」。

從結果的 screenshot 可以看到輸出的內容很簡單，就是座標與 OCR 出來的內容：

然後支援的語言很多：

We are currently supporting following 42 languages.

Afrikaans (af), Azerbaijani (az), Bosnian (bs), Simplified Chinese (ch_sim), Traditional Chinese (ch_tra), Czech (cs), Welsh (cy), Danish (da), German (de), English (en), Spanish (es), Estonian (et), French (fr), Irish (ga), Croatian (hr), Hungarian (hu), Indonesian (id), Icelandic (is), Italian (it), Japanese (ja), Korean (ko), Kurdish (ku), Latin (la), Lithuanian (lt), Latvian (lv), Maori (mi), Malay (ms), Maltese (mt), Dutch (nl), Norwegian (no), Polish (pl), Portuguese (pt),Romanian (ro), Slovak (sk) (need revisit), Slovenian (sl), Albanian (sq), Swedish (sv),Swahili (sw), Thai (th), Tagalog (tl), Turkish (tr), Uzbek (uz), Vietnamese (vi)

有些參數可以調整，但預設值似乎就跑得不錯了...

讓 Python 輸出變豐富的 Rich

Hacker News 上看到的 Python 專案，讓 terminal 輸出變得更好看：「Rich is a Python library for rich text and beautiful formatting in the terminal.」。

看到當下吸引我的地方在於表格：

from rich.console import Console
from rich.table import Column, Table

console = Console()

table = Table(show_header=True, header_style="bold magenta")
table.add_column("Date", style="dim", width=12)
table.add_column("Title")
table.add_column("Production Budget", justify="right")
table.add_column("Box Office", justify="right")
table.add_row(
    "Dev 20, 2019", "Star Wars: The Rise of Skywalker", "$275,000,000", "$375,126,118"
)
table.add_row(
    "May 25, 2018",
    "[red]Solo[/red]: A Star Wars Story",
    "$275,000,000",
    "$393,151,347",
)
table.add_row(
    "Dec 15, 2017",
    "Star Wars Ep. VIII: The Last Jedi",
    "$262,000,000",
    "[bold]$1,332,539,889[/bold]",
)

console.print(table)

輸出長這樣：

另外還有不少功能也不錯，會讓畫面豐富不少。

繁簡轉換的 OpenCC 專案

在 Twitter 看到這個東西：

翻了一下這邊講的 OpenCC 專案，以目前有提供的 json 檔來看，分的算蠻細的，看起來有對不少種類的漢文 (包括日文使用到的漢字) 都有支援。

這個看起來很適合用在搜尋引擎上... 翻了一下 Elasticsearch 上的情況，看起來目前沒有人有支援，可能要寫個 plugin 之類的掛進去，或是在 index 前先自己處理過再丟進 Elasticsearch 內。

用 Python 刻 GUI 的 guietta

翻 Hacker News Daily 翻到的奇怪工具 guietta，可以在 Python 下用奇怪的方法刻 GUI，範例就很好解釋了調性：

from guietta import _, Gui, Quit

gui = Gui(
    
  [  'Enter numbers:', '__a__'  , '+' , '__b__',  ['Calculate'] ],
  [  'Result:  -->'  , 'result' ,  _  ,    _   ,       _        ],
  [  _               ,    _     ,  _  ,    _   ,      Quit      ]
)

with gui.Calculate:
    gui.result = float(gui.a) + float(gui.b)
    
gui.run()

然後 Ubuntu 下的輸出會是：

在 Hacker News 的討論串「Guietta – Python module to create simple GUIs (github.com)」這邊有人也介紹了其他 Python 下刻 GUI 的方式，翻了一下也還不少有趣的東西。

guietta 看起來拿來刻一些簡單的東西應該還算堪用，尤其是討論裡面有提到在教學授課時可以簡化不少 interface 的問題。

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下，WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論：提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好)，然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候，宣稱失真壓縮的部份可以比 JPEG 小 25%～34%：(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%～34% 這個數字，是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg，而如果拿 MozJPEG 相比的話應該得不到這個結果，另外也把 AV1 的 AVIF 拉進來一起測試了：

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite，測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些，但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善)，而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了：

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好，不過要注意演算法會把非重點部位的細節吃掉：

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說，WebP 另外一個痛點是在 Safari 上的支援度，在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了，就剩下 Safari 還不支援，所以目前在 iOS 上得降回 JPEG：

不過這點之後也改變了，在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了：「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...