Nagi 0.1 性能・検証報告

この版は、Rust製コンパイラと実ランタイムを持つ、二層バックエンド言語の試作です。Highから編集可能なLowテキストを生成し、それを再解析・検査してRust経由でネイティブへコンパイルします。HTTP body → 型付きclass → SQLite → class → JSONのCRUD経路、Lowの通常関数呼び出し・関数置換、async/scope、actor間通信、worker再起動が実際に動きます。

汎用言語、本番用独自runtime、BEAM相当の障害隔離は未完成です。actor・Supervisor・queueは実ランタイムを呼ぶ標準試験関数で、Highの汎用宣言構文はまだありません。以下の数値は、記載した測定環境で採取したログに基づきます。サンプル名は公開用に匿名化し、測定時と同じASCIIのバイト長を維持しています。測定値は変更していません。

測定環境と再現条件

CPU/microbenchはserver負荷・ビルドと重ねず、CPU 0へ固定して個別に実行しました。各Rust測定は5回warmup、pilotから1反復のloop数を決め、7反復のmedianです。Pythonは5回warmupと7×25回、NodeはJIT用50回warmupと7×100回です。準備済みの同じ100,000要素を使用し、配列生成は計測外です。整数入力は (i*17+13)%997-498、floatはその値を7で割ります。Node Numberでも今回の整数入力・結果は正確ですが、i64全範囲の意味は共有しません。

試行内にも揺れがあり、CPU周波数、共有ホストの競合、cache状態の完全な制御はしていません。単一環境での探索的計測です。別実行の数%の差から言語の優劣を断定しません。raw_nsを保存し、良い値だけの選択はしていません。

allocation counterは呼び出しthreadのRust GlobalAlloc要求を数えます。SQLiteのC allocator・他threadのjob/task allocationは含みません。reallocはalloc回数にも含め、byteは要求量の累計でlive/peak memoryではありません。戻り値のdropはcount取得後なので、そのdeallocationは表に入りません。時間計測中はcounterを無効にしますが、allocator転送時のTLS分岐は残ります。静的cost reportは発生箇所であり、動的allocation回数ではありません。

CPU：同じ入力・同じ結果

kernel全体の時間はµs/opです。ns/itemは100,000要素で割ったamortized値であり、一つの加算の単独latencyではありません。

checksumは4実装で一致しました（floatは許容誤差1e-7）。{"integer_sum": -3184, "map_reduce": 90448, "filter_reduce": 12461527, "branch": 2106, "float_sum": -454.85714285709753, "loop": 299995}。Nagi/Rustのkernel内Rust allocationは全て0回です。Python/Nodeのallocationは未計測で、この0と比較しません。

CPythonのbuiltin sumは別の参考値として 686.172 µs/opでした。表のPythonは明示ループであり、NumPy等のnative kernelとの比較ではありません。データは反復中cacheへ温まるため、DRAM帯域や巨大datasetの処理速度も表していません。

Nagiはnative整数・連続配列を使い、動的な数値boxing・型判定をループ中に置きません。generated Rustと手書きRustの整数sumの逆アセンブルには、どちらもpacked i64加算の paddq が4箇所あります（integer-sum.asm / rust-integer-sum.asm）。LLVMのvector化・unrollがns/itemを下げています。手書きRustとの時間差には生成コード・配置・実行時の揺れがあり、独自backendがRustを上回ったという結果ではありません。

JSON・view・文字列のコスト

以下のJSONは id=42,name=alice,age=18 の小さい同一入力です。ns/opはparse/encode等の操作全体、allocationは1回の操作の動的測定です。

中間Value treeからUserへ変換する経路に対し、直接Userへdecodeする経路は今回 2.29×、allocationは5→1回、646→5 byteでした。Rust structへ直接deserializeしており、dict/map/汎用JSON treeを経由しません。残る1回は所有Stringフィールドです。

borrowed classは入力を指す&strを使う手書きRustの実験です。0 allocationでも、この試行ではowned classより速くはありませんでした。escapeを含むJSON文字列や入力寿命を越える保持には所有化が必要です。Highのclassにborrowed fieldを許す機能は未実装です。

