なぜ今、Fortranで「継承」を使うのか？― 数値計算の現場における型拡張の極意
多くの計算科学者が、Fortranのオブジェクト指向機能（OOP）を「C++の真似事」として敬遠し、結果としてコードが `if-else` 文の迷宮と化している現状を、私は何度も目撃してきました。
しかし、大規模な物理シミュレーションにおいて、`EXTENDS` 属性を用いた継承は、単なるプログラミングの趣味ではありません。「コードの疎結合化」と「コンパイラの最適化パスの最大化」を両立させるための戦略的兵器です。今回は、数値計算の現場で生き残るための、堅牢かつ高速な継承実装の極意を伝授します。
—
1. 継承は「カプセル化」ではなく「インターフェースの統一」のためにある
数値計算のコードにおいて、継承を複雑なクラス階層を作るために使うのは禁じ手です。メモリ上のデータレイアウトが複雑になり、プロセッサのキャッシュミスを誘発するからです。
我々が継承を使う最大の目的は、「計算アルゴリズムは不変のまま、演算対象の物理モデルだけを差し替える」ことにあります。
実装のアンチパターンと正解
`type, extends(base) :: child` を用いる際、メンバ変数にポインタを多用してはいけません。ポインタはコンパイラがエイリアス解析（Aliasing Analysis）を諦める原因となり、SIMDベクトル化を阻害します。データは可能な限り「派生型のメンバ」として実体（Allocatable Array）で保持してください。
—
2. 実践コード：高速・堅牢な型継承パターン
以下のコードは、ソルバーの計算ルーチンを抽象化し、具体的な物理モデル（線形・非線形）をオーバーライドで切り替える実装例です。
module physical_models
implicit none
private
public :: base_model, linear_model, compute_flux
! 基底型：抽象インターフェースのみを定義
type, abstract :: base_model
contains
! パスを最適化するため、オーバーライドを前提とした抽象メソッド
procedure(calc_interface), deferred :: get_flux
end type
abstract interface
function calc_interface(self, state) result(flux)
import :: base_model
class(base_model), intent(in) :: self
real(8), intent(in) :: state
real(8) :: flux
end function
end interface
! 派生型：線形モデル
type, extends(base_model) :: linear_model
real(8) :: coefficient
contains
procedure :: get_flux => get_linear_flux
end type
contains
! オーバーライドされるメソッド
function get_linear_flux(self, state) result(flux)
class(linear_model), intent(in) :: self
real(8), intent(in) :: state
! ここは単一のスカラ演算だが、ループ内で呼ばれる場合は
! 呼び出し側のループでベクトル化が効くように設計する
flux = self%coefficient state
end function
! 計算ルーチン：型に依存せずポインタ経由で呼び出す（動的ディスパッチ）
subroutine compute_flux(model, states, fluxes)
class(base_model), intent(in) :: model
real(8), intent(in) :: states(:)
real(8), intent(out) :: fluxes(:)
integer :: i
! コンパイラがループを展開しやすいように、
! 内部では派生型の中身を触らず、メソッドを呼ぶだけに留める
do i = 1, size(states)
fluxes(i) = model%get_flux(states(i))
end do
end subroutine
end module
—
3. コンパイラ最適化を殺さないための「鉄の掟」
この構造を導入しても、コンパイラが最適化を放棄しては意味がありません。以下の設定と工夫が現場では必須となります。
① `final` と `non_overridable` の活用
不要なオーバーライドの連鎖は、コンパイラにとって最適化の阻害要因です。継承させる必要がないメソッドには `non_overridable` 属性を付与し、静的ディスパッチを強制しましょう。
② `-fwhole-program` とリンク時最適化 (LTO)
Fortranの継承（動的ディスパッチ）は、実行時にVテーブル（仮想関数テーブル）を参照します。これはCPUにとって分岐予測のコストになります。
コンパイル時に `-flto` (gfortran) または `-ipo` (ifort) を指定することで、リンク時にインライン展開が可能になり、パフォーマンスの低下を最小限に抑えられます。
③ メモリの連続性（Col-Major）への配慮
継承関係にある型を配列として扱う場合、`type(linear_model), allocatable :: models(:)` のように実体の配列を確保してください。`class(base_model), allocatable :: models(:)` とすると、配列要素がポインタの集合となり、メモリが断片化（非連続アクセス）してキャッシュ効率が壊滅します。
—
結論：モダンFortranは「書き心地」ではなく「計算効率」で選べ
継承やオーバーライドは、コードを綺麗にするための道具ではありません。「計算の核心部分を、将来の変更から隔離する」ための防波堤です。
実務においては、まず「データ構造をいかにCPUのキャッシュラインに収めるか」を設計し、その後に `EXTENDS` で拡張性を付与する順序を守ってください。Fortranの型継承は、正しく使えば、レガシーな `common` ブロックや冗長な `if-else` の迷宮よりも遥かに高速で堅牢な基盤を提供してくれます。
次は、この継承構造を利用した「ジェネリックな並列計算テンプレート」について深掘りしましょう。シミュレーションの解像度を一段階上げるために、まずは既存のコードの `type` 定義を見直すことから始めてみてください。
コメント