在 Hacker News 首頁上看到這個小遊戲:「Show HN: Looptap – A minimal game to waste your time (vasanthv.com)」,如同他的標題寫的,浪費時間的小遊戲 XDDD
標題講的 QTE 是「快速反應事件」這個東西,在現在的遊戲裡面算是蠻常見的機制,是一種需要在事件有效區間反應的設計 (太早反應或是太晚反應都不行)。
幹壞事是進步最大的原動力
在 Hacker News 首頁上看到這個小遊戲:「Show HN: Looptap – A minimal game to waste your time (vasanthv.com)」,如同他的標題寫的,浪費時間的小遊戲 XDDD
標題講的 QTE 是「快速反應事件」這個東西,在現在的遊戲裡面算是蠻常見的機制,是一種需要在事件有效區間反應的設計 (太早反應或是太晚反應都不行)。
在 Lobsters Daily 上看到有強者在 Minecraft 實做邏輯電路,幹出一台完整的電腦出來 (CPU 的部份應該是 turing-complete 了):
PCWorld 有報導:「This 8-bit processor built in Minecraft can run its own games」。
把影片裡的描述截圖出來:
連分支預測器都出現了:
記憶體就 Minecraft 來說也是超大的 256 bytes:
然後還做了 cache 層,這邊提到的是 data cache:
然後這邊是 instruction cache:
也因為已經相當的 powerful,很多經典遊戲都可以玩,像是俄羅斯方塊:
貪食蛇:
打磚塊:
在 Hacker News Daily 上看到「Lossless Image Compression in O(n) Time」這篇,作者丟出了一個圖片的無損壓縮演算法,壓縮與解壓縮的速度超快,但壓縮率又不輸 PNG 太多,在 Hacker News 上的討論也可以看一下:「QOI: Lossless Image Compression in O(n) Time (phoboslab.org)」。
裡面有提到在遊戲產業常用到的 stb_image.h:
Yes, stb_image saved us all from the pains of dealing with libpng and is therefore used in countless games and apps. A while ago I aimed to do the same for video with pl_mpeg, with some success.
作者的簡介也可以看到他的主業也在遊戲這塊:
My name is Dominic Szablewski. I build games, experiment with JavaScript and occasionally tinker with low-level C.
圖片的無損壓縮與解壓縮算是遊戲創作者蠻常用到的功能,所以他想要看看這塊有沒有機會有更好的工具,於是他就用了四個很簡單的演算法幹完了 QOI (然後發現效果很讚):
其實從 Hacker News 的討論也可以看到這組演算法也常被拿出來在現代的壓縮演算法使用,所以雖然作者自稱不是 compression guy,但他用的演算法其實蠻專業的...
然後挑 single thread 主要是可以避免 threading 的複雜度以及 overhead,在「QOI Benchmark Results」這頁可以看到,無論是什麼類型的檔案,壓縮與解壓縮的速度都相當漂亮,而且壓縮率又沒有差 libpng 太多。
而且作者自己有提到,還沒用到 SIMD 指令集加速,這樣猜測應該還有不少空間...
標題不知道怎麼下,大概就是這樣...
從 Hacker News 首頁上翻到的,以這個 upvote 數量來看,應該會收到今天的 Hacker News Daily 上:「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。
作者是一位獨立遊戲開發者,在兩年前推出了「ΔV: Rings of Saturn」這款遊戲,並且也發佈了 Linux 版。
作者先就數字來比較,他賣出了 12000 套,其中 700 套是 Linux 玩家;另外他收到了 1040 個 bug report,其中大約 400 個是從 Linux 玩家回報的:
As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.
That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.
看文章時可能會覺得「Linux 玩家真難伺候」,但實際上作者講到,這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上),其他的 bug 其實是所有平台都會發生:
A lot of extra work for just 5.8% of extra units, right?
Wrong. Bugs exist whenever you know about them, or not.
Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]
原因是 Linux 社群在參與各種 open source project 養成的習慣,會盡可能把各種資訊講清楚,並且找出可以重製問題的方式:
The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!
But that’s not all. The report quality is stellar.
與一般玩家的回報方式完全不同,Linux 玩家很習慣就會附上基本的環境資訊,系統紀錄,甚至有時候還會包括 core dump 與 reproducible steps:
I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.
And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.
不知道有沒有遇到回報 GDB 資訊的...
很特別的分享 XDDD
AMD 推出了功能上類似於 Nvidia 的 DLSS 的技術,叫做 FidelityFX Super Resolution (FSR),並且 open source 出來:「AMD FidelityFX Super Resolution is Here」,另外可以看一下 GPUOpen 官方網站裡面的內容。
DLSS 的機制上可以這樣解釋,遊戲輸出 1080p,透過 machine learning 運算的方式將畫質提升到 2K 或是 4K,這樣比起遊戲直接要計算 2K 或是 4K 的輸出內容,運算量可能會比較少。
不過 DLSS 只能跑在 RTX 20xx 與 30xx 系列的顯卡上,以前的舊顯卡不支援。而先前 AMD 公佈 FSR 的時候,除了是宣示 AMD 也推出類似的技術外,另外一個賣點是 FSR 可以跑在 Nvidia 的顯卡上。
而這次的消息則是又多說明了 open source 的釋出部份,將在七月中放出來:「AMD FidelityFX Super Resolution is Here」。
The source code for FidelityFX Super Resolution 1.0 will be coming to GPUOpen in mid July!
目前有七個遊戲支援,後續會有更多遊戲加入...
本來花了一些功夫整理了一下 KataGo + Lizzie 純 CPU 版本在 Windows 上的安裝方式 (在「KataGo/Windows」這邊),後來找了一下發現早就有人做的更簡單了:「BadukMegapack」。
底層的部份除了可以選擇裝 KataGo 外,也可以選擇目前已經停止維護的 Leela Zero,或是 SAI、AQ 與 Ray。
而界面的部份除了可以用 Lizzie 外 (而且還是改過的加強版 XD),還可以選其他的界面... 除此之外還連 JVM (Java 8) 都一起拉進來幫你裝。
看起來算是包的好好的... 看起來最困難的應該是弄一張高階顯卡了?
看到「GTA Online load time fix released, shaves off actual minutes of waiting for some」這邊的消息,先前在「GTA 的啟動讀取效能問題」這邊提到 GTA Online 啟動速度很慢的問題,官方正式推出修正版本了:「GTAV Title Update 1.53 Notes (PS4 / Xbox One / PC)」。
抓了一些在 Reddit 的討論「Loading Times Have FINALLY been patched - Discussion Thread」。
這則降的比率與當時 workaround 的修正差不多:
Insane. GTA menu -> GTA: Online.
Dropped from 7 minutes to 1:57
i7-2600k,GTX1070,16GB RAM and the game is on HDD.
這個就有點誇張了,這是 90% 吧?
Dropped from 5-8 minutes to 35 seconds
這個差不多 70%~80%:
Loading time 2m 20s for online directly from steam. Before it was like 8-10 minutes for me. Damn
Edit: 50s for story mode. 35s from story mode to online. So it seems it's still faster to load into online from story mode.
這個也差不多 70%:
From 4-5 minutes to 1 a minute and 22 seconds. Y e s p l e a s e
然後 PS4 的版本原來也受到一樣的影響?
Currently tested on PS4 , from main menu to online : 3min 45 sec From story mode to online: 1min 20sec (😩 i can't tell for sure )
整體看起來是正面的,畢竟大家等這個問題等超久了... 另外也可以看出來當初的 workaround patch 其實相當精準的把問題都解掉了,官方的修正並沒有快更多。
來繼續關注 libc 那邊的問題...
這件事情也已經過了一個禮拜,來整理一下發生什麼事情...
起因是 GTA Online 的遊戲開啟速度很慢,而有人一路 reverse engineering 找出問題並且解決:「How I cut GTA Online loading times by 70%」,對應的 Hacker News 討論有提到其他有趣的事情也可以看看:「How I cut GTA Online loading times by 70% (nee.lv)」。
作者的電腦不算太差,但光開啟 GTA Online 就需要六分鐘,網路上甚至有辦投票蒐集大家的等待時間,發現也有很多人反應類似的問題:
接下來就開始 reverse engineering 了,先觀察各種狀態後發現是卡在 CPU,而不是網路或 Disk I/O,然後就拿出 Luke Stackwalker 這個工具 profiling,不過因為沒有 debug symbol 幫忙 group,所以只能人工判斷後,可以看到兩個問題:
第一個問題發現效能是卡在 strlen()
,而 call stack 可以看出來是從 sscanf()
一路打進去的:
反追發現是在處理 10MB 的 JSON 檔造成的,裡面 sscanf()
因為拉出 strlen()
,於是就造成把整個 10MB 的 JSON 掃過很多次 (一開始是 10MB,掃到後面會愈來愈少,平均下來應該是 5MB):
第二個問題產生的時間會在第一個問題跑完後,另外看問題的性質,應該跟第一個 JSON 處理有關,他會把 JSON 處理過的資料丟進 array,每個 entry 長這樣:
struct { uint64_t *hash; item_t *item; } entry;
丟進 array 是 OK 的,但問題在於他需要判斷 entry 是否重複,卻沒有用 hash 或是 tree 的結構,而這邊大約有 63k 筆資料,用 array 實做就產生了 O(n^2) 的演算法:
But before it’s stored? It checks the entire array, one by one, comparing the hash of the item to see if it’s in the list or not. With ~63k entries that’s (n^2+n)/2 = (63000^2+63000)/2 = 1984531500 checks if my math is right. Most of them useless. You have unique hashes why not use a hash map.
作者在 PoC 的章節裡面描述他怎麼解這兩個問題。
第一個問題比較好的解法是修正 JSON Parser,但這太複雜,所以他用 workaround 解:把 strlen()
包起來,針對長字串加上一層 cache:
- hook strlen
- wait for a long string
- “cache” the start and length of it
- if it’s called again within the string’s range, return cached value
而第二個問題他直接把檢查是否有重複的跳過,因為資料本身不重複:
And as for the hash-array problem, it’s more straightforward - just skip the duplicate checks entirely and insert the items directly since we know the values are unique.
整個開啟的速度從六分鐘降到一分五十秒,還是偏慢,但算是大幅緩解的 GTA Online 啟動速度的問題了。
不過故事到這邊還沒結束,有人一路去挖,發現其實 sscanf()
的效能地雷已經不是第一次了:YAML 的 Parser 也中過一樣的問題:「Parsing can become accidentally quadratic because of sscanf」,這篇也一樣上了 Hacker News:「Parsing can become accidentally quadratic because of sscanf (github.com/biojppm)」。
然後這又帶出了六年前在 StackOverflow 上就有人問過這個問題:「Why is glibc's sscanf vastly slower than fscanf on Linux?」。
另外也有人整理出來,應該是大家把同樣的演算法拿來實做:
JdeBP 3 days ago
I found this while making a collection of what C implementation does what at https://news.ycombinator.com/item?id=26298300.
There are two basic implementation strategies. The BSD (FreeBSD and OpenBSD and more than likely NetBSD too), Microsoft, GNU, and MUSL C libraries use one, and suffer from this; whereas the OpenWatcom, P.J. Plauger, Tru64 Unix, and my standard C libraries use another, and do not.
The 2002 report in the comp.lang.c Usenet newsgroup (listed in that discussion) is the earliest that I've found so far.
後續的更新動作可以再追一下進度 (包括 GTA Online 與各家的 libc)。
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 成果更新上去跑。
在 Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:
Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.
裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:
回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1
的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLS 與 DNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...