encode時には128 byte capacityのVecを一つ作ります。reused buffer実験は0 allocationですが、HTTPへ一般適用していません。HTTP responseはnative class → Vec<u8> → Bodyであり、直接socketへserializeする完全streamingではありません。parse-modify-encodeはStringと出力Vecの2 allocationです。

view試験は1 MiB bufferの範囲参照を作るだけです。入力pointer+1とview pointerの一致、0 allocationを記録しました。copy試験は1,048,575 byteを実際に所有コピーします。処理内容が違うため両者の時間比を同じ処理の高速化率とは扱いません。HTTP受信bodyの借用が追加コピーを避けても、network/kernel/HTTP入力buffer全体がzero-copyという意味にはなりません。

SQLite → class：変換と所有化

同じin-memory SQLiteへ10,000件を事前投入し、cached SELECTから1/100/1,000/10,000件を取得します。id i64、name TEXT「alice」、age i32です。SQL実行・row stepping・class生成・Vecへの格納を含み、接続生成・seed insertは含みません。

列名をquery開始時に一度だけ番号へ解決する経路は、10,000件で列名を毎row解決する経路に対し 1.55×でした。FromRowは直接native fieldを読み、tuple/dict/ORM中間objectを作りません。TEXTはSQLite stepの寿命を越えて返すため、各rowに所有Stringが必要です。row変換全体が0 allocationという主張はできません。

id-only scanとの時間差にはTEXT取得・String allocation・3field変換・Vec格納が混ざり、純粋な変換時間を厳密に分離した値ではありません。reserveは要求byteとreallocを減らしますが、この10,000件試行では通常Vec成長より時間が増えました。全queryで件数を事前に知るためのCOUNTや推測reserveは導入していません。

1,000 insertを一つのtransactionで実行してrollbackする操作は 488.667 µs/op、1 insert+rollbackは 3.463 µs/opでした。Rust allocation counterが0でも、SQLite C allocator、ページ処理、disk I/Oが0という意味ではありません。今回はmemory DBで、永続化/fsync性能は測っていません。

HTTPからのDB jobは専用thread、bounded channel 64、oneshot replyを通ります。その往復・job boxing・async schedulingはこの同期microbenchには含みません。後述のHTTP db_single_rowは実際にその経路を含みます。型付きcolumn検査はruntimeで、コンパイル時schema/SQL検証はありません。

実測後の変更

列番号を毎query Vecで保持していた実装を、16列以内はinline配列へ変更しました。列数overflow時のみVecへ退避します。列順入れ替え・missing columnの既存テストを通し、同じベンチを再測定しました。

確実な効果はqueryごとの1 allocation / 32 byte削減です。10,000件の時間差は小さく、速度改善が統計的に確立したとは扱いません。初期ログはmicro-before.jsonl、変更後はmicro-after.jsonlです。

actorには最大32件のpipeline送信を追加しました。個々のmessageは同じmailboxを通り、全oneshot replyを受けて結果20,000を確認します。一つの「+20,000」にまとめた測定ではありません。結果は下に示します。JSON buffer再利用とDB Vec reserveは実験のみで、現在のHTTP/DB標準経路には入れていません。

HTTP：同じ成功payloadでの比較

全serverをCPU 0、1 executor/event-loop workerへ固定し、wrkはCPU 7/8、2 thread、64 keep-alive接続です。各case 1秒warmup→3秒測定、各framework/caseを3試行しました。framework順はseed固定で試行ごとに並べ替えます。Nagi/Axumは共通runtimeのtimeout/body-limit middlewareを使います。NagiのみSQLite threadが一つ常駐します。Node/aiohttpにこのmiddlewareを完全に移植したわけではなく、framework全体の同一内部処理を保証する比較ではありません。

Nagi/Axumは同じnative structを使用します。NodeはJSON.parse→field検査→JSON.stringify、aiohttpはjson.loads→slots dataclass→型検査→json.dumpsです。成功status/bodyをそろえています。Nagiだけschema検証を省く測定にはしていません。small_jsonは定数JSON byteの再送ではありません。

