問題タブ [hft]

ここ数週間、高頻度取引に関する多くの記事に出くわしました。彼らは皆、コンピュータとソフトウェアがこれにとってどれほど重要であるかについて語っていますが、それらはすべて経済的な観点から書かれているため、ソフトウェアが何をするかについての詳細はありません?

プログラマーの観点から、高頻度取引とは何かを説明できる人はいますか? また、この分野でコンピュータ/ソフトウェアが重要なのはなぜですか?

これまで、ハードウェアアクセラレーションと組み込みプログラミングは、データフィードを解析したり、注文を交換にルーティングしたりするために主に使用されてきました。ハードウェアでの株式マーケットメイクなど、より単純なHFT戦略を作成する試みはありましたか？彼らは成功しましたか？どの企業がこれを行っており、どのようなプログラミングモデルが使用されていますか？

低遅延を必要とする高頻度取引 (HFT) システムでは、UDP よりも TCP が使用されると言われました。TCPではポイントツーポイント接続を作成できるのに対し、UDPではできないと言われましたが、私の理解では、UDPパケットを特定のIP /ポートに送信できます。

この記事では、ゲームで UDP > TCP を使用する理由についていくつかの議論が行われていますが、HFT との関連性は理解できます。

TCP が HFT に使用するのに適したプロトコルである理由は何ですか?

(管理者: この質問の以前の投稿は、説明なしで黙って削除されました。使用条件に違反している場合は、黙って質問を削除するのではなく、これについて警告してください)

これは、hftに精通している人にとってはより理論的な質問だと思います。FASTから注文を受け取り、処理します。私は毎秒約2〜3千件の注文を受け取ります。問題は、それらを同期または非同期で処理する必要があるかどうかです。

次の注文を受けるたびに、次のことを行う必要があります。

• 対応する機器のオーダーブックを更新する
• その順序に依存するインデックスとインジケーターを更新します
• 戦略を更新し、必要に応じていくつかのアクションをスケジュールします（何かを購入/販売するなど）

その同期を行うには、約200〜300 µsがあります（1秒あたり3000オーダーを処理できるようにするため）。それで十分だと思います。

私が費やした非同期タスクをスケジュールするためだけに、約30 µsだと思います

長所と短所：

同期：

• ++物事を同期する必要はありません！
• ++「注文を受け取った」と「アクションを実行した」の間の遅延は、タスクをスケジュールしたり、データ/作業を別のプロセスに渡したりする必要がないため、少なくなります（hftでは非常に重要です！）。
• -ただし、前の注文が処理されるのを待機しているソケットバッファで待機できるため、「注文を受信しました」アクションが遅延する可能性があります

非同期：

• ++最新のサーバーの能力を使用する機能（たとえば、私のサーバーには24コアがあります）
• ++一部のシナリオでは、前のメッセージが処理されるまで待たないため、より高速になります。
• ++は、より多くのメッセージを処理したり、メッセージごとにより多くの「複雑な」ことを実行したりできます
• -プログラムの速度を低下させる可能性のある多くのものを同期させる必要があります

同期の例：更新されたMSFT注文を受け取り、次にINTC注文更新を受け取り、それらを異なるスレッドで処理します。どちらの場合も、NASDAQインデックスの再計算をトリガーします。したがって、NASDAQインデックスの計算は同期する必要があります。ただし、この特定の問題は、同期を回避するために回避できます...これは可能な同期の単なる例です。

したがって、問題は、注文の更新を同期または非同期で処理する必要があるかどうかです。これまでのところ、私はそれらを非同期で処理し、楽器ごとに専用のスレッドを持っています。異なる機器（MSFTとINTC）に対して2つの更新を非同期で処理できますが、1つの機器（MSFT）に対して2つの更新を同期的に処理する必要があるためです。

サーバー (2 * E5-2640 を実行) の別の「コア」(24 個の仮想利用可能なコアの 1 つ) を与えることにしたほど頻繁に変化する株式市場指数を計算していますとにかく、これまでのところ私は 5% しか持っていませんCPU 負荷が少ないので、多くの空き CPU パワーを利用できます。

株式市場の指数の変化に早急に対応する必要があるため、ロックフリー コードを使用することにしました。これは、私が実際に使用するものの例です。

出力：

平均で 2 マイクロ秒というのは、私が使用している 18 マイクロ秒と比較すると、かなり驚くべきことBlockingCollection です。

私は多くの空き CPU パワーを持っており、HFT ではマイクロ秒が重要であるため、このマイクロ秒が本当に必要です。

質問は簡単です。私の例に問題はありますか? 私はロックフリーのコードを書いたことがないので、ばかげた間違いをするかもしれません。プリミティブな変更 (int/double/decimal) は「アトミック」であると想定しているため、スピンロックは使用しません。したがって、2 番目のスレッドでは常に前の値または新しい値のいずれかを受け取りますが、他には何も受け取りません。

