2026/01/10 1:05

インライン化 ― 究極の最適化

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

インライン化は、関数本体全体を呼び出し箇所にコピーするコアコンパイラ最適化であり、オプティマイザが定数やデッドコードを局所的に可視化できるようにします。これにより、別々の関数では不可能な変換を実行できます。現代のインライン化は呼び出しオーバーヘッドを回避するだけでなく、定数伝搬、デッドブランチ除去、およびその他の最適化を可能にします。

例: •

std::vector::size()

は完全にインライン化されるため、アセンブリには関数呼び出しがなく、減算とシフト命令のみが含まれます。
• 文字列を大文字に変換するルーチンで、

change_case

が

make_upper

にインライン化されます。上位フラグが常に真であるため、コンパイラは分岐全体を除去し、

(c - 'a') & 0xff < 26 ? c - 32 : c

を単一の条件付き減算に置き換えます。

利点: – 定数と未使用経路が局所的に可視化されることで、各呼び出し箇所で積極的な最適化が可能になります。
– インライン化は明示的な分岐を排除し、命令数を削減できます。

欠点: – 過度のインライン化はコードサイズを膨らませます。コンパイラは利益とコストをヒューリスティックにバランスさせる必要があります。
– まれに、共有ルーチン（インライン化しない）を保持することで、グローバル分岐が非常に予測可能な場合に分岐予測が改善されることがあります。

要件と挙動: – コンパイラは関数定義全体を完全に把握している必要があります。宣言だけではインライン化が阻止されます。
– インライン化の判断はヒューリスティックで、コンパイラ間で異なるため、小さなコード変更が最適化決定に波及することがあります。

総括すると、インライン化は究極の有効化最適化とみなされます。関数を別々に保つ場合には実現できない定数伝搬、デッドブランチ除去、およびその他の変換を解き放ちます。

本文

私が執筆し、LLM が校正した記事です。
詳細は最後に記載しています。

16 日目になりました。ここでは多くの人が「コンパイラ最適化の基本」として捉える インライン展開（inlining）について考えてきました。複雑だからではなく、実際にはコピー＆ペーストという単純な作業よりも、インライン展開が可能にすることの方が興味深いからです。

かつてはインライン展開は関数呼び出し自体のコストを回避するためでしたが、現在ではそれ以外にも多くの最適化を実現できるようになっています。

すでにインライン展開を経験しています（ただし今回は抑えました）。8 日目にはベクターのサイズを取得する際に

.size()

メソッドを呼び出しました。アセンブリコードを見ると、

size()

が

std::vector

のメンバ関数であることはわかりますが、実際には呼び出し命令は見られず、単に減算とシフトだけが残っています。

では、インライン展開が他の最適化を可能にする仕組みとは？ ARMv7‑M を使って文字列を大文字に変換する例を考えてみましょう。文字を上から下へまたはその逆に変えるユーティリティ関数

change_case

があるとします。この関数をコードで使用すると、コンパイラは次のように展開し、さらに

upper

が常に真であることを利用して全体を簡略化できます。

// コンパイラが change_case を make_upper にインライン展開し、
// upper が常に true であることを見てコード全体を簡略化する例:
.LBB0_1:
    ldrb r2, [r0]         ; 次の文字 `c` を読み込む; c = *string;
    sub  r3, r2, #97      ; tmp = c - 'a'
    uxtb r3, r3           ; tmp = tmp & 0xff
    cmp  r3, #26          ; tmp と 26 を比較
    sublo r2, r2, #32     ; tmp が 26 未満なら c = c - 32
                           ; c = ((c - 'a') & 0xff) < 26 ? c - 32 : c;
    strb r2, [r0], #1     ; `c` を書き戻す; *string++ = c
    subs r1, r1, #1       ; カウンタを減らす
    bne   .LBB0_1         ; まだ残りがあるならループ

!upper

のケースは完全に消え、コンパイラはインライン化されたコードのコピーをさらに修正して真であることを利用できるようになりました。ブランチを使わずに

(c - 'a') & 0xff < 26

を判定し、条件付きで 32 を減算することで

を

に変換します。

インライン展開はコンパイラにローカルな変更を行う余地を与えます。呼び出し元が存在しない場所で実装を特別扱いでき、定数として知られる値（上記の

upper