rpsとp50/p95/p99は3試行それぞれの値のmedian、maxは3試行の最大値です。複数試行のhistogramをmergeしたpercentileではありません。latencyの単位はµs。errorsはsocket/status/timeoutの合計です。

closed-loop wrkの値であり、一定到着率のopen-loopや過負荷時のtail latencyを評価したものではありません。同じruntimeを使う手書きAxumが主要なnative基準です。生成wrapperやhandlerの違い、body処理、allocation、SQLite workerを含む構成差を見て、CPU kernelの差とHTTPの差を分けて評価します。

小さいPOSTはNagi約39.9k req/s、手書きAxum約60.8k req/sで、今回Nagiが低い結果でした。大きいPOSTは約36k req/sで同じ桁です。小POSTの差を特定の関数のコストへ結び付けるprofileは取得できていません。生成wrapperとrouter/stateの扱いを分離する追加測定が必要で、native化だけでHTTPの全経路が最適になるとは判断しません。

次は測定区間のserver CPU使用率、終了時RSSの3試行最大、context switch/s（全server threadの合計差）、thread/FDの最大です。CPU使用率は1論理CPUを100%として、/procのCPU tick差をwall timeで割っています。load generator側のCPU/RSSは含めていません。

合計54試行でsocket/status/timeout errorは0件でした。正常応答の負荷比較であり、認証、TLS、HTTP/2、slow-client/DoS耐性、大容量streamを含む本番SLO試験ではありません。

120秒の継続負荷

Nagi /echo、4,096文字name、128接続、wrk 2 thread、server 1 workerで120秒実行しました。35,238 req/s、p50 3222 µs、p95 7209 µs、p99 16531 µs、max 176174 µs、socket/status/timeout error 0件です。

1秒ごとのRSSは 6.05–8.06 MiB、最終負荷sample 8.06 MiB、停止後5sampleは 7.16–7.16 MiBでした。FDは負荷中 10–138、停止後 10–10でした。

この有限時間で異常や未回収FDが観測されたかを確認する試験です。メモリリーク不在・数日安定性・allocator fragmentation・GC pauseを証明するものではありません。RSSが高水位から下がらない場合も、所有値のdrop、allocatorの保持、fragmentationを分ける追加観測が必要です。全processのallocation/free追跡やheap profilerは未実施です。

同時task・TCP接続

task試験はTokioの4 workerです。1,000/10,000/50,000/100,000 taskを生成し、各taskが最初のpollへ到達したことをatomic counterで確認します。Semaphoreを解放するまでは1件も完了できません。その時点のRSSを測り、全taskを解放・joinします。3試行のmedian時間と最大RSSです。gate、Arc、ready counter、spawn/joinのコストを含むテストharnessで、実アプリの1task単独コストではありません。

以前のconcurrency-before.jsonlは「spawnした総数」の試験で、全数が同時に待機していた保証とpeak観測がありません。gateを追加した後の時間とは直接比較しません。完了後のRSSはallocator保持を含み、未完了taskの数ではありません。CPU処理は別のspawn_blocking＋semaphore 4へ分けていますが、開始済みのblocking仕事の強制中断は未実装です。

TCPは実際に1,000/10,000接続を同時保持し、それぞれからhealth応答を受けます。open時のclient同時進行は128、server workerは1です。50,000/100,000 TCPは今回のFD上限16,384とIPv4 ephemeral port 32768–60999の条件で実施していません。100,000 taskの結果を100,000 TCP接続へ読み替えません。

FDは両試行で開始値へ戻りました。RSSは切断直後も高水位を保持しています。約250 MiBで10,000接続を保持できた観測はありますが、約25 KiB/接続の差分はHTTP buffer・runtime・allocator等を含むprocess全体の目安です。kernel socket memoryはRSSに含まれません。

actor・Supervisor・queue

同じCounterActor、mailbox 64、Tokio 4 worker、20,000 messageを5試行します。serial RPCは1件のreplyを待って次を送り、pipelineは最大32件を進行させます。下のµs/messageはelapsed/messagesのmedian相当で、個々のmessageのp50/p99 latencyではありません。

