本文書は、2008年7月11日に東京で行われたニューメリカルテクノロジーズ株式会社主催「金融ALM/リスク管理モデルの運営とコンピューティング・グリッド技術の応用」セミナーにおける配付資料の抜粋です。
※HPC: High Performance Commputing、高速計算技術を意味する学術用語。スーパーコンピューティング。
グリッド・コンピューティングよりも遙かに軽量かつ安価な高速計算技術が新しく登場した
Who Wins?
あなたがリラティブバリュー・アービトラージなり統計アービトラージのトレーダーであったとしよう。
左は個別株ペアトレードの組み合わせを発見し取引を自動執行するトレーダーだ。彼の後ろにいるのは彼専属の忠実なるシステム要員である。グリッド・コンピューティング技術を使って通常の100倍の速度でマーケットの歪みを計算する。
右は4×4スクリーンを前にした典型的なアーブだ。スクリーンのひとつひとつが左のグリッドコンピューティング環境と同じ100倍の能力を持っている。彼は金利、エクィティ、コモディティ、思いつくままにリアルタイムでクロスマーケットの裁定機会を計算させトレードを執行する。
どちらが市場に勝てるか? 右のトレーダーに決まっている!


あなた専用のHPC環境
本文書で解説するのはデスクトップPCの計算能力を100倍以上に増強するアクセラレータ技術である。
パソコン 1台がグリッド環境に匹敵する。
例題:BGMモデルを使ってヨーロピアンスワップション価格を求めよ
実際の業務に使える事例で試してみよう
いくら速くなったと言っても実際の業務に使える事例でなければ説得力がない。そこで金利系で計算が大変なデリバティブ商品の例として BGM[1997]※に基づくEuropean swaption の価格計算を選び、素直にモンテカルロ法を使って解いてみた。
自分が金利系トレーダーではなく為替系トレーダーだと言うのであれば、例えばバミューダン・オプションの価格モデルは最悪モンテカルロを必要とするという意味で同じクラスの計算規模に属するから、以下の事例を適宜読み替えて頂きたい
なお、本事例はあくまで性能評価が目的であるから、敢えて皆様の手で追試できるように実装方法はJustin London,“Moodeling Derivatives in C++,”John Wiley & Sons, p.652 に出来るだけ忠実に従った。
- LFMを使ってLIBORのセットを求める。
- オイラー法を使い上式を差分方程式に変換。
- ここまで準備してN 個のtimestep 毎に求めたLIBORからpayoffを計算する。
- 以上の過程をM回繰り返して(モンテカルロ法)期待値をとる。

ただし、この本には山のようにバグや理論的におかしな箇所があるので、明白な箇所は修正した。またあらかじめ本の原プログラムにあるループ内push_back 操作のような非効率な実装は取り除き、C++言語レベルのオプティマイズを済ませてから速度比較を行った。そうしないと見掛け上「1000 倍も高速化」してしまい、本事例研究への信頼が損なわれるからである。
後述する必須のハードウェアが本原稿執筆の直前まで出荷されなかったから、本例題の解法に使った作業期間は僅か1 週間であった。率直に言って多少のバグは残っているかもしれない。しかしながら結論は不変のはずである。
便利なExcelアドインアプリケーションに仕上げる
まさかトレーディングの最中に「プログラム起動手続き」なんかしたくはないでしょう?
世の中は使いにくいシステムで満ち溢れている。あなたはプライスを作るたびに誰かにグリッド・コンピューティング・システムでも起動してもらうつもりか?そんな手続きにはNo! と言おう。デスクのBloomberg の横にExcel を立ち上げれば十分。違いますか?
本事例ではExcel アドイン関数としてEuropean Swaption モデルを実装してみた。キャリブレート後のパラメータを入力としてSwaption 価格を計算する。あなたに必要な操作はExcel のセルにいつも通り関数を入力するだけである。事例ではNtMonteCarloLFM 関数は1,000,000 回のモンテカルロシミュレーションを1 秒もかからずに実行する。これは十分にオプティマイズされたC++プログラムを175 倍に加速する性能だ。
European Swaption Calculator for Excel (Engineering Sample)
175 倍速の計算能力があれば簡略法に頼る必要が無くなる
正確なプライスを求められる
十分に高速なモンテカルロ法を使えるならば、複雑で怪しい仮説に頼った解析的解法に頼る必要はない。高速解法の開発に回してきたクオンツの能力を他の問題に振り向けられる。
さらに収束性改善策(本事例では対称変量法)を併用する。この収束性能を見よ!
センシティビティ分析も差分解法も思いのまま
多様な分析が可能になる
セルに入力したNtMonteCarloLFM 関数をシート上の他のセルにコピーしても構わない。通常のExcel 関数とまったく同じ使い勝手のHPC である。
高速化の秘密はアクセラレータ
NVIDIA GTX280
本事例では2008 年6 月に発売されたNVIDIA 社のGTX280 を2 枚、PC の拡張スロットに入れて使用した。
このアクセラレータに使われているのがGPGPU(General Purpose Graphics Processing Unit) と呼ばれる技術。同様のGPGPU にはATI 社のRV770 がある。アクセラレータにはGPGPU 以外の技術もあり、Cell/B.E.、ClearSpeed が出荷中。Intel 社も2008~2009 年に開発コードネームLarrabee を出荷すると発表している。最近のHPC 関係ではホットイシューである。
なお、本事例で弊社がNVIDIA 社のGPGPU を使ってテストしたのは価格も安く入手しやすかったためである。他に理由はない。弊社では他の選択肢を積極的に試していきたいと考えている。

