uv:用 Rust 寫的 Python Packaging 替代方案

社群好幾個地方都有提到的「uv: Python packaging in Rust」這個,文章開頭的說明有快速說明目標是 pip 的 drop-in replacement:

TL;DR: uv is an extremely fast Python package installer and resolver, written in Rust, and designed as a drop-in replacement for pip and pip-tools workflows.

這跟「Ruff:用 Rust 寫的 Python Linter」都是 Astral 下的專案,主打用 Rust 改善速度的專案。

馬上想到的是 package resolver,這指的是依照每個套件指定的相依條件,找出符合所有條件的版本組合。

這在各個語言的套件系統上都是痛點,而在「Dependency hell is NP-complete」這篇就有指出這是 NP-complete

這是因為 3SAT 問題可以 PTIME 轉成 package resolver 問題 (於是就 NP-hard 了),再加上有 PTIME 的驗證,就變成 NP-complete 了。

但看說明應該是不只這個部分,包括了一些 i/o 類操作的改善。

除了速度以外,uv 也提供了讓測試更方便的功能,像是在計算相容版本時,預設的演算法是儘量都裝最新版,但你可以指定要儘量裝最舊的版本,這樣對於相容性測試頗有用的:

But by passing --resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.)

這個工具的出現也是頗有幫助,我記得寫 Python 專案時隨便引入個 Django,再多拉幾個套件,跑起 package resolver 就要花不少時間了,可以想像中大型專案在這塊的痛點...

另外剛剛回去看了 ruff,從去年四月 500+ 條規則增加到 700+ 條了,在發表受到注目後應該補了不少社群常用到的規則,說不定新專案可以無痛跳進去了,去年的時候試著用,有發現常見的規則還沒有支援...

libchewing 更新,0.6.0 釋出

新酷音的 libchewing 專案釋出了 0.6.0,上次的 release 的 0.5.1 是 2016 年了:「Release v0.6.0 · chewing/libchewing」。

This release contains many improvements and bug fixes. It's the first release since 2016. We have started a major rewrite in Rust so we expect to have more frequent releases in the following months.

Contributors to chewing/libchewing 這邊可以看到近期主要是 kanru 的貢獻,然後就如同上面引用的 release note 中提到的,目前朝著 Rust 這邊開始走。

另外一個比較大的改變 (build stage 的) 是把本來用 autotools 的部分換成 cmake 了:

Add several CMake presets for supported configurations [Kan-ru Chen]. #424

CMake minimum version changed to 3.21.0

Autotools build tools are removed. CMake is the recommended way to build libchewing.

整體看起來,這版看起來主要是把這七年多的各種 bugfix 整理起來出一個 release 了,讓各 repository 可以更新一波?

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇:「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」,原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報,提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal(),透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal(),直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy()memmove() 類的地方,算是很常見備用到的功能,這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到:「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」,所以後續應該也會有些改善的討論...

Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這,上游的 glibc 也有對應的追蹤:「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息,因為 patch space 的大小限制,AMD 可能無法提供 CPU microcode 上的 patch,直接解決問題:

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround,回到原來沒有 FSRM 的方式處理:

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境,得拿出不同的 profiling 工具出來用,所以也還蠻值得看過一次有個印象:

一開始的 timeit 算是 Python 裡面簡單的 benchmark library:

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑),查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+):

再來是用 strace 追問題,這個算是經典工具了,可以拿來看 syscall 被呼叫的時間點:

到後面出現了 perf 可以拿來看更底層的資訊,像是 CPU 內 cache 的情況:

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式,不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析:

而文章裡的則是可以看到已經到 assembly 層級了:

差不多就這些...

InfluxDB 好像又在搞事了:從 Golang 換 Rust

在「Influxdb made the switch from Go to Rust (reddit.com)」這邊看到 RedditInfluxDB 的 CTO 出來的解釋:「influxdb officially made the switch from Go => Rust」。

可以看到 Hacker News 上的討論很多人都有提到 InfluxDB 的各種問題,而且在量還不大的時候就會遇到了。

這次 Golang 換成 Rust,依照 InfluxDB CTO 的說法有這些「優點」:

  • No garbage collector
  • Fearless concurrency (thanks Rust compiler)
  • Performance
  • Error handling
  • Crates

不過如果在 Golang 沒辦法解決 scalability 的問題 (通常需要 profiling 找出熱點然後改善演算法),Rust 這邊遇到一樣的問題應該也是一樣炸裂...

另外這家公司先前也出過事,七月的時候 InfluxDB 把比利時區的服務給關掉,但有不少客戶因為種種原因沒有收到通知,加上他們是直接 hard shutdown (沒有備份資料),造成 InfluxDB Cloud 的企業用戶直接幹翻天:「InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion (influxdata.com)」。

