@inlinable属性は、Swiftコンパイラに関数の実装をモジュールインターフェースファイルにシリアライズするよう指示し、クライアントモジュールにコンパイル時に直接本体をコピーさせ、ジェネリック特化や定数折りたたみのような積極的な最適化を可能にします。ただし、インライン化されたコードは、クライアントのコンパイルユニット内のすべてのシンボル参照を解決する必要があるため、@inlinable関数によってアクセスされるすべてのinternal型、関数、またはプロパティは、@usableFromInlineでマークする必要があります。これにより、それらはパブリックAPIとして公開することなくコンパイラに対して露出します。
// レジリエントフレームワークモジュール内 @usableFromInline internal struct InternalBuffer { @usableFromInline var storage: [Int] } @inlinable public func fastSum(_ buffer: InternalBuffer) -> Int { // @usableFromInlineによって内部ストレージにアクセス可能 return buffer.storage.reduce(0, +) }
この組み合わせにより、ライブラリの著者はクライアントバイナリ内でジェネリックコードが単一化されるゼロコストの抽象化を提供しますが、関数本体が安定したバイナリインターフェースの一部になるため、いくつかのABIの柔軟性は犠牲にされます。
高スループットの機械学習フレームワークを開発しているチームは、クライアントアプリケーションに対してジェネリック行列乗算関数matmul<T: Numeric>を公開する必要がありましたが、プロファイリングの結果、クロスモジュール関数呼び出しのオーバーヘッドと特化が不足していることが、手書きのループと比較して性能を40％低下させていることが明らかになりました。ライブラリはバイナリSwiftパッケージとして配布されていたため、ソースレベルの最適化はクライアントには利用できませんでした。
1つのアプローチは、すべてのヘルパー型と実装関数をpublicにし、内部バッファ管理およびストライド計算のすべての詳細を公開することでした。この方法ではインライン化が可能でしたが、チームは特定の内部型を安定したAPIとして永遠に維持する必要があり、将来のリファクタリングを妨げ、消費者が直接触れるべきでない実装の詳細でパブリックインターフェースが cluttered することを防ぐことができなかったでしょう。
別の選択肢として、@inline(__always)を使用することが考慮されました。これは同じモジュール内でコードを積極的にインライン化しますが、関数本体を他のモジュールにエクスポートしません。この方法ではAPIをクリーンに保つことができますが、クライアントコンパイラがFloat16やDoubleなどの特定の数値型に対してジェネリックTを特化することを許可せず、ランタイムディスパッチのオーバーヘッドをそのまま残し、パフォーマンス目標を達成できませんでした。
エンジニアは最終的にエントリーポイントに**@inlinableをマークし、内部バッファ構造体と算術ヘルパーに@usableFromInline**を注釈しました。この戦略は、クライアント呼び出しサイトでの完全な単一化とインライン化を可能にするのに必要な実装の詳細をコンパイラにわずかに露出させる一方で、シンボルを公共の文書から外しました。その結果、クライアントアプリケーションは手動で展開したCコードと同等のパフォーマンスを達成しましたが、フレームワークのバイナリサイズはモジュール間のコード重複のためわずかに増加し、チームは関数のパッチがクライアントに再コンパイルを必要とすることを受け入れました。
クロスモジュール境界に関する@inlinableと@inline(__always)の根本的な違いは何ですか？
@inlinableはモジュールインターフェースの契約であり、関数本体を**.swiftinterfaceファイルに書き込むことにより、コンパイラが依存モジュールのコンパイル中に実装を直接発行できるようにします。これはクロスモジュールジェネリック特化にとって不可欠です。一方、@inline(__always)**は、単にローカルコンパイルユニットへの最適化のヒントです。これはモジュール内でコールスタックをフラット化するようコンパイラに指示しますが、外部コンパイラに対して本体を使用可能にしないため、クライアントモジュールは依然としてレジリエントインダイレクションを介して関数を呼び出し、ジェネリックディスパッチのオーバーヘッドを取り除くことはできません。
なぜSwiftは@inlinable関数によって参照される内部シンボルに@usableFromInlineを要求するのですか？単に可視性を推測することはできませんか？
関数がクライアントモジュールにインライン化されると、コンパイラはそのコードの具体的な機械命令を呼び出しサイトで生成する必要があります。このためには、すべての参照エンティティについて完全な型メタデータとシンボルアドレスが必要です。internalシンボルはカプセル化を強化するために意図的にモジュールインターフェースから除外されます。@usableFromInlineは、クライアントソースコードにアクセス可能にすることなく、インターフェースファイルでシンボルの定義を公開する特別なコンパイラ専用の可視性レベルとして機能し、コード生成要件を満たしながらソースレベルのプライバシーを維持し、偶発的なAPIの漏洩を防ぎます。
@inlinableを採用すると、SwiftライブラリのABIの安定性とバイナリサイズ特性にどのように影響しますか？
関数を**@inlinableでマークすることは、その実装をライブラリのABIに埋め込むことを意味します。したがって、関数本体に変更（バグ修正やアルゴリズムの改善など）がある場合、それはクライアントモジュールが更新を反映するために再コンパイルされる必要がある、壊れるバイナリ変更となります。レジリエント関数では、実装を独立して置き換えることができます。さらに、コンパイラがすべてのクライアントバイナリ内のすべての呼び出しサイトで関数本体を複製し、単一の共有ライブラリアドレスを参照するのではなく、@inlinable**は最終アプリケーションの総バイナリサイズを大幅に増加させます。これにより、大規模であまり呼び出されないユーティリティ関数には不適切となります。