ベンチマークテストの結果
Intel Core2 Quad Q9550/2.83GHz 搭載のPC1 台を使い、GPGPU なしでCPU の1 コアを使って計算した時間を基準として比較した。
| モンテカルロの 試行回数と精度 |
GPGPUなし (すべて倍精度) |
GPGPUx1 | GPGPUx2 |
|---|---|---|---|
| 1,000,000回 倍精度 | 90.618秒 | 4.043秒 (22倍の高速化) |
2.094秒 (43倍の高速化) |
| 1,000,000回 単精度 | 90.618秒 | 1.017秒 (89倍の高速化) |
0.596秒 (152倍の高速化) |
| 10,000,000回 単精度 | 904.376 | 10.223秒 (88倍の高速化) |
5.165秒 (175倍の高速化) |
- 現在最速のIntel Xeon X5460/3.16GHz の1 コア性能を別途測定した結果と比較すると、10,000,000 回モンテカルロが760.044 秒だったので147 倍の高速化となる。SMP との比較ではないから、4 コア、8 コア、あるいは16 コアと比較したければ4、8、16 で割って適当に倍率を推定してほしい。
- GPGPU なしの場合の計算精度はすべて倍精度とした。仮に単精度にした場合は、Intel 系CPU の場合はかえって倍精度よりも遅くなるので実環境を想定した比較対象としては適さないと判断したものである。
- PC の計時機能は時間分解能が低く、またOS のスレッドスケジューリングも影響するので、1 秒未満の時間計測には誤差が含まれている。またスタートアップにかかるアムダール則の影響も当然ある。他方、10,000,000 回モンテカルロの傾向を見る限り性能向上曲線はリニアのようだ。したがってラフに言えば本例題に関する限りGPGPU の1 枚あたり88 倍の性能向上があると考えてよいだろう。NVIDIA 社はHPC 用として外付けのx4 ユニットを今秋出荷予定。このx4 ユニットならば最大350 倍の高速化が予想される。
- GTX280 の弱点は倍精度計算が遅いことだと言われる。FLOPS 値で言えば倍精度は単精度の1/8 の性能に過ぎない。それなのに上記の計測結果では1:3.5 程度と善戦している。その理由は、金融計算では倍精度であっても整数演算が多く含まれるので、32bit integer で行われる整数演算が多ければ倍精度の遅さが隠蔽されるからだろう。
安価な構築コスト
グリッド・コンピューティングに比べて圧倒的に安いコスト。
【同じことを試そうとされる方への注意】
我々がパーツからパソコンを組み立てた理由はGTX280 が大容量の電源と新しいバス(PCI Express Gen.2)を必要とするため。この自作例のようにGTX280 を2 枚入れる場合は電源容量の面でさらにハードルが上がる。もし仕様に合わないPC を無理矢理に使うと危険。企業内でも安心できる導入をしたければ、GTX280 のGPGPU 版製品(TESLA)に変更し、大容量電源を備えたハイエンドPCの選択が適切だろう。
最大の難関:プログラミング
アクセラレータのプログラミングは難しい
アクセラレータ方式を選んだら、ハードウェアから理解しなければ動作さえさせられない。もちろんグリッド方式にしたところで並列処理は難しいが、アクセラレータ方式はさらに難易度が高い感じだ。平均的なプログラマでは開発できない。オフショアの下請けプログラマ任せにしていたら性能も引き出せない。金融機関は立派なハードウェアを買ってはいるが、ソフトウェア開発がプアなせいでシステム投資額を無駄にしてはいないか。
結局、優秀な開発要員を求めるならば金融機関の中、特にクオンツ自身やクオンツ周辺のエンジニアから人材を探した方がよいだろう。

