Pystd：コンパイル時間を大幅に短縮した標準ライブラリ

2026年6月26日金曜日 Pystd標準ライブラリ、コンパイル時間を大幅に短縮した類似機能 私は、C++用のゼロから記述された標準ライブラリ（カスタムデザインであり、ISO仕様の実装ではない）であるPystdに関する講演提案を多数のカンファレンスに提出しました。残念ながら、それらはすべて却下されたので、ブログ投稿の時間です。 議論を呼ぶ意見 C++のコンパイルが遅いというのはほぼ全員が同意するところですが、個人的には耐えられないほど遅いと感じています。他の人はそうは思わないかもしれませんが、それはそれで構いませんが、いくつかの数字を見てみましょう。 Cでhelloworld実行ファイルをコンパイルするのに約0.02秒かかります。#include<print>を使用して同じことを行うC++のexeをコンパイルすると、最適化を無効にすると1秒、有効にすると最大2.3秒かかります。これは約100倍の遅延です。私はRyzen 7 3700Xプロセッサを使用しているので、最新鋭ではありませんが、それほど悪くもありません。私はこの遅延について何人かの人に直接話しましたが、奇妙なことに彼らの答えは「それは問題ではない、2秒は些細なことだ」というものでした。たとえこれを受け入れたとしても（個人的には受け入れませんが）、大きな問題はスケーリングから生じます。なぜなら、遅延係数はほぼ線形だからです。極端ではないケースで、遅延が100倍ではなく20倍だったと仮定しましょう。この場合、0.1秒で終わるはずのプログラムが2秒かかり、したがって、1分でコンパイルできるはずのプログラムが20分程度のコンパイル時間を要することになります。 なぜコンパイルはそんなに遅いのか？ C++は実際にはコンパイルが非常に高速ですが、遅延のほとんどは標準ライブラリの実装方法に起因します。これは、以下のシェルスクリプトを実行することで、かなり簡単に自分でテストできます。 ```shell echo '#include<vector>' | g++ -x c++ -E - -std=c++23 | wc ``` `-E`フラグは、プリプロセッシング後にコンパイラを停止するように指示します。出力は、コンパイラ本体に供給されるソースコードです。代わりにこれを`wc`に渡し、`vector`をインクルードするだけで29,000行のコードに展開されることがわかります。この数字は「人間が書いたコード」と直接比較できるものではありませんが、それでも、要素の拡張可能な配列を得るためだけに約3万行のコードというのは少し多すぎるように思えます。そして、`vector`は実際には軽量なヘッダーの1つです。`memory`は55,000行（特にひどく、99%の時間は`unique_ptr`が欲しいだけです）、`print`は65,000行、`filesystem`は80,000行です。 残念な現実は、標準ライブラリのヘッダーを1つでもインクルードすると、コンパイル時間は低下し、それについてできることは何もないということです。 ただ断るだけ Pystdは、元々、私が低レベルのプリミティブ（ハッシュマップなど）を楽しみのためにゼロから実装するだけのプロジェクトでした。かなりすぐに、私は3つの設計優先事項にたどり着きました。 コンパイル時間 実装の簡潔さ パフォーマンス ビルド時間の最小化が設計上の優先事項であった既存の標準ライブラリを私は知りません。CやGoの標準ライブラリのように高速なものは、ほとんどがそれぞれの言語の簡潔さに起因しているようです。 執筆時点では、シングルコアを使用してPystdとすべてのテストをゼロからビルドするのに4秒かかります。これは45個の個別のプロセス（ほとんどがコンパイル、いくつかのリンク）で構成されています。最適化を有効にすると、ビルド時間は9秒に膨れ上がります。すべての16コアを使用すると、1.9秒に短縮されます。 これまでの成果 テストコードを無視すると、Pystdは合計で6500行のヘッダーと5600行のソースを持っています。これら2つを合わせても、行数は`std::vector`の（プリプロセスされた）実装の約3分の1です。Pystdが提供する機能は以下の通りです。 vector、string、検証u8string、string view、span ハッシュマップ、順序付きマップ（Bツリーを使用） sort（stdlibc++とほぼ同じ速さ）、stable_sort（stdlibc++よりも速い） ISOアルゴリズムヘッダー内のランダムな選択項目 Optional、expected、variant、unique_ptr Pythonモジュールのargparse、pathlib（**演算子を含む）、正規表現（pcreを使用）、tempfileとほぼ同等の機能 これらの機能はすべて「完全」であることに注意してください。通常、これらは最も一般的に使用される機能のサブセットのみを含んでいます。それはかなり小さいかもしれません。 パフォーマンス パフォーマンスに関する以前のブログ記事があります。CapyPDFライブラリを変換したときの数値は以下の通りです。 コンパイル時間が約80%短縮 非ストリップバイナリサイズが約75%削減 ストリップバイナリサイズが約30%削減 ランタイムパフォーマンスが約25%高速化（はい、遅くなったのではなく、速くなりました） 退行は防げる 「コンパイルが速い」という話を聞いたときに人々がよく挙げる2つの典型的な問題は以下の通りです。 「速い」とは一体何なのか？それは人それぞれ、使用するコンピュータによって異なる非常に主観的なものです。 たとえ今速くても、速いままではいられない。常に新しい機能が追加されるため、コードは常に遅くなり、最終的にはデフォルトの標準ライブラリと同じくらい遅くなる運命にある。 これら両方の問題に対する退屈な解決策は同じです。事前に定義された時間予算です。Pystdは、任意の単一の公開ヘッダーをインクルードするソースファイルのコンパイルが最大0.15秒かからなければならないという要件を持っています。この制限は元々0.1秒で、GCCでは完全に機能しましたが、Clangのプロセス起動時間はそれよりも長いです。パフォーマンスを検証するテストスクリプトはこちらです。これはRaspberry Pi上でもパスしなければなりません。 興味深いことに、テスター スクリプトは元々シングルスレッドではありませんでした。Pystd のコンパイルテストサイクルで1秒以上かかる唯一の最も遅い部分だったため、並列化しました。 これは、Pystd のすべての新機能が満たさなければならない要件です。追加したいコードのコンパイルが遅すぎる場合は、パッケージ全体を書き直してコンパイルを高速化するか、アップストリームコンパイラにパッチを提出して実行を高速化する必要があります。 自分で試してみる Pystd のコードは通常の方法で入手できます。初心者の方は、代わりにサンプルプロジェクトの使用を試してみてください。 このコードはLinuxとmacOSで動作します。MSVCはサポートしていません。実装がパックインデックスを使用しており、MSVCがまだ実装していないためです。Jussiが午後9時26分に投稿 メールで送信ブログに投稿！Xに共有Facebookに共有Pinterestに共有 2つのコメント: Wayne 2026年6月27日午前3時47分 ドキュメントは？読みやすいソースコードはありますが、タイプやAPIのリストのようなドキュメントは少なくとも期待します。AIエージェントをソースコードに向けて、cppreferenceのようなスタイルのHugoサイトを作成するように依頼してみてはどうでしょうか。あるいはDoxygenのようなもの（ただしDoxygenの出力には満足したことがありません）。返信削除 返信 Jussi 2026年6月28日午前10時51分 残念ながら、私は実際にドキュメントを書く時間がありませんでした（いつもそうですよね）。部分的には、機能がC++またはPythonの標準ライブラリのコピーだからです。誰かがコードをスキャンしてdeepwikiに載せましたが、それは現在古くなっており、AIであるため品質は少し粗悪です。倫理的な理由から、AI生成のものは実際のレポには追加しません。削除 返信 コメントを追加さらに読み込む... 古い投稿 ホーム 次の投稿を購読: コメント (Atom)