換到 PHP 7.3

上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」),這次是在整理機器時發現 blog 這台機器還在跑 7.2,就更新一下系統把上面的站台都換到 7.3。

蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」),目前看到的資料都會快一些,應該是沒有太大問題,之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB,但用 opcache-status 看起來只用了 65 MB 左右),把記憶體空間讓給其他程式用...

不過 7.4 也快出了...

Linux 上 Intel CPU 的安全性修正與效能的影響

Hacker News Daily 上看到在講 Intel CPU 因為各種安全性問題,而需要在 Linux Kernel 上修正,所產生的效能問題:「HOWTO make Linux run blazing fast (again) on Intel CPUs」。

這一系列的子彈也飛得夠久了 (雖然還是一直有其他的小子彈在飛),所以回過頭來看一下目前的情況。

這邊主要的測試是針對 mitigations=off 與 SMT 的啟用兩個項目在測 (SMT 在 Intel 上叫做 Hyper-threading),可以看到這兩份測試結果,目前的 mitigation 對效能的影響其實已經逐漸降到可以接受的程度 (小於 5%),但關閉 SMT 造成的效能影響大約都在 20%~30%:

但是開啟 SMT 基本上是個大坑,如果有關注大家在挖洞的對象,可以看到一堆 Intel CPU 上專屬的安全性問題都跟 SMT 有關...

剛好岔個題聊一下,先前弄了一顆 AMDRyzen 7 3700X 在用 (也是跑 Linux 桌機),才感受到現在的網頁真的很吃 CPU,開個網頁版的 SlackOffice 365 的速度比原來的老機器快了好多,差點想要把家裡的桌機也換掉...

用更少訓練時間的 KataGo

最近開始在不同的地方會看到 KataGo 這個名字 (TwitterYouTube 上都有看到),翻了一下資料發現是在訓練成本上有重大突破,依照論文的宣稱快了五十倍...

在第一次跑的時候,只用了 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 的消息,看起來作者也在裡面一起討論,應該會有一些結果出來...

延遲載入 CSS 的方式

在「Simpler way to load CSS asynchronously」這邊看到的技巧,利用了 onload<noscript> 的方式,達成延遲載入 CSS 的效果:

<link rel="stylesheet" href="/path/to/my.css"
      media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

對於非必要的 CSS 可以用這樣的方式加強,看起來頗不賴... 這邊提到的方式,作者是引用「Smashing Newsletter: Issue #234」,不過查了一下發現 2015 的時候有人在 StackOverflow 上回答過:「How to load CSS Asynchronously」,不確定有沒有更早的資料...

另外一個比較新的語法是使用 rel="preload",但支援度就不太好了,需要靠 polyfill 之類的方式補上 (於是又多了一些東西要 load),反而不如前面提到的方式來的簡單。

Hacker News

早上看到「Tell HN: Thank you for not redesigning Hacker News」這篇,作者在網路速度受限的地區,上各種網站幾乎都不會動,但 Hacker News 沒有改用一堆前端框架,而是保留使用 HTML 反而讓頁面維持極小:

I’m currently in a country with low speed internet and the entire ‘modern’ web is basically unusable except HN, which still loads instantly. Reddit, Twitter, news and banking sites are all painfully slow or simply time out altogether.

To PG, the mods and whoever else is responsible: thank you for not trying to ‘fix’ what isn’t broken.

順手開了一下網路工具來看,發現單一元件最大的居然是 favicon XDDD:

Wikipedia 上列出來的相容性,如果只支援 IE11+ 的話,看起來可以改用 PNG,大小就已經有明顯的改善了:

-rw-r--r-- 1 gslin staff 7527 Sep  2 09:50 favicon.ico
-rw-r--r-- 1 gslin staff 2598 Sep  2 09:51 favicon.png

操作 S3 Command Line 的工具

在朋友的 Facebook 上看的東西:「S5cmd for High Performance Object Storage」。會想要寫這篇是因為看到 s4cmds5cmd 這兩個工具的命名而笑出來:

不過這篇也可以看到差異,s3cmd 是自己用 Python 刻所有東西,s4cmd 還是用 Python,但是因為 boto3 而快了不少,而 s5cmd 則是改用 Golang 寫,並且採用多個 TCP connection 操作而讓效能大幅提昇。

Facebook 推出了 Hermes,為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine:「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy,針對行動裝置的特性而設計:避免 JIT 產生的 overhead,以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊:

不過沒有提到 CPU usage 會上升多少,只是帶過去:

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量,但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息,在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字,不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇,好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字,不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了,要一直壓榨效能,最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善),現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料,而其他 workspace 的頁面就只保留狀態 (透過 Redux):

從記憶體用量可以看出來:

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料,所以啟動時間也就下降了不少,但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render),不過大概是考慮到常見情境下的切換次數而決定這樣做,應該還算 ok...

Vim 的 Performance Profiling

在「Profiling Vim」這邊看到 Vim 上常見的效能問題,很多時候會覺得「慢」但不知道慢在哪邊的問題...

文章作者已經知道是開 Markdown 檔案時的問題,所以可以在開啟 Vim 後用下指令啟動 profiling,但如果是想要追蹤一開起來很慢的問題,可以看「對 Vim 啟動過程做效能分析」這篇的方式,直接在啟動時加上 --startuptime vim.log 這樣的語法,把 log 寫到 vim.log 裡面。