pipelineはserialに対しこの試行で 24.95×のthroughputでした。待機とscheduler往復を重ねて隠す改善で、1件のRPC latencyが同じ倍率で下がったという意味ではありません。mailbox message/replyのallocationと所有化は残ります。Highのsharedは明示Arcですが、task/channel/DB stateの内部Arcまで消す設計ではありません。

Supervisorはworker panicを3回検出し3回再起動、再起動latencyは 1.951–2.137 msでした。latencyはpanic検出から新しい子taskの最初のpollまでで、1 ms backoffを含みます。独立workerは12回継続しました。crash-loop試験は1秒windowで上限2に達した後、再起動停止を確認しました。SIGSEGV/abort/process killの隔離、request replay/loss、任意Supervisor treeは試験対象外です。

queueは1,000 job、8 worker、channel 64、最大3 attempt、retry backoff 1/2 msで、完了909、dead-letter 91、retry 312、peak in-flight 8でした。失敗はidから決めて注入します。DLQ件数を数える実験であり、永続DLQ、process再起動後のreplay、exactly-once APIはありません。

DB workerを100回生成・終了した後、live worker数は0→0でした。scope子taskのerror/panicでは他の子taskをcancelしてjoinし、guardが解放されたことをunit testで確認しています。外側futureのdropやbody panicではJoinSet Dropによるabort要求までで、その場で非同期cleanup完了を待つ保証はありません。

安全性・正しさの確認

High checkerの成功だけでsoundnessを保証していません。safe Rustを生成し、Rustのborrow/Send検査まで通ったものだけnative binaryにします。runtime側unsafeはSystem GlobalAlloc転送等の限られた観測実装にあり、Lowに任意unsafe/FFIを許す段階ではありません。生成コードとruntimeのdependencyに対する独立したsecurity auditはしていません。

実装状況と判断

有効だった方向は、native primitive＋連続配列、直接typed JSON、DB列番号の一回解決、不要な小Vecの除去、actor pipelineです。JSON借用やreserveはallocation削減と速度向上を分けて評価すべき結果でした。HTTPはhandler/runtime/serialization/schedulingを含むため、CPU kernelの倍率から予測できません。

次の実装は、算術・borrow仕様の確定、module/generic、任意state actorのlowering、typed DB paramの一般化、request arenaとbuffer再利用の実測の順が妥当です。完成に必要な工数を今回の試作速度だけから推定しません。Low self-hostはString/Map/module/allocator APIとbootstrap一致試験をそろえた後の段階です。

再実行と生ログ

ビルド・機能試験はREADMEの手順を使用します。数値の再測定時は同時にビルドや別のCPU benchmarkを走らせず、CPU affinityを環境に合わせて変更してください。

taskset -c 0 ./native-target/release/nagi-cpu > benchmarks/results/cpu-nagi.jsonl
taskset -c 0 ./target/release/examples/microbench > benchmarks/results/micro-after.jsonl
taskset -c 0 python3 benchmarks/python_cpu.py > benchmarks/results/cpu-python.jsonl
taskset -c 0 node benchmarks/node_cpu.js > benchmarks/results/cpu-node.jsonl
./target/release/examples/concurrency_bench > benchmarks/results/concurrency-after.jsonl 2> benchmarks/results/fault-after.log
python3 tests/connections.py > benchmarks/results/connections.json
python3 scripts/http_bench.py --wrk /absolute/path/to/wrk --soak 120
python3 scripts/summarize_results.py

results/にはCPU・JSON・SQLite・allocation・concurrencyのJSONL、wrk各試行のtext、HTTP集約JSON、1秒resource sample、障害stderr、環境情報、checksum検証を同梱します。wrkのソース全体は同梱せず、commitとLua scriptを記録しています。Linux専用のtaskset/proc計測部分は他OSでは置き換えが必要です。CI定義は同梱していますが、remote CI上では今回実行していません。

設計・未実装の詳細はdocs/の22ページ、再現用ソースはcompiler/runtime/examples/tests/benchmarks/scripts/にあります。