のような）を伝搬させたり、使用されていないコードパスを削除したりできます。

ただしインライン展開には欠点もあります。過剰に使うとプログラムのサイズが大幅に増える可能性があります。コンパイラは関数をインライン化するかどうか、またその関数が呼び出す他の関数まで連鎖的に評価し、コードサイズの増加と予想される利益とのバランスで最適化を決定します。結局のところこれは推測です。

まれに共通ルーチンへの呼び出しコストを受け入れることでメリットが生じるケースもあります。例えば、グローバルに予測可能な分岐があるルーチンでは、共有された分岐点の方がブランチプロデクタにとって有利になることがあります。しかし多くの場合は逆で、インライン化されたコード内の分岐ヒストリがよりローカルになり、予測精度を向上させることがあります。これは複雑です。

インライン展開を行う際には呼び出す関数の定義（本体）が可視である必要があります。コンパイラが宣言だけ（例：

char change_case(char c, bool upper);

）しか見ていない場合、インライン化はできません。本格的な C++ ではヘッダに多くのコードが入っているためこれは問題になりにくいですが、ビルド時間や依存関係を最小限に抑えたい場合には注意が必要です。

さらにフラストレーションが生じるのは、インライン展開が非常にヒューリスティックに左右されるためです。コンパイラごとに「どの関数をインライン化すべきか」の推測が異なり、ある場所に1 行追加するだけで全体の最適化方針に波及効果を与えることがあります。

結論として インライン展開は究極的な可能性を広げる最適化 です。単純に関数本体を呼び出し箇所へコピーするだけで数サイクル節約になる場合もありますが、コンパイラに新しいコードコピーを与えることで定数伝搬、デッドブランチの除去、そして共有関数本体では不可能な変換を適用できるようになります。コピー＆ペーストが常に悪いとは限らないのです。

この投稿には添付動画もあります。

この記事は Advent of Compiler Optimisations 2025 の第17日目で、コンパイラが私たちのコードをどのように変換するかを探る25 日間シリーズの一部です。

← 「呼び出し元」 | 部分的インライン化 →

この記事は人間（Matt Godbolt）によって執筆され、LLM と人間によって校正・レビューが行われました。

Patreon、GitHub、または Compiler Explorer Shop で CE をサポートしてください。

2025 年 12 月 17 日 06:00:00 CST に投稿しました。

同じ日のほかのニュース

一覧に戻る →

2026/01/14 5:45

**ゲームズ・ワークショップ、スタッフのAI使用を全面禁止　経営陣はテクノロジーに興味津々でない** - 同社は従業員が業務上人工知能ツールを利用することを一律で禁じる方針を採用しました。 - 経営層は知的財産の安全性や創造的コントロールへの影響を懸念していると述べています。 - 業界内では注目が集まっても、上級経営者はAIがデザイン・生産フローに与えるメリットに対し慎重な姿勢を保ち続けています。

## Japanese Translation: **改善された概要** Games Workshop は、コンテンツ制作と設計プロセスにおける生成型 AI ツールの使用を正式に禁止しました。この方針では、厳格な監視下で数名の上級マネージャーのみが AI を実験できるようになっていますが、その可能性についてはまだ誰も興奮していません。外部コンペティションへの参加を含む不正使用は禁止されており、企業はデータ準拠・セキュリティ・ガバナンスを監視し、AI/ML エンジンがデバイスに自動インストールされるのを防止する必要があります。 GW の禁止措置は知的財産権を保護し、人間クリエイターを尊重するとともに、上級スタッフによる限定的な調査を許可しています。この決定は、より広い文脈の中で行われました。GW は *Warhammer 40,000* や *Age of Sigmar* などのフラッグシップテーブルトップタイトルを所有し、高品質のコデックス本・ミニチュア・アニメーションを販売しており、最近は新規採用で Warhammer Studio を拡大しました。Displate の作品に関する最近の紛争―Displate がそのアートワークが AI によって生成されたと否定し、「赤旗」を人為的なミスに帰せたケース―は、ファンが生成型 AI アートに対して反発していることを示しています。特に Warhammer の美学に大きな影響力を持つアーティスト John Blanche の存在がその背景にあります。今後も GW はデータ準拠とセキュリティの監視を継続します。上級マネージャーは AI の可能性を探るかもしれませんが、内部方針の変更や外部圧力が変わらない限り、広範な採用は見込めません。この禁止措置により GW は Genvid、EA、Square Enix など AI を積極的に導入している競合他社に比べて遅れを取ることになり、ゲーム開発の競争ダイナミクスが変わる可能性があります。これは生成型 AI の統合に対する業界全体の慎重な姿勢を反映しています。

