再帰の深淵：RECURSIVE属性とスタックを枯渇させないための実践的設計論
数値シミュレーションの世界において、木構造の探索や分割統治法（FFTの再帰的実装など）を扱う際、`RECURSIVE`キーワードは強力な武器となる。しかし、CやPythonのような「とりあえず再帰」というノリでFortranで実装すると、計算機のメモリ空間で大惨事を引き起こすことになる。
今日は、大規模シミュレーションの現場で「計算が終わる前にセグメンテーションフォールトで死ぬ」という事態を避けるための、モダンFortranにおける再帰の作法を伝授する。
1. なぜFortranでRECURSIVEを慎重に扱うべきか
Fortranの初期設計思想において、サブルーチンは基本的に静的（スタティック）なメモリ配置を前提としていた。`RECURSIVE`を付与するということは、コンパイラに対して「この手続きは再入可能（Reentrant）であるため、スタック領域を動的に確保せよ」と明示的に命令することに他ならない。
ここで問題になるのが、OSが提供するデフォルトのスタックサイズだ。計算科学の現場で扱われる膨大なデータ構造を再帰で回せば、あっという間にスタックオーバーフロー（Stack Overflow）が発生する。
2. 安全な再帰実装のアーキテクチャ
まずは、再帰関数を記述する際のテンプレートを見てほしい。単に動けばいいというコードではなく、最適化の余地を残した書き方だ。
MODULE solver_utils
IMPLICIT NONE
PRIVATE
PUBLIC :: factorial_safe
CONTAINS
! RECURSIVEキーワードを明示。PUREを付与することで、
! 副作用がないことをコンパイラに伝え、最適化の余地を広げる。
RECURSIVE PURE FUNCTION factorial_safe(n) RESULT(res)
INTEGER, INTENT(IN) :: n
INTEGER(8) :: res ! 桁溢れを防ぐための8バイト整数
! 再帰の終了条件を冒頭に配置。
! 条件分岐の予測（ブランチ予測）を効かせるために重要。
IF (n <= 1) THEN
res = 1
ELSE
res = n factorial_safe(n - 1)
END IF
END FUNCTION factorial_safe
END MODULE solver_utils
3. コンパイラによる最適化と「スタック」の罠
現場で最も多いトラブルが、「コードは正しいのに大規模データで落ちる」現象だ。これはコンパイラの最適化フラグとスタックサイズの不整合が原因である。
コンパイラ設定の最適解（GCC/gfortranの場合）
再帰を利用する際、以下のコンパイルフラグを意識してほしい。
- `-fstack-arrays`: ローカルな自動配列をスタックではなくヒープに置く設定だが、再帰が深い場合は逆にスタック消費を抑えるために慎重に使う必要がある。
- `-fmax-stack-var-size=n`: スタックに置く変数の上限を制限する。これを設定しておくと、意図しない巨大な配列のスタック確保をコンパイル時に検知できる。
また、実行環境側で必ず以下の設定を行うこと（Linux環境）。
スタックサイズを無制限（または極大）に設定
ulimit -s unlimited
コンパイル時は最適化を効かせる
gfortran -O3 -march=native -fno-protect-parens -o simulation_exec main.f90
4. 現場のシニアが教える「再帰を避ける」という選択
ここまで`RECURSIVE`の話をしてきたが、私の経験上、本当に計算速度を追求するならば再帰は避けるのが鉄則である。
なぜか？ 再帰呼び出しには、関数スタックの積上げと戻りという「オーバーヘッド」が存在する。行列演算や流体解析のホットパス（最も頻繁に実行されるループ）において、このオーバーヘッドはベクトル化やループ展開（Loop Unrolling）を阻害する最大の要因となる。
もし、再帰呼び出しの深さが予め予測可能であるなら、明示的なスタック（配列）を自前で実装したループ処理に書き換えることを強く推奨する。
! 非再帰的なスタック実装の例（擬似コード）
SUBROUTINE iterative_solver(data)
INTEGER, ALLOCATABLE :: stack(:)
INTEGER :: sp
ALLOCATE(stack(MAX_DEPTH))
sp = 1
stack(sp) = initial_value
DO WHILE (sp > 0)
! ループ内に処理を落とし込むことで、
! コンパイラのSIMD最適化を最大限に引き出す
END DO
END SUBROUTINE
まとめ：堅牢なコードのために
1. RECURSIVEの明示: 再帰が必要な場合は必ず付与し、同時に`PURE`属性で副作用を排除して最適化の余地を確保せよ。
2. スタック制限の意識: デバッグ時は`-fcheck=stack`等のオプションを使い、実運用時は`ulimit`でスタックサイズを管理せよ。
3. 再帰の脱却: ホットパスにおける再帰は悪。性能を極限まで引き出したいなら、再帰アルゴリズムをスタックデータ構造を用いた「反復（Iteration）」に書き換えるのが、真にプロフェッショナルなFortranエンジニアの仕事だ。
計算機というハードウェアの物理的制約（メモリレイアウトとパイプライン）を理解し、その上で言語仕様をねじ伏せる。それこそが、モダンFortranを使いこなすということだ。君たちのコードが、スパコンの上で淀みなく流れることを期待している。
コメント