基本上可以閃遠一點... 目前看到的替代方案有 TimescaleDB (在 comment 裡有看到一些抱怨) 與 Clickhouse (在這篇的 comment 討論的比較少)。

Ruff:用 Rust 寫的 Python Linter

Hacker News Daily 上看到「Astral (astral.sh)」這個,網站在「Astral: Next-gen Python tooling」。

裡面提到的 Ruff 專案是一套用 Rust 寫的 Python Linter,主打就是速度,從官網提供的 benchmark 就可以看出來差距:

因為是 Python ecosystem 的東西,安裝可以直接用 pip 裝預設編好的套件,而不需要透過 cargo 自己編 (當然你想要還是可以用 cagro 編)。

feedgen 測了一下,速度是真的快,這樣就比較不會嫌棄了... 要注意會冒出 .ruff_cache/ 目錄,.gitignore 要加一下。

然後用預設值先掃出 unused import 修掉,其他的有機會再看要怎麼改。

AWS 官方推出了自己的 Amazon S3 FUSE 套件

看到「Mountpoint for Amazon S3」這個專案,AWS 自己推出了自己的 Amazon S3 FUSE 套件。Hacker News 上也有一些討論:「Mountpoint – file client for S3 written in Rust, from AWS (github.com/awslabs)」。

Amazon S3 的價錢比其他 AWS 提供的 storage 都便宜不少。以美東第一區 us-east-1 來說,S3 是 $0.023/GB,而 EBS (gp3) 要 $0.08/GB,即使是 EBS (st1) 也要 $0.045/GB。

S3 相較於 EBS 來說,多了 API call 的費用,所以對於不會產生大量 API call 的應用來說 (像是常常會寫很大包的資料到檔案裡),透過 FUSE 操作 Amazon S3 可以讓現有的套裝軟體或是程式直接跑上去。

另外一個常見的應用是讓套裝軟體或是現成的程式可以讀取 S3 的資料。

之前這類應用馬上會想到的專案是 s3fs-fuse,這個專案很久了,大家也都知道多人寫入的部份會是痛點。

這次 AWS 自己出來做的事情有點重工,看起來他想做的事情 s3fs-fuse 都解的差不多了,目前看起來唯一的賣點應該只有 Rust-based,但 s3fs-fuse 主要是 C++,其實也沒差到哪裡:

Mountpoint for Amazon S3 is optimized for read-heavy workloads that need high throughput. It intentionally does not implement the full POSIX specification for file systems.

目前專案還是 alpha release,不確定專案的方向到底是什麼...

Tor 的 Rust 計畫 Arti 推進到 1.0.0 版

在「Arti 1.0.0 is released: Our Rust Tor implementation is ready for production use.」這邊看到 TorRust 計畫進入了 1.0.0 版。

不過每次編 Rust 的東西都會發現 Rust 版本不夠新,這次也不例外,就不知道是 Rust community 的特性還是真的太少用 Rust...

    Updating crates.io index
  Downloaded arti v1.0.0
error: failed to parse manifest at `/home/gslin/.cargo/registry/src/github.com-1ecc6299db9ec823/arti-1.0.0/Cargo.toml`