つまり、1 つのスレッドで int x を 100 から 555 に変更すると、2 番目のスレッドでは 100 または 555 になりますが、500 または 155 などにはなりません。

たとえば、NASDAQ のインデックスを計算しています。

すべての株価は 10 進数です。重みを 10 進数または 2 倍にすることができます。問題ありません。

ナスダック = 重量 1 * 在庫 1 + 重量 2 * 在庫 2 + .... + 重量 n * 在庫 n.

株価は小数であるため、ナスダック指数を小数にするのは理にかなっているようです。しかし、株式が更新されるたびにナスダック指数を再計算したくありません。代わりに、以前の値を「キャッシュ」してから、差のみを計算したいと考えています。たとえば、stock2 が変更された場合、次のようになります。

株式は同時に更新できるため、ナスダック指数を同期する必要があります。たとえば、MSFT と INTC の新しい価格を並列スレッドで受け取ることができます。したがってInterlocked.Add(ref nasdaq, diff * weight2);、以前の質問を参照して、ロックフリーコードを使用して異なるスレッドから追加を同期する方法を書かなければなりませんか? ただしdecimal、小数がサポートされていないため、それはできません。

それでは、nasdaqindex をdouble?として宣言してみましょう。double を使用して実行できますInterlocked.Addが、別の問題が発生しました。すべてのステップで 10 進数から double に変換するため、精度が失われます。そして、私の「スマートキャッシングアルゴリズム」は絶対に「正確」ではありません。これは、100 000 000 の更新後にインデックスの値が完全に間違ったものになることを意味し、それに対処することはできません。

したがって、使用することもdouble、どちらも使用することもできませんdecimal。

decimal考えられる解決策は1つだけです。「スマートキャッシングアルゴリズム」を使い続けることができるように、ナスダックインデックスを宣言する必要があるため、より複雑な「同期」メカニズムを使用する必要があり、おそらくスピンロックを使用する必要があります。

おそらく、より簡単な解決策を見ることができますか？

私はHFTソフトウェアを書いています。

Disruptorは、「高性能のスレッド間メッセージングライブラリ」であると主張しており、明らかにパフォーマンスが大幅に向上しています。

.NETに匹敵する速度のものはありますか？

指値注文を「維持」して、現在のオファーよりも常に $0.10 安く「MSFT」を購入するとします。

したがって、オファーが移動した場合は、注文も移動する必要があります。

たとえば、オファーが 30.10 から 30.11 に移動された場合、注文を 30.00 から 30.01 に移動する必要があります。

問題は、何らかの理由でオファーが 30.10 と 30.11 の間で頻繁に移動する場合、注文も頻繁に移動することです。証券取引所は余分な取引に対して「請求」するので、取引の数をできるだけ少なくする必要があるため、残念です。

だから私は自分のシリーズをもっと「動かない」ものにしたいと思っています。つまり、そのようなシリーズ「30.00 30.01 30.00 30.01 30.00 30.01 30.02」をおそらくそのようなシリーズ「30.00 30.00 30.00 30.00 30.00 30.01 30.02」に置き換えたい

「オファー」がどのように変更されるか正確にはわかりませんが、注文の移動数を「制限」する必要があります。

したがって、このような単純な Solution1 を使用することをお勧めします。注文が Price1 から Price2 に移動した場合、次の期間 (1 秒程度) の間、この注文を Price1 に移動することは禁止されています。これにより、すべてのケースがカバーされます。例えば：

1. Price1 -> Price2 - 許可
2. Price2 -> Price3 - 許可
3. Price3 -> Price1 - 十分な時間が経過していない場合は辞退

Solution2 も提案できます。

「現在のオファー」の代わりに「最後の期間の最小オファー」を使用します。たとえば、「最後の 1 秒間の最小限のオファー」は頻繁に変更されることはありません。

「Solution1」では、上下の変更にすぐに反応しますが、「繰り返される」変更を除外します。ただし、「期間ごとに1回」移動します。

「Solution2」では、アップの変化に「遅延」で反応し、ダウンの変化にすぐに反応しますが、最低のオファーが繰り返されるたびに「ストップウォッチ」が「リセット」され、「もう一度カチカチ音をたてる」ため、まったく動かないこともあります。 2番目"。したがって、「最低のオファー」が 1 秒に 1 回以上繰り返される場合、私は何も動かずにある時点にとどまります。

あなたは何を提案できると思いますか？

私は整数の「オンライン」シリーズを持っているので、数ミリ秒ごとに新しい番号があります。頻度は指定されていません。数が多い場合もあれば、数がない場合もあります。

実際には、この数字はいわゆる「真の価格」です。取引アプリケーションで使用しています。

今は最後の数値を「真の価格」として使用しているだけなので、シリーズはまったく追跡しません。しかし、このようなアプローチにはいくつかの問題があります。このシリーズを見てみましょう：

