Millimanの金融リスク管理部門でPrincipalを務めるChad Schusterは、C++で書かれたアプリケーションに全面的に依存する代わりに、PythonとNumbaを使って高性能な計算モデルを構築する実践例を紹介した。この取り組みの出発点は、金融サービスでよくある問題である。多数のシナリオにわたってキャッシュフローをシミュレーションするモデルには大きな計算能力が必要だが、チームはPythonの開発速度と保守の容易さを維持したいと考えている。
この問題は、生命保険モデルや年金商品のような退職関連商品において特に重要である。これらの計算は将来の債務を評価し、複数のシナリオを実行するために用いられる。発表によれば、保険会社は歴史的に5,000〜10,000ノードのオンプレミス・グリッドに依存してきたが、クラウドへの移行によって、実行時間と各処理のコストがインフラストラクチャに関する意思決定でより明確になった。
NumbaはPythonに何をもたらすのか？
従来のPython、すなわちCPythonは、実行時にコードを解釈する。一方、C++のようなコンパイル型言語は、実行前にコードをマシン命令へ変換する。NumbaはJust-in-Time（JIT）コンパイルによってこの差を縮めようとする。対象となる関数はプログラムの実行中にLLVMを使ってコンパイルされ、その後、元の関数がコンパイル済みの実装に置き換えられる。
開発者は通常、JITやnjitなどのPythonデコレーターを使ってこの処理を有効にする。Numbaは関数単位で動作し、コードを検査して独自の中間表現へ変換し、その後、変数、引数、戻り値の型を推論してから、表現をLLVM IRへ下げ、必要な最適化を行う。異なる型で関数が呼び出される場合、Numbaは型の組み合わせごとに特化したコンパイル済み実装を生成できる。これはpolymorphic dispatchと呼ばれる。
性能向上は固定された数字ではない
Schusterが紹介した概念実証では、Numbaによってプログラムはインタープリター型Pythonと比べて約75倍高速になった。別のモデルでは結果が異なり、負荷の高い数値計算をCPU上のNumbaへ移すことで約2倍の高速化が得られ、その後GPUへ移行すると、その特定の実行においてさらに750倍の高速化が達成された。発表では、この改善幅により、その実行におけるGPUユニットが約750個のコアに相当し、推定コストを約10分の1に削減したと述べられた。
しかし、これらの結果はすべてのアプリケーションに対する一般的な保証ではない。改善幅は、コンパイル可能なコードの量、入出力処理に対する計算処理の規模、元のPythonの効率、そして生成されたコードをLLVMが最適化できる能力に依存する。また、GPU処理はすべてのアルゴリズムに適しているわけではないため、モデルを再設計する前に実際のボトルネックを測定する必要がある。
エンジニアリングチームにとって実務上何が変わるのか？
この実験では、データの前処理、入力、出力の層はPythonに残し、可能な限り計算負荷の高い部分だけをNumbaへ移すことが推奨されている。このアプローチは書き換えの範囲を抑え、Python環境の大部分を維持しながら、実行時間の大半を占める関数に最適化の労力を集中させる。数値計算関数が限定され、明確である場合、Python環境内にとどまりたい人にとってNumbaの検証は直接的な選択肢になり得るとSchusterは考えている。
一方、広範で複雑なロジックをNumbaへ取り込むと、設計と保守のコストが増大する。この実験では、NumbaのサポートがPythonのすべての機能を網羅していないため、NumPy配列、タプル、単純なデータ構造が採用された。挙げられた制約には、柔軟な型を持つ辞書、例外、コンテキストマネージャー、クロージャー、内包表記で生成されたリストのほか、print、sorted、getattrなど一部の一般的な関数に対する限定的なサポートが含まれる。
採用前に考慮すべき制約
この実験では、オブジェクト指向プログラミングが重要な弱点として残っている。Numbaには、オブジェクトに似た振る舞いを実現するjitclassesやstructrefsなどの実験的機能があるが、バージョン間で変更される可能性があり、GPUもサポートしていない。そのため、これらはチームが採用したアプローチには適さなかった。結果として、アプリケーションは関数型プログラミングと単純なデータ構造に近いスタイルへ移行した。ただし、保守性と顧客へのモデル引き渡しの観点から、オブジェクト指向設計は望まれていた。
型推論エラーやloweringエラーも、特に呼び出し階層が多いプログラムでは追跡が難しい場合がある。エラーは、問題が実際に発生した箇所から遠く離れた関数を指し示すことがある。提案されている実践的な方法の一つは、必要に応じてnjitではなくJITを使うことである。これにより、デバッグを容易にするためNumbaを一時的に無効化してインタープリター型Pythonへ戻し、その後、本番実行で高速化を再び有効にできる。
また、各関数の初回呼び出し時には初期コンパイル時間が発生し、inliningを広範囲に使用するとこの時間が膨らむ可能性がある。この遅延を避けるためにAhead-of-Time（AOT）コンパイルを利用できるが、JITと比べて、実際のデバイスに合わせてコードを適応させる能力が低下する可能性がある。
編集部の見解：この実験の本質的な価値は、750倍という数字そのものではなく、モデルの分割と性能測定を結び付ける手法にある。Numbaは、ボトルネックが計算処理にあり、型と構造が明確な関数へ切り分けられる場合に適している。一方、Pythonシステム全体をコンパイル可能なコードへ変換すると、実行速度の問題が開発とデバッグの複雑さへ置き換わる可能性がある。そのため、金融およびエンジニアリングのチームは、C++の全面的な代替、またはより広範なシステム再設計と見なす前に、実行速度、保守性、コンパイル時間、GPU互換性のバランスを取るべきである。
ニュースの出典
InfoQ - Architecture Articles
原文を開く ↗