rust – Gea-Suan Lin's BLOG

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.」這邊看到 Tor 的 Rust 計畫進入了 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 的地方還是可以考慮一下的...

Nokia 釋出的 Memory Profiler

用 Rust 開發的 memory profiler，可以抓 memory leaking 與 memory fragmentation，然後宣稱效能影響也比較低：「A memory profiler for Linux」，有提供網頁界面，還蠻美觀的：

給的範例有兩行，一行是跑 profiler：

LD_PRELOAD=./libmemory_profiler.so ./your_application

另外一行是讀資料給 HTTP server：

./memory-profiler-cli server memory-profiling_*.dat

之後有機會抓漏時可以拿來用看看...

Cloudflare 自己用 Rust 寫了一套相容 WireGuard 協定的軟體

Cloudflare 發現目前符合他們條件的 WireGuard 軟體效能不夠好，所以就用 Rust 寫了一套出來：「BoringTun, a userspace WireGuard implementation in Rust」，軟體在「BoringTun」這邊可以看到。

Cloudflare 的條件是 userspace 以及多平台，市面上有 wireguard-go 符合這兩個條件，但效能不太好，所以就下去寫了。

GitHub 的頁面上可以看出還在剛開始的階段，很多頁面都還只有個雛型... 等這幾天陸陸續續更新後再回來看好了。

Rust 版本 Mercurial

看到「Mercurial: 964212780daf」這則 commit log，看起來 Mercurial 從 Python 換成 Rust 的計畫正在進行中：

rust: implementation of `hg`

This commit provides a mostly-working implementation of the `hg` script in Rust along with scaffolding to support Rust in the repository.

之前從朋友那邊聽到，在 F 公司用 Mercurial 用到覺得很厭世，主要是因為 repository 太大，一跑下去就會發現記憶體用量與速度都很無奈 (即使內部已經有不少工具改善速度)，所以就啟動專案要換一個程式語言，直接拼最後那段的效能 XD

如果是隔壁棚的 Git... 就沒這個問題，一開始 Git 就用 C 寫，所以如果厭世的話也不太容易生出什麼進展了 XDDD

Rust 是不錯啦，不過...

作者寫了一篇「Creating Rust-based NodeJS modules」講同樣演算法 Node.js 要跑 3.5 秒，Rust 只要跑 130ms，所以 Rust 很棒棒之類的...

So about 3.5 seconds for an answer, in web time that is like an eternity. Our algorithm is a very straight forward one, basically just a filter on a large array.

The exact same algorithm, with the exact same CSV and coordinates is now executing in about 130ms.

然後仔細看了一下他的範例，holy...

這讓我想到之前在「看到 zmx 貼了之前的連結，更確信 Uber 的問題不是技術問題了...」這篇提到的文章「Unwinding Uber’s Most Efficient Service」：

TLDR;
Uber：傳統方式太複雜了根據我們資料特性自創一套高效能的空間索引服務。
前 Bing 員工：買了 Bing 怎麼不問專家啊？Quadtree 降兩個數量級啊，不然你們自創的做了這個小修改也是降兩個數量級啊！https://t.co/nHw1DgmYtU

— zmx (@zmx) August 2, 2016

很想講「傻逼你先把演算法修好再來怪 Node.js 慢」，程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-