1. 98; 最後 = 98
2. 100; 最後 = 100
3. 101; 最後 = 101
4. 100; 最後 = 100
5. 101; 最後 = 101
6. 100; 最後 = 100
7. 101; 最後 = 101
8. 100; 最後 = 100
9. 101; 最後 = 101
10. 100; 最後 = 100
11. 99; 最後 = 99
12. 98; 最後 = 98

問題は、私の「真の価格」が非常に短期間に 100 から 101 に何度も変更されてしまうことです。真の価格を変更するたびに、多くの作業 (再計算、発注など) が必要になるため、そのような真の価格を変更する必要はありません。この変更 (100-101-100-101) は「測定の問題」によるものであり、フィルタリングする必要があります。「計測」は直せないので、ここで直さなければなりません。

アプローチの 1 つは、「3LastAverage」アルゴリズムを使用することです。

1. 98; 3 最後の平均 = 98
2. 100; 3 最後の平均 = 99
3. 101; 3 最後の平均 = 99.67 => 100
4. 100; 3 最後の平均 = 100.33 => 100
5. 101; 3 最後の平均 = 101
6. 100; 3 最後の平均 = 100
7. 101; 3 最後の平均 = 101
8. 100; 3 最後の平均 = 100
9. 101; 3 最後の平均 = 101
10. 100; 3 最後の平均 = 100
11. 99; 3 最後の平均 = 100
12. 98; 3 最後の平均 = 99

このようなアプローチが常に機能するとは限らないことがわかるように、私はまだ 100-101-100 の問題を抱えています。おそらく、より多くの数値を使用して「平均」を計算できます...しかし、そのような例のため、そのようなアプローチはうまくいきません:

1. 99; 3lastAverage = 99 (99 が欲しい)
2. 100; 3lastAverage = 100 (100 が欲しい)
3. 101; 3lastAverage = 100 (101 が必要)
4. 102; 3lastAverage = 101 (102 が必要)
5. 103; 3lastAverage = 103 (103 が欲しい)

一般に、物事が「OK」になったときは、truePrice を最後の数字にする必要があります。

したがって、整数の「オンライン」シリーズがあるため、このシリーズのいわゆる「真の値」を計算する必要があります。これは、次のように定義されています。

• すべてが問題なければ、これは最後の数字です
• 直列に同じ数が多すぎる場合（測定の問題のため）、「真の値」はあまり頻繁に変化するべきではありません。最も適切な値を使用する必要があります

私の提案は次のとおりです。

• 「真の値」が 1 秒に 2 回以上同じ価格になることを禁止するだけです。

例えば：

1. 0.000 : 98; 真の値 = 98
2. 0.100 : 100; 真の値 = 100
3. 0.200:101; 真の値 = 101
4. 0.300 : 100; 真の値 = 101 (100 は 0.2 秒前のステップ 2 で既に使用されています)
5. 0.400 : 98; 真の値 = 101 (98 は 0.4 秒前のステップ 1 で既に使用されています)
6. 0.500 : 99; 真の値 = 99
7. 0.600 : 100; 真の値 = 99 (0.5 秒前のステップ 2 で 100 が使用されました)
8. 1.500:101; 真の値 = 101 (101 が使用されてから 1 秒以上経過)。

ただし、そのようなアプローチには次のような「バグ」もあります。

1. 99tp = 99
2. 100tp = 100
3. 101 tp = 101
4. 102 tp = 102
5. 103 tp = 103
6. 102 tp = 103
7. 101 tp = 103
8. 100 tp = 103
9. 99tp = 103
10. 98tp = 98
11. 97tp = 97

ここでの問題は、「tp」がレベル 103 で長時間「凍結」されていたことです。

大変な質問で大変申し訳ありません。しかし、おそらく誰かが密接な問題を解決していて、経験を共有することができます. 私の主な問題は、2 つの相反する問題を同時に解決する必要があることです。

• 「真の価格」は、一般的な条件下での「最後の」値でなければなりません
• 「真の価格」は頻繁に変更すべきではありません (そのため、以前の値を何らかの方法で使用する必要があります)。
• また、いつ「一般的な」条件があり、いつ「測定上の問題」があるのか​​を判断するのは困難です。

だから私の質問は本当に漠然としていて、誰かがそのようなことを解決しようとしていたことを願っています. いつものように、この問題を解決するには「常識」を使用する必要があります。

私は HFT 取引ソフトウェアを書いています。私はすべてのマイクロ秒を気にします。今は C# で書いていますが、すぐに C++ に移行します。

そのようなコードを考えてみましょう

超低遅延ソフトウェアは「new」キーワードをあまり使用すべきではないと思うのでactions、次のフィールドに移動しました。

おそらく、「新しい」キーワードをまったく避けるようにする必要がありますか？事前に割り当てられたオブジェクトの「プール」を使用できます。

• どこまで行けばいいですか？
• 避けることがどれほど重要newですか？
• 構成のみが必要な事前割り当てオブジェクトを使用している間、何かを獲得できますか? （上記の例ではタイプと価格を設定）

これは超低遅延なので、可読性保守性などよりもパフォーマンスが優先されると仮定してください。