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

不停機把 server 搬到兩百米外的機房

Hacker News Daily 上看到的有趣故事,作者在 Reddit 上描述怎麼不停機把實體的伺服器搬到兩百米外的機房,中間還經過了停車場:「[Rant... sorta] Physically moved a server today...」,另外作者的 FAQ 在「[FAQ][Rant... sorta] Physically moved a server today...」這邊可以看到。

我會把這個當故事看一看就好,裡面還是有一些細節沒有被敘述 (像是網路不斷線的部份),感覺不太對,但就一個故事來看是蠻有趣的 XD

搬運的過程中間包括了使用 UPS 與多顆 switch 對接,另外中間經過一個停車場,算是很有趣的方式?

用純 HTML + CSS 做出來的踩地雷...

一樣還是 Hacker News Daily 上看到的東西,不過這個東西主要就是趣味性為主而已。這次看到的是純 HTML + CSS 做出來的踩地雷 (Minesweeper),沒有 JavaScript 在內:「css-sweeper from PropJockey」。

自從 HTML + CSS3 證明是 Turing-complete 後,再加上 CSS 本身又一直加各種互動性質的操作,出現這些東西好像不太意外就是了 XDDD

依照他的說明,這邊用到的 CSS 技巧主要是 Space Toggle 這個技巧 (也就是 --toggler 這個),但試著找了對應的文獻說明居然沒翻到,有人可以給個 hint 嗎...

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 既然沒問題,就大家也不要太計較舊版的問題」的概念...

安排路線的服務 Trail Router

Hacker News Daily 上看到的有趣服務,給起點與終點,以及想要有的長度,可以幫你拉一條差不多長度的路徑出來,可以提供給慢跑或是騎腳踏車的人規劃路線:「Trail Router」。

然後發現原來公司對面有 YouBike 站點... XD

這個服務的作者有在 Hacker News 上接受大家的詢問,可以到 Hacker News 上討論的頁面看一下作者的回應:「Show HN: Trail Router – generate running routes that prefer greenery and nature (trailrouter.com)」。

另外值得一提的是,這個服務用了 Mapbox 的圖資 (跟 OpenStreetMap 有關),看起來台北地區的呈現已經遠超過以前「堪用」的程度了,以後如果有需要用到的話可以考慮看看,就不一定要綁在 Google Maps 上了...

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.

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

tw.bbs.* 的轉信

看到 gugod 最近在玩 Usenet:「玩 Usenet Newsgroup」,把 tw.bbs.talk 的 innbbsd 設定給設起來,結果發現 subject 的部份 innbbsd 有把 UTF-8 轉成 BIG5 (記得是因為標題用 MIME-B 很普及,所以很早就支援了),但內文就沒有轉碼了,也許得 patch innbbsd 讓他過 iconv 轉碼?

spam 的部份如同 gugod 提到的也少很多了,看起來是個老人聊天的好地方...

另外在 debug 過程中因為直接讀 header & body,看到了 Cancel-Lock 這個 header,查了一下發現是個 2018 年通過的新標準 (RFC 8315):「Cancel-Locks in Netnews Articles」,不過從維基百科的說明,看起來沒有什麼人支援:

Cancel-lock is much simpler, but neither commonly accepted, nor implemented in popular news servers and newsreaders.

可能會先用其他方式去聊天 (tin?),長期的話再來看看要怎麼搭...

嘲笑某些大公司的技術文章...

看到「Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY」這篇,建議一定要搭著看 Hacker News 上的各種評論 (或者叫做「導讀」):「We at $Famous_company switched to $Hyped_technology (saagarjha.com)」。

在「導讀」裡面的馬上就看到三篇文章,然後也有一些討論:

另外討論裡面還有用到大量的 $VARIABLE 在嗆來嗆去,還被拿來反諷 Hacker News 上的各種 comments XD

原作者提到的這些技術文章大多都是 workaround,代表只有在很特定的情況下帶來的優點會大於缺點。

這些大公司會選擇某種 workaround 通常跟他公司內的政治因素有關,但在這些文章裡面都不會描述出來 (無論是作者不知道,或者知道但不能寫)。在沒有說明「為什麼會這樣 workaround」的前提下,其實文章看過、知道技術上有這種解法就好。

而且在實務上,除非你處理的資料量有一定的規模 (通常是在這些大公司內),不然一般人手上的資料量,以現在硬體的發展情勢,「暴力」其實可以解決很多問題。

整個產業透過雲端改變了不少以前的思維:這是個可以在 AWS 上租 x1e.32xlarge 把資料全部放到記憶體裡面 random access (128 vCPU + 3904 GB RAM),就算是寫爛的 O(n^2) 演算法,先開個幾千台 EC2 instance 撐著,再花時間慢慢解。

這跟以前自己弄硬體的思維跟雲端的思維玩法不一樣,「等產品衝起來再說」(或者說「活下去再還技術債」) 的可行性變得更高。

AWS Elemental Link:直接把影音訊號丟到雲端的硬體

AWS 推出了 Live 用的硬體設備 AWS Elemental Link,可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上:「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。

機器很輕 (450g) 也不大 (32 立方英呎,大約 524 立方公分):

界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI,規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限),然後設備除了透過一般電力供電以外,也可以用 PoE 供電,可以少接一條電源線:

Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.

價位上是賣 USD$995,但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品,好像沒看到類似可以直接送到網路服務的產品...