Caused by:
  feature `edition2021` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["edition2021"]` to enable this feature

rustup update 更新後就能編了,然後跑起來看起來沒什麼問題:

$ arti proxy -p 9150
2022-09-03T17:13:30.234032Z  INFO arti: Starting Arti 1.0.0 in SOCKS proxy mode on port 9150...
2022-09-03T17:13:30.238606Z  INFO tor_circmgr: We now own the lock on our state files.
2022-09-03T17:13:30.238652Z  INFO tor_dirmgr: Didn't get usable directory from cache.
2022-09-03T17:13:30.238674Z  INFO arti::socks: Listening on 127.0.0.1:9150.
2022-09-03T17:13:30.238686Z  INFO arti::socks: Listening on [::1]:9150.
2022-09-03T17:13:30.238713Z  INFO tor_dirmgr::bootstrap: 1: Looking for a consensus.
2022-09-03T17:13:33.833304Z  INFO tor_dirmgr::bootstrap: 1: Downloading certificates for consensus (we are missing 9/9).
2022-09-03T17:13:34.335754Z  INFO tor_dirmgr::bootstrap: 1: Downloading microdescriptors (we are missing 6629).
2022-09-03T17:13:41.041683Z  INFO tor_dirmgr::state: The current consensus is fresh until 2022-09-03 17:00:00.0 +00:00:00, and valid until 2022-09-03 19:00:00.0 +00:00:00. I've picked 2022-09-03 18:35:38.290798754 +00:00:00 as the earliest time to replace it.
2022-09-03T17:13:41.061978Z  INFO tor_dirmgr: Marked consensus usable.
2022-09-03T17:13:41.065536Z  INFO tor_dirmgr: Directory is complete.
2022-09-03T17:13:41.065557Z  INFO tor_dirmgr: We have enough information to build circuits.
2022-09-03T17:13:41.065564Z  INFO arti: Sufficiently bootstrapped; system SOCKS now functional.

curl 測試也的確是 Tor 的 exit node 了:

$ curl -i --socks5 127.0.0.1:9150 https://httpbin.org/ip
HTTP/2 200 
date: Sat, 03 Sep 2022 17:21:20 GMT
content-type: application/json
content-length: 32
server: gunicorn/19.9.0
access-control-allow-origin: *
access-control-allow-credentials: true

{
  "origin": "85.93.218.204"
}

$ host 85.93.218.204
204.218.93.85.in-addr.arpa domain name pointer tor.localhost.lu.

看起來 client 的功能能用了...

jless:檢視 JSON 的工具

前幾天在「Show HN: Jless, a command-line JSON viewer (pauljuliusmartinez.github.io)」這邊看到用 Rust 寫的 jless 這個工具,官網有個動圖可以參考:

這樣方便不少,就不需要自己在對半天...

另外也剛好拿來練手,把 Rust 寫的套件包成 Ubuntu PPA:「PPA for jless」。

主要是 cargo vendor 這個指令可以把相依套件都抓下來放到 vendor/ 下面,然後設定 .cargo/config.toml 後就可以在本地端處理了,這對於 build farm 限制 internet 連線的情況會好用很多...

Psst:Open Source 且非 Electron 版本的 Spotify 播放器

前幾天在 Hacker News 首頁上看到的東西,而且也是當天熱度超高的話題,Open Source 且非 Electron 版本的 Spotify 播放器 Psst:「Psst: Fast Spotify client with native GUI, without Electron, built in Rust (github.com/jpochyla)」。

因為使用 Rust 與 native GUI library,加上沒有一堆 Spotify 內建的廣告系統,整個速度快到爆炸 XDDD

專案的擁有者 jpochyla 在「make provided binaries more prominent #89」這邊有提到有 nightly build 可以用:「nightly.link | Repository jpochyla/psst | Workflow build.yml | Branch master」,不過我抓下來發現不會動,所以就自己花了些時間編看看...

剛被推上 Hacker News 的時候 README.md 上的指示還沒那麼清楚,編不起來,後來這兩天陸陸續續被修正了。

桌機是 Ubuntu 20.04,而用 Ubuntu 20.04 內包的 rustc (1.51.0) 是沒辦法編的,需要自己先透過 rustup 裝新版 1.54.0 來編,基本上照著 README.md 的指示先把 dependency 裝起來,然後照著對應的指令操作就可以了。

這樣之後聽音樂方便不少...

快速產生 SQLite 資料的方式:一分鐘內產生十億筆資料

在「Towards Inserting One Billion Rows in SQLite Under A Minute」這邊看到作者想要在一分鐘內在 MBP 2019 上面寫 1B 筆資料進 SQLite,裡面有些方法還蠻值得玩一下的,這台 MBP 2019 機器的規格是:

The machine I am using is MacBook Pro, 2019 (2.4 GHz Quad Core i5, 8GB, 256GB SSD, Big Sur 11.1)

第一版是 Python 寫的,塞 10M 筆花了 15 分鐘:

In this script, I tried to insert 10M rows, one by one, in a for loop. This version took close to 15 minutes, sparked my curiosity and made me explore further to reduce the time.

加了五個 PRAGMA 的版本變成 100M 筆十分鐘:

The naive for loop version took about 10 minutes to insert 100M rows.

用批次處理則可以降到八分半:

The batched version took about 8.5 minutes to insert 100M rows.

再來是拿經典神器 PyPy 出來用,降到兩分半:

All I had to do was run my existing code, without any change, using PyPy. It worked and the speed bump was phenomenal. The batched version took only 2.5 minutes to insert 100M rows. I got close to 3.5x speed :)

接下來就是跳槽到 Rust 了,中間也有不少 tuning 相關的討論,但直接先跳到最後面好了... 最後 100M 只用了 33 秒:

I created a threaded version, where I had one writer thread that received data from a channel and four other threads which pushed data to the channel. This is the current best version which took about 32.37 seconds.

能用 PyPy 的地方還是可以考慮一下的...