2026/01/14 2:10

**チューリップ・クリエイティブ・コンピュータ** - 芸術と技術のユニークな融合 - 革新的なビジュアル体験を設計 - 鮮やかなカラーパレットと最先端ハードウェアを組み合わせる

## 日本語訳： **Tulip CC** は低電力で手頃な価格のセルフコンテインドポータブルコンピュータで、オープンソースの音楽ワークステーションとしても機能します。ESP32‑S3マイクロコントローラを中心に構築され、MicroPython を実行し、AMY ステレオ 120 ボイスシンセサイザーエンジン（加法／減法/F‑M 合成、サンプラー、Karplus–Strong、アナログフィルタ、シーケンサー、ドラムマシン、パッチエディタ）とキャパシティブ・マルチタッチ対応のタッチスクリーンディスプレイを備えています。デバイスは 8.5 MB の RAM（MicroPython 用 2 MB、OS 用 1.5 MB、残りがグラフィックスフレームバッファ）と 32 MB のフラッシュ（うち 24 MB が使用可能）、Wi‑Fi、USB キーボード/マウス/MIDI、I²C/Grove/Mabee コネクタをセンサーや周辺機器用に搭載し、組み込みの pico/nano スタイルエディタ（構文ハイライトと REPL）も備えています。グラフィックスは LVGL によって処理されます：テキストフレームバッファ 128 × 50（ANSI 256 色）、スキャンラインあたり最大 32 スプライト（32 KB ビットマップメモリ）、1024 × 600 の背景フレームバッファでスクロール、PNG ローディング、デフォルト 30 FPS、解像度調整可能、256 色。電力消費は 5 V で 575 mA（中程度の輝度）で、LiPo、18650、または USB バッテリーパックに対応しています。追加ソフトウェア機能として、ネイティブチャット/ファイル共有 BBS「TULIP ~ WORLD」、MIDI 入出力コールバック、およびクリエーションの共有用 Web バージョンがあります。 Tulip CC は市販ユニット、DIY ハードウェアキット、フル機能の Web アプリ、またはネイティブデスクトップアプリ（Mac/Linux/WSL）として入手可能です。開発リソース—完全な API ドキュメント、チュートリアル、Discord コミュニティ、およびオープンソース GitHub リポジトリ—が提供されており、埋め込みデバイスとデスクトップ環境の両方で動作するために貢献が必要です。将来のファームウェア更新では、合成モジュールの拡張、LVGL を介したグラフィックス解像度の向上、および電力効率の改善がコミュニティの入力を受けて行われる可能性があります。

2026/01/14 1:22

「二つの頭（＝複数の視点）が一つより優れているのでしょうか？」

## Japanese Translation: ## 要約コイントスの結果を時折だけ報告する人々がいる場合、報告者数が奇数であると予測精度が向上し、さらに1人追加して偶数にすると追加効果は得られないという点が主旨です。シミュレーションと解析的な検証から次のように示されています：正直な友人（80 % 正解率）を1人だけ持つ場合、2人目を加えても精度は80 %のままであり、合意しても不一致が相殺されるため利益がありません。3人目が参加すると精度は90 %に上昇し、4人目が加わると再び90 %に戻ります。このパターンは奇数回報者ごとに繰り返されます。この発見はコンドルセートの陪審理論を反映しており、偶数規模のグループでは多数決が引き分けになる可能性があるため、新たな情報を提供しないことを説明しています。著者は、創造的執筆プロジェクトを開催するプログラミングリトリート「Recurse Center」でベッティングシミュレーションを実行している際にこの現象に気付きました。今後の研究では、この傾向がより複雑な投票設定や大規模グループでも維持されるかどうかを検証することが期待されます。グループサイズと偶奇性が意思決定品質に与える影響を理解することで、クラウドソーシングサイト、陪審制度、または人間の判断を集約するあらゆるプラットフォームの設計者が、不必要な偶数参加者を追加しないよう助けることができます。