自動微分の誤った神話その1

使っているライブラリ全ての書き直しをしなければならない

原文:AD Myths Debunked: I’ll have to re-write my Libraries- Published 2022/03/06 By Johannes Lotz

この記事は 自動微分の誤った神話 シリーズの一部です。

この記事を読まれている読者の方々は自動微分とその利点には興味がありますが、自動微分の適用には「ライブラリを書き直す必要がある」と耳にされた事があるかもしれません。ライブラリの書き直しには多大な労力がかかるかので、自動微分の適をあきらめてしまった方々もいるのではないでしょうか。

私たちNAGは、このようなシナリオに何度も遭遇してきました。お客様になぜ適用コストがそんなにかかるのかと尋ねると、たいてい「大規模なレガシーコードがあるから」という答えが返ってきて、そのレガシーコードがいかに粗悪なものであるかを説明されます。

そこで、もう少し具体的にレガシーコードのどの部分が自動微分の実装を難しくしているのかと質問しますと、これに対しての答えは大抵返ってきません。

C++のコードに自動微分を組み込む事は大変な事なのでしょうか。何がそれを難しいものにしているのでしょうか。 また、なぜそれが大がかりな仕事だと考えるのでしょうか?

NAGは何十社ものお客様に対して、私たちの自動微分ソリューションであるdco/c++を非常に大規模で複雑なライブラリに適用するお手伝いをしてきましたが、コードの書き直しに至ったことはほとんどありません。

自動微分適用の容易さは、使用する自動微分ツールの洗練度に依存します。設計が不十分なツールは、この作業を実に不愉快なものにしてしまいます。dco/c++のようなエンタープライズクラスの製品は、他のツールを悩ませる多くの落とし穴を回避します(一例として、dco/c++はあなたのコードが特定の形状やフォームを持っていることを仮定しません)。

C++ライブラリに関して一貫して実現可能であることが証明されている唯一の自動微分のアプローチは、演算子オーバーローディングのアプローチです。高いレベルでは、自動微分ツールは自身を「数値データ型」として提示しますが、利用者はdoubleやfloatで計算する代わりにこのデータ型で計算を行い、その他の部分を全てツール側に任せる事が可能です。

dco/c++のような非常に効率的な自動微分ツールは、コンパイラにできるだけ多くの力仕事をさせるために、式テンプレートを多用します。式テンプレートを利用している方は、そのようなライブラリを混在させることが大変であることを知っています。ですから、もしあなたのライブラリがBoostやEigen(あるいは自家製の式テンプレートライブラリ)を使っているならば、注意して進まなければなりません。幸いなことに、dco/c++はBoostとEigenの両方をサポートしており、他の式テンプレートエンジンに対しても堅牢です。

ここで、いくつかの数字を載せるために、実際の例を通して話をしましょう。私たちは最近(2021年)、QuantLibのmasterブランチにdco/c++を適用しました。QuantLibは、期待される標準的なC++の利用形態をすべて備えた大規模なコードです:テンプレート(演算型にテンプレート化されていませんが)、型定義、ポリモーフィズムと仮想継承、デザインパターン、ロギング(ストリーム経由)、そして、boostとC++11クラスとアルゴリズムのかなりの部分を使用しています。

このプロジェクトのコード統計情報は次のようになっています。

言語 ファイル数 空行 コメント行 コード行数
C++ 915 23793 21250 220934
C/C++ Header 1374 27319 43601 83622

NAGの自動微分チームのエンジニアの一人が、1日足らずで自動微分をQuantLib全体に適用しました。その際、合計200のファイルが変更され、全体で625の挿入と462の削除(これは文字です)がありましたが、そのうちの90%はツールによって安全に行うことができました(NAGはそのようなツールのプロトタイプを所有しています)。dco/c++の単純な統合もまた目を見張る結果を達成しました。

自動微分ツールの性能はアジョイント係数(アジョイントランタイム/オリジナルランタイムの比)によって測定されます。 そして有限差分に対するスピードアップは,おおよそ sensitivity数/アジョイント係数 となります.

  • マルチカーブのスワップ価格の例(カーブの構築を含む)では、アジョイント係数は1.3でした。
  • バスケットオプションの価格設定(モンテカルロ法)の場合、アジョイント係数は1.1でした。
  • HestonSLVの価格計算の例(PDE)では、アジョイント係数は凡そ15でした。

これらの結果は改善できるでしょうか?もちろんです。リバースモード(アジョイント)自動微分のメモリ効率については、次回の記事で取り上げます。

NAGの自動微分ツールセットは過去12年にわたり開発され、さらに10年にわたるC++による自動微分研究開発の経験を基に構築されています。私たちは、細部が重要であることを知っています。レガシーコードは私たちのビジネスであり、私たちが扱うことができないコードに出会ったことは一度もありません。

神話は、真実のように聞こえるかもしれませんが、私たちは、神話について詳しく話し、私たちの経験を共有することによって、企業がこれらの問題を解決する手助けをしたいと願っています。

結果は重要ですが、神話は重要ではありません。

関連情報
MENU
Privacy Policy  /  Trademarks