メールバッグで私が最も頻繁に受け取る質問の1つは,アルゴリズム取引のための最良のプログラミング言語は何ですか. 簡単な答えは,最も優れた言語はないということです. 戦略パラメータ,パフォーマンス,モジュール性,開発,回復力,コストはすべて考慮する必要があります. この記事では,アルゴリズム取引システムのアーキテクチャの必要なコンポーネントと,実装に関する決定が言語の選択にどのように影響するかについて説明します.
まず,アルゴリズム取引システムの主要な構成要素,例えば研究ツール,ポートフォリオ最適化器,リスクマネージャ,実行エンジンなど,検討される.その後,異なる取引戦略と,そのシステムの設計に影響を及ぼす方法が検討される.特に,取引の頻度と,取引の確率量は両者とも議論される.
取引戦略が選択された後,システム全体をアーキテクチャにする必要があります.これはハードウェアの選択,オペレーティングシステム (s) と,希少で潜在的に壊滅的な出来事に対するシステムの回復力を含みます.アーキテクチャを検討している間,パフォーマンスに適切な配慮が必要です.研究ツールとライブ実行環境の両方.
貿易 制度 は 何 を 試み て い ます か
自動取引システムを書くための"ベスト"言語を決定する前に,要件を定義する必要があります. システムは純粋に実行に基づいているのでしょうか? システムはリスク管理またはポートフォリオ構築モジュールが必要ですか? システムは高性能バックテストが必要ですか? ほとんどの戦略では,取引システムは2つのカテゴリーに分けることができます. 研究と信号生成.
研究は,歴史的なデータに対する戦略のパフォーマンスの評価に関与する.以前の市場データに対する取引戦略の評価プロセスはバックテストとして知られる.データサイズとアルゴリズムの複雑さは,バックテストの計算強度に大きな影響を与えます.CPU速度と並行性は,しばしば研究実行速度を最適化する制限要因です.
シグナル生成は,アルゴリズムから一連の取引信号を生成し,通常はブローカージングを通じてそのようなオーダーを市場に送信する.特定の戦略には高いレベルのパフォーマンスが必要である.ネットワーク帯域幅や遅延などのI/O問題は,実行システムを最適化する際の制限要因である.したがって,システム全体の各コンポーネントのための言語の選択はかなり異なることがあります.
戦略の種類,頻度,規模
採用されるアルゴリズム戦略の種類は,システムの設計に大きな影響を与えます.取引されている市場,外部データベンダーとの接続性,戦略の頻度と容量,開発の容易さとパフォーマンス最適化との間のトレードオフ,および必要となるカスタムハードウェア,コロロケーションカスタムサーバー,GPUまたはFPGAを含む.
低周波の米国株式戦略の技術選択は,先物市場で取引する高周波の統計的仲介戦略と大きく異なります.言語の選択の前に,手元にある戦略に関連する多くのデータベンダーを評価する必要があります.
販売者との接続性,APIの構造,データのタイムリー性,ストレージ要件,および販売者がオフラインになる場合の回復性を考慮する必要があります.また,複数のベンダーへの迅速なアクセスを持つことも賢明です!様々なツールはそれぞれ独自のストレージの奇異性があります.その例には,株式のための複数のティッカーシンボルと先物期間の有効期限日数 (特定のOTCデータについては言及していません).これはプラットフォーム設計に考慮する必要があります.
戦略の頻度は,技術スタックがどのように定義されるかを決定する最大の要因の一つである可能性が高い.データを使用する戦略は,毎分または二次バーよりも頻繁に,パフォーマンスに関して重要な考慮が必要です.
2度目のバー (すなわち,ティックデータ) を超えた戦略は,主要要件としてパフォーマンス駆動設計につながります.高周波戦略では,かなりの量の市場データが保存および評価されなければなりません.HDF5またはkdb+などのソフトウェアは,これらの役割のために一般的に使用されます.
HFT アプリケーションに必要な膨大な量のデータを処理するために,広範に最適化されたバックテストと実行システムを使用する必要があります. C/C++ (おそらくアセンブリで) は最も強力な言語候補である可能性が高い.超高周波戦略には,ほぼ確実にFPGAs,交換コロロケーション,カーネル/ネットワークインターフェースチューニングなどのカスタムハードウェアが必要です.
研究システム
研究システムは,通常,インタラクティブ開発と自動スクリプトの混合を伴う.前者は,Visual Studio,MatLabまたはR StudioなどのIDE内でしばしば行われます.後者は,多数のパラメータとデータポイントに対する広範な数値計算を伴う.これは,コードをテストするためのシンプルな環境を提供する言語選択につながります.しかし,複数のパラメータ次元での戦略を評価するのに十分なパフォーマンスを提供します.
この領域における典型的なIDEは,広範なデバッグユーティリティ,コード完了機能 (Intellisense
数値バックテストには,上記の言語はすべて適している.しかし,コードが背景で実行されるため,GUI/IDEを使用する必要はない.この段階では,実行速度が主な考慮事項である.バックテストパラメータの寸法が大きい場合,コンパイルされた言語 (C++など) がしばしば有用である.そのような場合,そのようなシステムに注意を払う必要があることを忘れないでください!
Pythonなどの解釈言語は,復習された同等値との競争力を合理的に維持するために,バックテストステップのためにNumPy/pandaなどの高性能ライブラリを使用することが多い.最終的に,バックテストのために選択された言語は,特定のアルゴリズムの必要性および言語に利用可能なライブラリの範囲によって決定される (以下より).しかし,バックテストおよび研究環境に使用される言語は,建設ポートフォリオ,リスク管理および実行コンポーネントで使用されるものとは完全に独立している可能性があります.
ポートフォリオ構築とリスク管理
ポートフォリオ構築とリスク管理のコンポーネントは,小売アルゴリズムトレーダーによってしばしば見過ごされています.これはほぼ常に間違いです.これらのツールは資本が保存されるメカニズムを提供します.彼らは,リスクの高い賭けの数を軽減するだけでなく,取引コストを削減して取引自体を最小限に抑えます.
これらのコンポーネントの洗練されたバージョンは,収益性の質と一貫性に大きな影響を与える可能性があります.ポートフォリオ構築メカニズムとリスクマネージャーは,複数のシステムを処理するために簡単に変更できるため,戦略の安定性を作成することは簡単です.したがって,アルゴリズム取引システムの設計の開始時に不可欠なコンポーネントと見なされるべきです.
ポートフォリオ構築システムの仕事は,希望された取引のセットを取り,切断を最小限に抑え,さまざまな要因 (セクター,資産クラス,変動等) に関する露出を維持し,ポートフォリオ内のさまざまな戦略への資本の配置を最適化する実際の取引のセットを作成することです.
ポートフォリオの構築はしばしば線形代数の問題 (マトリックス因数分解など) に縮小され,したがってパフォーマンスは利用可能な数値線形代数の実装の有効性に依存する.一般的なライブラリには,C++用のuBLAS,LAPACK,NAGが含まれます.MatLabには,広範に最適化された行列演算も含まれています.Pythonは,そのような計算のためにNumPy/SciPyを使用します.頻繁に再バランスされるポートフォリオには,このステップを実行するためにコンパイルされた (そして最適化された!) マトリックスライブラリが必要です.
リスク管理は,アルゴリズム取引システムのもう1つの非常に重要な部分である.リスクは,様々な形で現れる:変動性の増加 (これは特定の戦略では望ましいと考えられるが!),資産クラス間の相関性の増加,対当事者のデフォルト,サーバーの切断,ブラック・スワン・イベント,取引コードの検出されていないバグなど.
リスクマネジメントコンポーネントは,過剰な変動と資産クラス間の相関関係とその後の影響 (s) の取引資本への影響を予測しようとします.しばしば,これはモンテカルロのストレステストのような統計計算のセットに縮小されます.これはデリバティブ価格設定エンジンの計算ニーズに非常に似ています.これらのシミュレーションは高度に並列化可能であり,ある程度には,問題に対してハードウェアを投げることは可能です.
執行システム
実行システムの仕事は,ポートフォリオ構築およびリスク管理コンポーネントからフィルタリングされた取引信号を受信し,ブローカーまたは他の市場アクセス手段に送信することです.小売アルゴリズム取引戦略の大部分では,これはインタラクティブブローカーなどのブローカーへのAPIまたはFIX接続を含む.言語を選択する際の主な考慮事項には,APIの品質,APIのための言語ラッパの利用可能性,実行頻度,予想されたスライプが含まれます.
APIの"品質"とは,APIがどの程度文書化されているか,どのようなパフォーマンスを提供するか,アクセスするにはスタンドアロンソフトウェアが必要かどうか,またはゲートウェイがヘッドレスな方法で (GUIがない) 確立できるかどうかを指します.インタラクティブブローカーの場合,トレーダーワークステーションツールはAPIにアクセスするためにGUI環境で実行する必要があります.私はかつてAmazonクラウドサーバーにデスクトップUbuntu版をインストールする必要がありました.この理由だけで,インタラクティブブローカーを遠隔でアクセスするために!
ほとんどのAPIはC++および/またはJavaインターフェースを提供します. C#,Python,R,ExcelおよびMatLabの言語特有のラッパーを開発するのは通常コミュニティ次第です.追加されたプラグイン (特にAPIラッパー) を使用するたびに,バグがシステムに潜入する余地があることを注意してください.常にこのようなプラグインをテストし,積極的に維持することを確認してください.最近数ヶ月でコードベースに何件の新しい更新が行われたかを見るのが価値のある指標です.
実行頻度は実行アルゴリズムにおいて極めて重要である.毎分数百のオーダーが送信される可能性があるため,パフォーマンスが重要なことに注意してください.不効率な実行システムによって滑り込みが起こり,これは収益性に大きな影響を与えます.
C++/Javaなどの静的型言語 (下記を参照) は,通常実行に最適であるが,開発時間,テスト,保守の容易さにはトレードオフがある.PythonやPerlなどの動的型言語は,現在一般的に十分速い.コンポーネントがモジュール式に設計されていることを常に確認してください (下記を参照).
建築計画と開発プロセス
トレーディングシステムの構成要素,その頻度およびボリューム要件は,上記で議論されているが,システムインフラストラクチャはまだカバーされていない.小売トレーダーとして活動したり,小規模なファンドで働く人は,多くの帽子をかぶる可能性があります.アルファモデル,リスク管理および実行パラメータ,およびシステムの最終的な実装をカバーすることが必要になります.特定の言語に深入する前に,最適なシステムアーキテクチャの設計について議論されます.
憂慮 を 切り離す
始めにしなければならない最も重要な決定の一つは,取引システムの"関心事"をどのように分離するかである.ソフトウェア開発では,これは基本的に,取引システムのさまざまな側面を個々のモジュール構成要素に分割する方法である.
各コンポーネントのインターフェースを露出することで,外部依存コードを変更することなく,パフォーマンス,信頼性または保守を助ける他のバージョンのためにシステムの部分を交換することは簡単です.これはそのようなシステムのための"ベストプラクティス"です.低周波の戦略では,そのようなプラクティスが推奨されます.超高周波取引では,さらに高いパフォーマンスのためにシステムを調整する犠牲にルールブックを無視する必要があります.より緊密に結合されたシステムは望ましいかもしれません.
アルゴリズムの取引システムのコンポーネントマップを作成することは,それ自体で記事に価値があります.しかし,最適なアプローチは,歴史的およびリアルタイムの市場データ入力,データストレージ,データアクセス API,バックテスト,戦略パラメータ,ポートフォリオ構築,リスク管理,自動実行システムに別々のコンポーネントがあることを確認することです.
例えば,現在使用されているデータストレージが,重要なレベルの最適化でも,パフォーマンスが劣っている場合,データインジェクションまたはデータアクセス APIに最小限の書き換えで交換することができます.バックテストと次のコンポーネントに関しては,違いはありません.
分離されたコンポーネントのもう一つの利点は,全体的なシステムでさまざまなプログラミング言語を使用することを可能にすることです.コンポーネントの通信方法が言語独立である場合,単一の言語に制限する必要はありません.TCP/IP,ZeroMQまたは他の言語独立プロトコルを通じて通信している場合,このようなことが起こります.
具体的な例として,BacktestingシステムがC++で"number crunching"の性能のために書かれ,ポートフォリオマネージャーと実行システムはSciPyとIBPyを使用してPythonで書かれています.
性能に関する考慮事項
性能は,ほとんどの取引戦略において重要な考慮事項である.高周波戦略では最も重要な要因である. 性能は,アルゴリズムの実行速度,ネットワークレイテンシー,帯域幅,データI/O,並行性/並行性,スケーリングなどの幅広い問題をカバーする.これらの領域はそれぞれ大きな教科書によって個別にカバーされているため,この記事はそれぞれのテーマの表面を掻くのみである.建築と言語選択は,現在パフォーマンスへの影響の観点から議論される.
コンピュータサイエンスの父であるドナルド・ノースが述べたように,支配的な知恵は"早速の最適化はすべての悪の根源である"である.これはほぼ常に事実である.高周波取引アルゴリズムを構築する場合は除く.低周波戦略に興味のある人のために,一般的なアプローチは,可能な限りシンプルな方法でシステムを構築し,ボトルネックが現れ始めたときにのみ最適化することです.
プロファイリングツールは,ボトルネックが生じる場所を決定するために使用されます.プロファイルは,MS WindowsまたはLinux環境で,上記のすべての要因のために作成できます.多くのオペレーティングシステムと言語ツール,および第三者のユーティリティがこれを行うことができます.言語選択は,現在パフォーマンスの文脈で議論されます.
C++,Java,Python,RおよびMatLabは,基本データ構造とアルゴリズム作業のための高性能ライブラリ (標準の一部または外部) をすべて含んでいる.C++は標準テンプレートライブラリと交配され,PythonにはNumPy/SciPyが含まれている.これらのライブラリには一般的な数学タスクがあり,新しい実装を書くことはめったに有益ではない.
1つの例外は,高度にカスタマイズされたハードウェアアーキテクチャが必要であり,アルゴリズムは独自の拡張機能 (カスタムキャッシュなど) を広く利用している場合である.しかし,しばしば"輪の再発明"は,取引インフラストラクチャの他の部分を開発し最適化するのにより良い時間を無駄にする.開発時間は特に単独開発者の文脈では非常に貴重なものです.
遅延は,通常同じマシンに研究ツールが配置されているため,実行システムの問題である.前者では,実行経路に沿った複数のポイントで遅延が発生する可能性があります. データベースを閲覧 (ディスク/ネットワーク遅延),信号を生成 (オペレーティングシステム,カーネルメッセージング遅延),取引信号を送信 (NIC遅延) および注文処理 (交換システムの内部遅延) が必要です.
高周波操作では,カーネル最適化やネットワーク伝送の最適化について深く熟知することが必要です.これは深い分野であり,記事の範囲を大幅に超えていますが,UHFTアルゴリズムが望まれている場合,必要な知識の深さを認識してください!
キャッシングは,定量的な取引開発者のツールキットで非常に有用である.キャッシングは,データの潜在的な静止性を犠牲にして,より高いパフォーマンスのアクセスを可能にする方法で頻繁にアクセスされるデータを保存する概念を指す.ディスクバック付きのリレーショナルデータベースからデータを取り,メモリに入力する際にWeb開発で一般的な使用ケースが発生する.データへの次のリクエストは,データベースに"ヒット"する必要がないため,パフォーマンスの向上は重要である.
取引状況ではキャッシングが非常に有益である.例えば,戦略ポートフォリオの現在の状態は,再バランスされるまでキャッシュに格納され,取引アルゴリズムの各ループでリストを再生する必要がない.そのような再生は,高いCPUまたはディスクI/O操作である可能性が高い.
しかし,キャッシングには独自の問題がある.キャッシュストレージの不安定な性質のために,キャッシュデータの再生が同時にインフラストラクチャに大きな需要を及ぼす可能性があります.別の問題は,非常に高い負荷下で新しいキャッシュコピーの数世代が実行され,カスケード失敗につながるドッグ・ピーリングです.
ダイナミックメモリアロケーションは,ソフトウェア実行における高価な操作である.したがって,より高いパフォーマンスの取引アプリケーションは,プログラムフロー中にメモリがどのように割り当てられ,配分されているか十分に認識することが不可欠である.Java,C#,Pythonなどの新しい言語標準はすべて,オブジェクトが範囲外に行くときにダイナミック配分されたメモリの配分を意味する自動ゴミ収集を実行する.
ゴミ収集は,エラーを削減し,読みやすさを助けるため,開発中に非常に有用である.しかし,特定の高周波取引戦略ではしばしば最適ではない.これらのケースでは,カスタムゴミ収集がしばしば望ましい.例えばJavaでは,ゴミ収集器とヒープの構成を調節することによって,HFT戦略の高いパフォーマンスを得ることが可能である.
C++ はネイティブゴミ収集器を提供していないため,オブジェクトの実装の一環としてすべてのメモリ割り当て/デアロケーションを処理する必要があります. 潜在的にエラーに易い (ポインタをぶら下げることにつながる可能性があります) がありますが,特定のアプリケーションでオブジェクトが堆積物にどのように表示されますかを細かく制御することが非常に有用です. 言語を選択する際に,ゴミ収集器がどのように機能するか,特定の用例に最適化するために修正できるか,調べることを確認してください.
アルゴリズム取引システムの多くの操作は並列化に適している.これは複数のプログラム操作を同時に,すなわち"並列"で実行するという概念を指す.いわゆる"不快な並列"アルゴリズムには,他のステップから完全に独立して計算できるステップが含まれている.モンテカルロシミュレーションなどの特定の統計操作は,他のパスに関する知識なしに各ランダム抽出と次のパス操作が計算できるため,不快な並列アルゴリズムの良い例である.
他のアルゴリズムは部分的に並列化可能である.流体力学シミュレーションは,計算領域を分けるような例であるが,最終的にこれらの領域は互いに通信しなければならないため,操作は部分的に連続的である.並列化可能なアルゴリズムは,NNの独立したプロセス (例えばCPUコアまたはスレッド) に従えば並列化されたアルゴリズムの性能増加の理論上の上限を提供するアムダール法則に従います.
パラレライゼーションは,プロセッサのクロック速度が停滞して以来,最適化手段としてますます重要になってきている.新しいプロセッサには,並行計算を行うための多くのコアが含まれているため.消費者向けグラフィックハードウェア (主にビデオゲーム用) の上昇は,高度な並行操作のために数百のコアを含むグラフィック処理ユニット (GPU) の開発につながった.そのようなGPUは現在非常に手頃である.NvidiaのCUDAなどの高レベルのフレームワークは,学界や金融に広く採用された.
このような GPU ハードウェアは,一般的に定量金融の研究側面にのみ適しており,他のより専門的なハードウェア (フィールドプログラム可能なゲートアレイ (FPGA) を含む) は, (U) HFT に使用されています.現在,ほとんどの近代的な言語は一定程度の並行/マルチスレッドリングをサポートしています.したがって,すべての計算が一般的に他のものとは独立しているため,バックテストを最適化することは簡単です.
ソフトウェアエンジニアリングおよび運用におけるスケーリングとは,より大きな要求,より高いプロセッサ使用,より多くのメモリ割り当ての形で一貫して増加する負荷を処理するシステムの能力を指す.アルゴリズム取引では,より多くの資本を受け入れながら一貫したリターンを生み出すことができれば,戦略はスケーリングすることができます. 貿易技術スタックスケーリングは,ボトルネックなしで,より大きな取引量と増加したレイテンシーに耐えることができればスケールされます.
システムはスケーラブルに設計されなければならないが,ボトルネックが起こる先を予測することはしばしば困難である.厳格なログリング,テスト,プロファイリング,モニタリングはシステムのスケーラブル化に大いに役立つ.言語自体はしばしば"スケーラブルでない"と記述される.これは通常,硬い事実ではなく誤った情報の結果である.スケーラブル性については言語ではなく,全体的な技術スタックが確認されるべきである.明らかに特定の言語は特定の使用ケースで他の言語よりも優れた性能を持っているが,一つの言語はあらゆる意味で決して他の言語よりも"より良い"ではない.
スケール管理の1つの手段は,上述したように,関心を分離することです.システムに"スパイク"を処理する能力をさらに導入するために (つまり,急激な波動が取引のレイプを誘発する),"メッセージキューアーキテクチャ"を作成することは有用です.これは単に,多くの要求を処理できない特定のコンポーネントの場合,注文が"積み重ねられる"ように,コンポーネントの間にメッセージキューシステムを配置することを意味します.
メッセージが処理されるまで要求が失われるのではなく,単にスタックに保管されます.これは特に実行エンジンに取引を送信するのに役立ちます.エンジンが重い遅延に苦しんでいる場合,取引をバックアップします.取引信号生成器と実行APIの間のキューは,潜在的な取引の滑りによってこの問題を解決します. 尊敬されているオープンソースメッセージキューブローカーはRabbitMQです.
ハードウェアとオペレーティングシステム
戦略を実行するハードウェアは,アルゴリズムの収益性に大きな影響を与えます.これは高周波トレーダーに限られた問題ではありません.ハードウェアやオペレーティングシステムの選択が不適切であれば,マシンがクラッシュしたり,最悪なタイミングで再起動したりすることがあります.したがって,アプリケーションがどこに配置されるかを検討する必要があります.選択は一般的にパーソナルデスクトップマシン,リモートサーバー,
デスクトップマシンは,特にWindows 7/8,Mac OSX,Ubuntuなどの新しいユーザーフレンドリーなオペレーティングシステムでは,インストールおよび管理が簡単です. デスクトップシステムにはいくつかの重大な欠点があります. しかし,最も重要なことは,デスクトップマシンのために設計されたオペレーティングシステムのバージョンは,リブート/パッチが必要になる可能性が高いことです (そしてしばしば最悪の場合!).また,グラフィカルユーザーインターフェース (GUI) を必要とするので,より多くのコンピューティングリソースを使用します.
家庭 (またはローカルオフィス) 環境におけるハードウェアの使用は,インターネット接続と電力稼働時間の問題を引き起こす可能性があります.デスクトップシステムの主な利点は,相当速度のリモート専用サーバー (またはクラウドベースのシステム) のコストのほんの一部で重要な計算馬力を購入できるということです.
専用サーバーまたはクラウドベースのマシンは,デスクトップオプションよりもしばしば高価ですが,自動化データバックアップ,稼働時間とリモートモニタリングをより直接的に確保する能力などのより重要な冗長性インフラストラクチャを可能にします.操作システムのリモートログイン機能を使用する能力を必要とするため,管理するのが困難です.
Windowsでは,通常,GUI リモートデスクトッププロトコル (RDP) を介して行う. Unix ベースのシステムでは,コマンドラインの Secure SHell (SSH) が使用される. Unix ベースのサーバーインフラストラクチャは,ほぼ常にコマンドラインに基づいているため,すぐに GUI ベースのプログラミングツール (MatLab や Excel など) が使用不能になる.
コロケイトサーバーは,資本市場で使用されているフレーズとして,取引アルゴリズムの遅延を減らすために取引所内に居住する専用サーバーである.これはアルファを生成するために低遅延に依存する特定の高周波取引戦略に絶対的に必要である.
ハードウェア選択とプログラミング言語選択の最終的な側面は,プラットフォーム独立性である.コードが複数の異なるオペレーティングシステムで実行される必要があるか?コードは,インテル x86/x64などの特定のタイプのプロセッサアーキテクチャで実行するように設計されているか,またはARMが製造するRISCプロセッサで実行できるだろうか.これらの問題は,実装されている戦略の頻度と種類に大きく依存する.
回復力 と 試し
アルゴリズムの取引で多くのお金を失う最良の方法の1つは,回復力のないシステムを作成することです.これは,ブローカージ破産,突然の過剰な変動,クラウドサーバープロバイダの地域全体のダウンタイム,または取引データベース全体の偶然の削除などの希少なイベントにさらされた場合,システムの耐久性を指します. 設計の悪いアーキテクチャで数秒以内に利益をなくすことができます. デバッグ,テスト,ログ,バックアップ,高可用性,モニタリングなどの問題をシステムのコアコンポーネントとして考慮することは絶対に重要です.
適正に複雑なカスタム定量取引アプリケーションでは,開発時間の少なくとも 50%がデバッグ,テスト,保守に費やされる可能性が高い.
ほぼすべてのプログラミング言語は,関連デバガーが搭載されているか,または尊敬されるサードパーティの代替品を持っている.本質的には,デバガーは,コードパスに任意のブレイクポイントを挿入してプログラムの実行を可能にします.これは,システムの状態を調査するために一時的に実行を停止します.デバッグの主な利点は,既知のクラッシュポイントの前にコードの行動を調査することが可能である.
デバッグはプログラミングエラーを分析するためのツールボックスの不可欠な構成要素である.しかし,C++やJavaなどのコンパイル言語では,Pythonなどの解釈言語がLOCが少なく,文言が少ないため,デバッグが容易であるため,より広く使用されている.この傾向にもかかわらず,Pythonは洗練されたデバッグツールであるpdbで出荷する.Microsoft Visual C++ IDEには広範なGUIデバッグユーティリティがあり,コマンドラインLinux C++プログラマにはgdbデバガーがあります.
ソフトウェア開発におけるテストは,コードベース内の特定の機能,方法,オブジェクトに既知のパラメータと結果を適用するプロセスを指し,動作をシミュレートし,複数のコード経路を評価し,システムが適切に動作することを確保するのに役立ちます.より最近のパラダイムは,テスト駆動開発 (TDD) と呼ばれ,テストコードは実装なしの指定されたインターフェースに対して開発されます.実際のコードベースが完了する前にすべてのテストは失敗します.コードが"空白を満たす"ように書かれると,テストは最終的にすべて通過し,その時点で開発は停止する必要があります.
TDDは,成功するために,広範な初期仕様設計と健全な規律の度合いを要求する.C++では,Boostはユニットテストフレームワークを提供します.Javaでは,JUnitライブラリも同じ目的を達成するために存在しています.Pythonには標準ライブラリの一部としてユニットテストモジュールもあります.他の多くの言語はユニットテストフレームワークを有しており,しばしば複数のオプションがあります.
生産環境では,洗練されたログリングは絶対的に不可欠です.ログリングは,システムの実行行動に関するメッセージをフラットファイルまたはデータベースにさまざまな重度で出力するプロセスを指します.ログは,予期せぬプログラム実行時の行動を狩る際に"攻撃の第一線"です.残念ながら,ログリングシステムの欠陥は,事実後にのみ発見される傾向があります.下記のバックアップと同様に,ログリングシステムは,システムが設計される前に適切に考慮する必要があります.
Microsoft Windows と Linux は,広範なシステムログング機能と付属しており,プログラミング言語は,ほとんどの用例をカバーする標準ログングライブラリと配送される傾向があります.これは,パフォーマンス向上やエラー削減に関するアイデアにつながるため,後で分析するためにログング情報を集中することがしばしば賢明です.これは,ほぼ確実に取引収益にポジティブな影響を与えます.
システムログは過去に起きたことを情報を提供するが,アプリケーションのモニタリングは,今起こっていることを洞察する.モニタリングのためにシステムのすべての側面を考慮すべきである.ディスク使用,利用可能なメモリ,ネットワーク帯域幅,CPU使用などのシステムレベルのメトリックは基本的な負荷情報を提供します.
不正常な価格/量,突然の迅速な引き下げ,さまざまなセクター/市場における口座露出などの取引指標も継続的に監視されるべきである.さらに,特定の指標が違反した場合の通知を提供する
システムモニタリングは,しばしばシステム管理者またはオペレーションマネージャーの領域である.しかし,単独の取引開発者として,これらのメトリックはより大きなデザインの一部として確立されなければならない.監視のための多くのソリューションがあります:プロプライエタリ,ホストおよびオープンソース,特定の用例のためのメトリックの広範なカスタマイゼーションを可能にします.
バックアップと高可用性は,取引システムの主要な関心事であるべきです.次の2つの質問を考えてみましょう. (1) 市場データと取引履歴の生産データベース全体が削除された場合 (バックアップなしで),研究および実行アルゴリズムがどのように影響されますか? (2) 取引システムが長期間にわたって中断された場合 (オープンポジションで),アカウントの資本と継続的な収益性はどのように影響されますか? この2つの質問の回答は,しばしば慎重です.
データ の バックアップ と その データ の 復元 を テスト する ため の システム を 設置 する こと が 必須 です.復元 戦略 を テスト し ない 人 は 多く い ます.事故 の 後 の 復元 が 安全 な 環境 で テスト さ れ て い ない なら,最悪 の 時 に 復元 が できる と いう 保証 は 何 です か.
同様に,高可用性も最初から考慮する必要があります.冗長なインフラストラクチャ (追加の費用であっても) は常に考慮する必要があります.ダウンタイムのコストは,そのようなシステムの継続的なメンテナンスコストをはるかに上回る可能性があります.このトピックは広い領域なので,深く掘り下げません.しかし,取引システムに与えられる最初の考慮事項の1つであることを確認してください.
言語 を 選ぶ
現在,カスタム高性能アルゴリズム取引システムの開発時に発生するさまざまな要因についてかなりの詳細が提供されています.次の段階は,プログラミング言語が一般的に分類される方法を議論することです.
タイプシステム
トレーディングスタック用の言語を選択する際には,型系を考慮する必要がある.アルゴリズム取引に興味のある言語は,静的または動的にタイプされている. 静的タイプ言語は,コンパイルプロセス中にタイプ (例えば整数,浮遊数,カスタムクラスなど) のチェックを実行する.そのような言語には,C++とJavaが含まれます.動的にタイプされた言語は,実行時にほとんどのタイプチェックを実行します.そのような言語には,Python,Perl,JavaScriptが含まれます.
アルゴリズムの取引エンジンなどの高度な数値システムでは,コンパイル時にタイプチェックは非常に有益であり,他の方法では数値エラーにつながる多くのバグを排除できる.しかし,タイプチェックはすべてを捉えることができず,予期せぬ操作を処理する必要性があるため例外処理が登場する.動的言語 (すなわち動的にタイプされているもの) は,他の方法ではコンパイルタイムタイプチェックで捉えられるランタイムエラーを引き起こすことが多い.このため,TDD (上記参照) とユニットテストの概念が生まれ,正しく実行された場合,コンパイルタイムチェック単独よりも多くの安全性を提供する.
静的型言語のもう一つの利点は,コンパイラが動的型言語には利用できない多くの最適化を行うことができるという点である.単に型 (したがってメモリ要件) がコンパイル時に知られているためである.実際には,動的型言語の非効率性の一部は,実行時に特定のオブジェクトが型検定されなければならないという事実から生じる.これはパフォーマンスヒットをもたらす. NumPy/SciPyなどの動的言語のライブラリは,配列内で型を強制することでこの問題を軽減する.
オープンソースか プロプライエタリか?
アルゴリズムの取引開発者にとって最も大きな選択肢の1つは,プロプライエタリ (商業的) またはオープンソース技術を使用するかどうかである.両方のアプローチには利点とデメリットがある.言語がどの程度サポートされているか,言語を取り巻くコミュニティの活動,インストールと保守の容易性,ドキュメントの品質,およびライセンシング/メンテナンスコストを考慮する必要があります.
Microsoft.NETスタック (Visual C++,Visual C#を含む) とMathWorks
MicrosoftとMathWorksは,両社の製品に幅広い高品質のドキュメントを提供している.さらに,各ツールの周辺のコミュニティは,両方のためのアクティブのウェブフォーラムで非常に大きい..NETソフトウェアは,C++,C#,VBなどの複数の言語との凝った統合を可能にする.また,LINQ経由でSQL Serverデータベースなどの他のMicrosoft製品との簡単なリンクを可能にする.MatLabには,ほぼすべての定量研究ドメインのための多くのプラグイン/ライブラリ (一部は無料,一部は商業用) もあります.
Visual Studioは,Windowsで実行されるソフトウェアであり,Windowsは,Windowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されているWindowsに搭載されている.
MatLabには,高性能アルゴリズム取引に適した数少ないブローカーの1つであるInteractive Brokers APIの周りの良いラッピングのようないくつかのキープラグインも欠けている.プロプライエタリ製品の主な問題はソースコードの利用可能性の欠如である.これは,超性能が本当に必要である場合,これらのツールはどちらもはるかに魅力的でないことを意味します.
オープンソースツールは,しばらく産業レベルであった.代替資産空間の大部分は,オープンソースのLinux,MySQL/PostgreSQL,Python,R,C++およびJavaを高性能生産役割で広く使用している.しかし,それらはこの領域に限定されることはない.特にPythonとRは,特定の注意事項とともに,しばしばコンパイルされた言語に匹敵する実行速度で,考えられるほぼあらゆる種類のデータ分析を実行するための広範な数値ライブラリを含んでいる.
インタプリテッド言語の使用の主な利点は,開発時間の速度である. Python と R は,主に広範なライブラリにより,同様の機能を達成するために,はるかに少ないコード行 (LOC) を必要とする.さらに,インタラクティブなコンソールベースの開発をしばしば許可し,繰り返しの開発プロセスを迅速に削減する.
開発者としての時間は非常に価値があり,実行速度はしばしば少なく (HFT領域を除く場合) であるため,オープンソース技術スタックに広範な考慮を払う価値がある. Python と R は重要な開発コミュニティを有し,その人気が非常に高いため非常によくサポートされています.ドキュメントは優秀で,バグは (少なくともコアライブラリでは) 希少です.
オープンソースツールは,専用の商用サポート契約の欠如に苦しんでおり,容赦のないユーザーインターフェースを持つシステムで最適に動作する.典型的なLinuxサーバー (Ubuntuのような) は,しばしば完全にコマンドラインを指向する.また,PythonとRは特定の実行タスクに遅い可能性があります.実行速度を改善するためにC++と統合するメカニズムがありますが,マルチ言語プログラミングの経験が必要です.
プロプライエタリソフトウェアは依存性/バージョン化問題から免れていないが,そのような環境で誤ったライブラリバージョンを扱わなければならないことはあまり一般的ではない.Linuxのようなオープンソースオペレーティングシステムは管理が難しい.
私はここで個人的な意見を冒頭して,私のすべての取引ツールをオープンソース技術で構築していると述べます.特に私はUbuntu,MySQL,Python,C++およびRを使用しています.成熟度,コミュニティの大きさ,問題が発生した場合に深く掘り下げること,および低コスト所有 (TCO) の能力は,プロプライエタリGUIのシンプルさとより簡単なインストールをはるかに上回ります.それにもかかわらず,Microsoft Visual Studio (特にC++) は素晴らしい統合開発環境 (IDE) で,私も強くお勧めします.
バッテリーも?
このセクションのヘッダは,言語の"out of the box"機能 - どれだけのライブラリが含まれ,どの程度良いかを指しています.ここでは成熟言語がより新しいバリエーションに優れているところです.C++,Java,Pythonには,ネットワークプログラミング,HTTP,オペレーティングシステムインタラクション,GUI,レギュラー表現 (レジェックス),イテレーション,基本的なアルゴリズムのための広範なライブラリがあります.
C++は,多くの高性能データ構造とアルゴリズムを含む標準テンプレートライブラリ (STL) で有名である. Pythonは,主に独自の標準ライブラリを通じて,ほぼ他のタイプのシステム/プロトコル (特にウェブ) と通信することが知られています. Rには多くの統計および経済学ツールが組み込まれています.
C++ は標準ライブラリ以外にも,標準ライブラリに欠けている部分を補うBoost ライブラリを使用している.実際には,Boost の多くの部分は TR1 規格に組み込まれ,その後 C++11 仕様で入手可能になり,ラムダ表現と並行に対応している.
Pythonには高性能 NumPy/SciPy/Pandas データ分析ライブラリ組み合わせがあり,アルゴリズム取引研究に広く受け入れられている.さらに,MySQL++ (MySQL/C++),JDBC (Java/MatLab),MySQLdb (MySQL/Python),psychopg2 (PostgreSQL/Python) などの主要なリレーショナルデータベースへのアクセスのために高性能プラグインがあります.PythonはRPyプラグインを通じてRと通信することもできます!
取引システムの初期研究・設計段階では,しばしば見過ごされる側面は,ブローカーAPIへの接続性である.ほとんどのAPIはC++とJavaをネイティブでサポートしているが,C#とPythonも直接またはコミュニティが提供するラッパーコードでC++APIをサポートしている.特に,Interactive BrokersはIBPyプラグインを通じて接続することができる.高性能が必要な場合は,ブローカーはFIXプロトコルをサポートする.
結論
現在明らかになっているように,アルゴリズム取引システムのためのプログラミング言語の選択は単純ではなく,深い思考を必要とする.主な考慮事項は,パフォーマンス,開発の容易さ,回復性およびテスト,懸念の分離,熟悉性,保守,ソースコードの利用可能性,ライセンスコスト,ライブラリの成熟度である.
分離されたアーキテクチャの利点は,要求が変化するにつれて,取引スタックの異なる側面のために言語を"接続"できるようにすることです.取引システムは進化するツールであり,言語選択もそれとともに進化する可能性が高い.