つまり、この文書を読んでいるあなたがプログラマの第一候補なのである。
残念ながら現在のアクセラレータ方式は小規模開発向き
| グリッド方式 | アクセラレータ方式 | |
|---|---|---|
| 汎用性 |
![]() 様々なプログラミングモデルを選択できる。 |
![]() 現世代はSIMD が前提(限定的なMIMD)。繰り返し処理は得意。大量データ処理は苦手。現世代のアクセラレータは小さなプログラムしか格納できない。 |
| 信頼性 |
![]() 実績多数。ただし金融系HPC ではエンジニアもアプリケーションも未熟。学術系HPC に比べてプアなシステムが多い。 |
![]() まだ出始め。代替的手段で実行結果を確認して使わないと危ない。どの方式が生き残るかまったく読めない。 |
| コスト |
![]() 大変な高額。 |
![]() 圧倒的に安い。 |
| 開発リスク |
![]() 学術系HPC からみれば金融系HPC の大半が性能未達と言って良いだろう。 |
![]() 開発規模が大きくなりようがないから開発リスクは低い。つまり低い汎用性とは逆の理由。 |
- グリッド・コンピューティング=ブレードサーバーの大量販売。顧客にグリッド方式をやめてアクセラレータ方式に変更されたら、ベンダーにとっては大幅な受注額減になる。そんな提案書は、金融機関側が要求しない限り、ベンダー側から持ってくるとは考えないほうがよいだろう。ハードウェア・メーカーやインテグレータ側のコンサルタントにプロジェクトを丸投げすれば、痛い目に遭うのは発注する金融機関側である。
- 大量のコードリソースを必要とする大規模なポートフォリオのリスク管理に使うならば、アクセラレータ方式はプログラミングモデルが複雑で大規模開発に向かない。しかもアクセラレータの本命がわからない。アクセラレータを使う大規模な長期開発を始めても、出来上がった頃には当該製品が生き残っていないかもしれない。数値の信頼性も低い(IEEE754 準拠レベルが低い)。現行世代のアクセラレータは高速メモリが8bit パソコン並みに小さい(NVIDIA GTX280 ではわずかに16KB のshared memory)。低速なグローバルメモリの量も32bit パソコン程度(同じくGTX280 では1GB)。このためさらに低速なCPU ・アクセラレータ間のデータ転送(PCI Express Gen.2 x16 で片方向8GB/s)がボトルネックとなり、64bit OS を要求する規模の大量トランザクション処理には困難を伴う。だから現段階ではグリッド方式しか選びようがない。
- 二重モンテカルロになるケースでは学術系HPC で見られるハイブリッド方式も考えられる。
最新HPC技術に注目を
ベンダーとの利益相反
グリッド・コンピューティング=ブレードサーバーの大量販売。顧客にグリッド方式をやめてアクセラレータ方式に変更されたら、ベンダーにとっては大幅な受注額減になる。そんな提案書は、金融機関側が要求しない限り、ベンダー側から持ってくるとは考えないほうがよいだろう。ハードウェア・メーカーやインテグレータ側のコンサルタントにプロジェクトを丸投げすれば、痛い目に遭うのは発注する金融機関側である。
HPC の学会で情報を集めよう
主要なHPC の学会のひとつSC 。毎年11 月頃に開催される。最近は金融HPC に関する学会発表も目立つ。金融機関は人を派遣して情報収集に努め、ダメなベンダーやインテグレータの言いなりで意味のないグリッド構築をしないように、自ら技術トレンドについて行くべきだろう。
そうでないと、いつまでも「RedHat かWindows か迷ってます」とか「Platform 社のミドルウェアを入れたから大丈夫です」のレベルを超えられない。低レイテンシ広帯域ネットワーキング、トポロジ、並列I/O 、並列プログラミングモデルなど、HPC 独特の専門知識が蓄えないとせっかくのシステム投資が無駄になりかねない。アクセラレータ技術のような適材適所で使うべきテクノロジーも同様である。

-
お断り
- 本文書の著作権はニューメリカルテクノロジーズ株式会社に帰属します。
- 本文中で使用されている製品名・社名などは、一般にその所有者の商標または登録商標です。
- ニューメリカルテクノロジーズ株式会社は、本文書の完全性、正確さを保証致しません。いかなる場合においても、ニューメリカルテクノロジーズ株式会社は本文書に関連して生じた通常の直接的、間接的、必然的、偶発的、特別な、あるいは懲罰的賠償について、たとえニューメリカルテクノロジーズ株式会社がそのような賠償が発生する可能性があることを通告されたとしても、なんら責任を負いません。










