高頻度取引における C++: 市場データから確定的なレイテンシーまで

導入

高頻度取引には、技術的な議論を単純化する方法があります。ソフトウェアの多くの分野では、規模、ハードウェア予算、または十分な応答時間の期待の背後にある非効率性を隠しながら、システムは立派な状態を保つことができます。 HFT では、遅さは代償を伴います。不安定性は戦略の品質を損ない、診断を曖昧にし、スタック全体の信頼を弱めます。この領域は、理論に時間への答えを強制します。

だからこそ、C++ はトレーディング システムにおいて非常に重要であり続けます。この言語がそこで生き残っているのは、HFT が C++ が依然として異常に優れた特性を提供するプロパティの組み合わせを繰り返し要求しているためです。つまり、メモリ レイアウトの制御、正確なパフォーマンス作業、成熟したネイティブ ツール、深い OS とネットワークの統合、そしてプレッシャーの下で構築された数十年にわたる実際のシステムを通じて蓄積された膨大な実践的な知識です。

これを、C++ は速いなどの 1 つのスローガンにまとめたくなるでしょう。しかし、そのスローガンは小さすぎます。 HFT は、抽象的な実際の速度に報酬を与えるわけではありません。市場データから意思決定、注文送信までの経路全体にわたる決定的な行動に報酬を与えます。平均レイテンシは役立ちますが、予測可能なレイテンシはさらに役立ちます。時々素晴らしく、定期的に不安定なシステムは、わずかに遅く一貫して理解できるシステムよりも悪いことがよくあります。さらに深い話は、C++ は、動作を詳細に形成、測定、修正できる低遅延システムを構築するための最も強力な言語の 1 つであり続けているということです。

HFT が C++ に戻り続ける理由

時間通りに競争する取引スタックは、他のほとんどのドメインが曖昧にする余裕のある詳細を気にします。ホット パス上で割り当てがいくつ発生しますか?どのデータがキャッシュ内に一緒に存在しますか?どのスレッドがどこで実行されますか?パケットの到着と戦略ロジックを分けるキュー ホップの数は何ですか?パーサーは必要以上に多くのメモリを操作していませんか?ゲートウェイはコア間で移行しますか?無害であると思われるロギングまたは正規化のステップにより、レイテンシ分布の裾が広がりますか?これらは装飾的な質問ではありません。それらが作品なのです。

C++ は、エンジニアがこれらの詳細に直接直面できるため、この作業にとって自然な場所であり続けます。この言語は、システム全体に 1 つの割り当てモデル、1 つのキュー ストーリー、1 つの所有権ストーリー、または 1 つのランタイム スケジューラを強制しません。その自由は不注意なチームの手にかかると危険ですが、HFT はその自由を規律正しく使用することで真の優位性を生み出す場所の 1 つです。成熟した取引組織は、機械に適切に要求することを望んでいません。彼らは、マシンが何をするように指示されているのか、そしてコストがどこに隠れているのかを正確に知りたいと考えています。

人々が認める以上に重要なエコシステムに関する議論もあります。 HFT は言語、ツール、エクスペリエンスの問題です。 C++ には、成熟したコンパイラー、プロファイラー、フレーム グラフ、ハードウェア カウンター ワークフロー、サニタイザー サポート、OS レベルの統合パターン、およびパフォーマンスが重要な隣接業界からの長い継承が付属しています。 AI アシスタントは、同じパブリック継承からますます恩恵を受けています。エンジニアがパーサーの改善、キューの強化、またはネイティブ ホット パスでのプロファイリング出力の解釈について支援を求める場合、C++ に関する歴史的な密度は依然として重大な利点となります。

マーケットデータイベントが実際に経験すること

1 つの市場データ イベントを、マシン内を移動する物理的な負担としてイメージすると役立ちます。パケットが到着します。それは、ネットワーク スタックまたはフィード ハンドラーから受信され、解析され、何らかの内部表現にマッピングされ、1 つ以上のブック構造に適用され、戦略ロジックによって観察され、リスク チェックによってフィルタリングされ、場合によってはアウトバウンド注文またはキャンセルに変換される必要があります。すべてが順調であれば、この連鎖は瞬時に感じられます。アーキテクチャが不注意であると、パケットは各ステップで重みを取得します。

ここに 1 つの追加の割り当て、そこに 1 つの共有キュー、必要以上にコピーする正規化パス、教科書的な意味では洗練されているが記憶に残っていない本の構造、安全のみを目的としたロギング パス、間違った瞬間に移行するスレッド。これらのコストはどれも単独では神話のように聞こえません。それらの危険は蓄積と反復にあります。 HFT システムは楽観主義を罰するため、エンジニアはこの累積的な考え方を学びます。イベントごとの非効率はわずかであっても、市場活動、戦略の頻度、予測可能な反応時間のビジネス上の重要性が加わると、非効率は大きくなります。

これは、トレーディングにおけるホット パスが 1 つの機能だけであることはめったにない理由でもあります。それはエコロジーです。市場データ、状態管理、スケジューリング、シリアル化、リスク、送信はすべて相互作用します。調整とレイアウトをずさんなままにして、最も魅力的なループだけを最適化するエンジニアは、断片的には十分にベンチマークを行うシステムを作成することがよくありますが、重要な唯一の場所、つまり完全なパスでは期待外れになります。

決定的なレイテンシはアーキテクチャ上の規律である

低レイテンシーというフレーズは、あたかも関数の特性を説明するかのように使用されることがよくあります。 HFT では、低遅延はアーキテクチャの特性です。それはシステム全体がどのように形作られているかから現れます。ホットデータはホットのままである必要があります。メモリの所有権は明らかである必要があります。スレッドは放っておくのではなく、意図的に配置する必要があります。共有された可変状態は疑いを持って扱う必要があります。キューは必要な場合にのみ存在する必要があります。可観測性は、システムが独自の診断に溺れることなく検査可能な状態を維持できる程度に低コストである必要があります。

マシンは意図ではなくメモリを介して動作するため、データ レイアウトは重要です。連続したレイアウト、コンパクトな本の表現、プログラマーの感情ではなくアクセス パターンを反映した構造は、再利用可能に見えながらホットな状態があちこちに散在する賢い抽象化よりも価値があります。ホット パス上の動的メモリはジッター、競合、および残りのランタイムとの予期せぬ相互作用を引き起こす可能性があるため、割り当ての規律が重要です。 HFT では、ジッターのほうが屈辱的な問題となることがよくあります。

スレッド化も同様に真剣に取り組む必要があります。スレッドが増えても、自動的にパフォーマンスが向上するわけではありません。場合によっては、より多くの調整、より多くのキャッシュ移動、より多くのアフィニティミス、およびオペレーティングシステムが非自発的な共同作成者となる場所が増えることを意味します。成熟した取引システムは、スレッドを意図的に固定し、必要に応じて NUMA 境界を尊重し、共有される決定の数をアーキテクチャが許す限り低く保ちます。これではコードがおしゃれに感じられません。これにより動作がより安定し、通常ははるかに価値があります。

ネットワーキング、解析、およびブックのメンテナンス

トレーディングにおけるネットワーク化の道は、抽象化が最もうそをつきたくなる場所であるため、それ自体が尊重されるべきものです。バイナリ フィードは状態変化のストリームであり、忠実かつ迅速に解釈する必要があります。パーサーが高速であればあるほど、下流で混乱が生じる余地は少なくなります。実行する割り当てと分岐が少なくなるほど、マシンが何に支払っているのかを理解しやすくなります。フィード処理コードが厳格に見えることが多いのは、まさにこの理由からです。市場はどのようなエレガンス形態が報われないのか、苦しみを経て学んできたのだ。

オーダーブックのメンテナンスも同様の性質を持っています。書籍は、負荷がかかっている状態でも、更新、クエリ、再生、推論が可能になると価値が生まれます。ここでは、部外者が予想するよりもリプレイ可能性が重要です。 HFT チームは、実際のトラフィックを再生し、リビジョン間で戦略の動作を比較し、システムが遅くなったり安定性が低下した場所を診断したりすることで、膨大な量のことを学びます。再生または検査するのが難しい書籍表現は、狭いテストでは高速に見えても、操作的には弱い可能性があります。トレーディングでは、速くて診断しやすいものは、速くて神秘的なものに勝ちます。

これは C++ が特に適している部分です。これにより、同じコードベースが流暢に対話して、パーサー、メモリを意識したデータ構造、プロファイリング ツール、および低レベルのオペレーティング システムの動作にフィードを与えることができます。他の言語も取引システムに参加でき、多くの言語が参加していますが、問題のサブシステムがホット パス自体である場合でも、C++ は制御とエコシステム サポートの最良の組み合わせの 1 つを提供します。

リスク、リプレイ、運用の成熟度

HFT をガバナンスを取り除いた純粋なスピードとして想像するのは間違いです。世界最速のパスであっても、間違った注文を送信したり、状態を回復できなかったり、不安定な市場イベントの後に説明不能になったりする可能性がある場合は役に立ちません。したがって、優れた取引システムでは、リスクチェックが明確に行われ、障害処理がリハーサルされ、日常のエンジニアリング業務に近いインフラストラクチャが再現されます。これらは官僚的な付属品ではありません。それらは競争力の一部です。

健全な HFT コードベースは通常、この成熟度を反映しています。可観測性がないのではなく、安価な可観測性が含まれています。チームは、リプレイできないものは自信を持って改善できないことを知っているため、リプレイ ツールが含まれています。これには、有用な場合に厳選されたマイクロカーネルを含む、パス全体を調べるベンチマークとプロファイラーが含まれています。デプロイメントの一貫性、コンパイラ設定、アフィニティ戦略、およびマシン構成を第一級のエンジニアリング上の懸念事項として扱います。言い換えれば、最良の取引システムとは、規律ある技術環境です。

これが、安定性が生の賢さを上回ることが多い理由の 1 つです。ラボのベンチマークのわずかな改善は、テールが理解され、フィード処理が説明可能で、戦略の動作が事後に再構築できる再現可能なシステムよりも価値がありません。 HFT に参入するエンジニアは、英雄的な行為を期待することがあります。成熟したチームが代わりによく実践するのは、ある種の冷静な厳しさです。彼らは驚きを取り除きます。市場はすでにそれらを十分に提供しています。

一般的な通説は廃止されるに値する

いくつかの神話はエンジニアに媚びるために生き残っています。 HFT のパフォーマンスは、主に手書きのアセンブリまたは難解なマイクロ最適化に関するものである、という人もいます。実際には、最も有意義な成果は、建築、測定、そして通常の無駄の繰り返しの除去から得られます。ロックのない構造は自動的に優れているという人もいます。時にはそれらがまさに正しいこともあります。場合によっては、より単純な設計のほうがより適切に動作するはずの場所に、複雑さとメモリ順序のコストがインポートされることがあります。 3 番目は、より多くのスレッドが常に役立つと言っています。低遅延システムでは、余分な同時実行により、スループットが向上するよりも早く予測可能性が低下する可能性があります。

HFT での C++ の継続的な使用は、ほとんどが歴史的な慣性によるものに違いないという現代の通説もあります。確かに歴史は重要ですが、システムがお金と時間に対して継続的に測定される分野では、惰性だけでは生き残れません。 C++ が残っているのは、言語、そのツール、およびその周囲のエンジニアリング文化が、決定論的な低遅延設計の現実と依然としてよく一致していることがチームによって発見され続けているためです。別の言語が最も人気のある取引経路で一貫してより良い結果を生み出していれば、HFT 企業は気づくでしょう。彼らは注意を払うのに十分な強いインセンティブを持っています。

このドメインがまだ研究する価値がある理由

商社で働いたことのないエンジニアにとっても、HFT はシステムの真実を回避するのを困難にするため、貴重な教師であり続けます。コードと結果の間に密接な関係が強制されます。データのレイアウトは装飾ではないこと、キューは自由ではないこと、平均レイテンシは嘘をつき得ること、再生は理解の一形態であること、そしてアーキテクチャがしばしば最も重要な最適化であることを教えます。これらの教訓は取引以外にも応用できます。

C++ は、エンジニアが難しいバランスを保つことができるため、引き続きそのレッスンの中心にあります。それは、実質的なシステムを構築するのに十分な表現力を持ち、コストを正直に明らかにするのに十分な低レベルであり、ツールと実際の実践の膨大な継承を伴うのに十分古いものです。この組み合わせは、当社の最も要求の厳しいパフォーマンス領域の 1 つにおいて依然として重要です。

HFT に動機を与えるものがあるとすれば、それはスピードそのものの神話ではありません。これは、ソフトウェアはプレッシャーの下でも正確で、測定可能で、威厳のあるものにできるということを思い出させてくれます。 C++ は、依然としてその分野が最も流暢に話されている言語の 1 つです。

ハンズオン ラボ: フィードから書籍への小さなリプレイを構築する

ミニチュア HFT スタイルのおもちゃを作って終わりにしましょう。それはお金にはなりません。それは素晴らしいですね。お金を稼ぐことを約束するコード例のほとんどは、最悪の形で教育的です。

それが行うことはより便利です。一連の市場更新を小さなメモリ内のブック表現に再生し、最良の買値と売値をレポートします。

main.cpp

#include <algorithm>
#include <chrono>
#include <cstdint>
#include <iostream>
#include <limits>
#include <string>
#include <vector>

enum class Side { Bid, Ask };

struct Update {
    Side side;
    int price;
    int qty;
};

struct Book {
    std::vector<Update> bids;
    std::vector<Update> asks;

    void apply(const Update& u) {
        auto& side = (u.side == Side::Bid) ? bids : asks;
        auto it = std::find_if(side.begin(), side.end(), [&](const Update& x) {
            return x.price == u.price;
        });

        if (u.qty == 0) {
            if (it != side.end()) side.erase(it);
            return;
        }

        if (it == side.end()) {
            side.push_back(u);
        } else {
            it->qty = u.qty;
        }
    }

    int best_bid() const {
        int best = 0;
        for (const auto& b : bids) best = std::max(best, b.price);
        return best;
    }

    int best_ask() const {
        int best = std::numeric_limits<int>::max();
        for (const auto& a : asks) best = std::min(best, a.price);
        return best;
    }
};

int main() {
    std::vector<Update> replay{
        {Side::Bid, 10010, 5},
        {Side::Bid, 10020, 3},
        {Side::Ask, 10040, 4},
        {Side::Ask, 10035, 8},
        {Side::Bid, 10020, 0},
        {Side::Ask, 10035, 6},
        {Side::Bid, 10025, 7}
    };

    Book book;
    const auto t0 = std::chrono::steady_clock::now();

    for (const auto& u : replay) {
        book.apply(u);
    }

    const auto t1 = std::chrono::steady_clock::now();
    const auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(t1 - t0).count();

    std::cout << "best_bid=" << book.best_bid() << "\n";
    std::cout << "best_ask=" << book.best_ask() << "\n";
    std::cout << "replay_ns=" << ns << "\n";
}

建てる

Linux または macOS の場合:

g++ -O2 -std=c++20 -o tiny_book main.cpp
./tiny_book

Windows の場合:

cl /O2 /std:c++20 main.cpp
.\main.exe

これが教えてくれること

この小さな再生プログラムでも、すぐに本当の HFT 疑問が生じます。

• 価格レベルはベクトル、マップ、配列、またはカスタム ラダーに存在する必要がありますか?
• リプレイが 7 回の更新から 700 万回に増加するとどうなるでしょうか?
• 状態の更新とレポートにはどのくらいの時間がかかりますか?
• 構造が動的に拡張される場合、割り当てはどこに表示されますか?

例は小さいですが、質問は決して小さいものではありません。

愛好家向けのテストタスク

1. apply の線形検索を、より適切に拡張し、再生時間を比較する構造に置き換えます。
2. 100 万件の合成更新を生成し、単純な構造がどのように劣化するかを測定します。
3. フィードの再生と書籍の更新の間に SPSC キューを備えたプロデューサー スレッドとコンシューマー スレッドを 1 つ追加し、安定性と複雑さを比較します。
4. リプレイ スレッドを Linux のコアに固定し、実行ごとの差異を比較します。
5. 意図的にノイズの多いロギング パスを追加し、「無害な」デバッグの決定がレイテンシの測定にどれだけ早く影響を与えるかを観察します。

これらの練習は地味ですが、だからこそ良いのです。本当の低遅延エンジニアリングは、慎重に選択されたか、後で後悔する多くの質素な構造から構築されています。

まとめ

C++ は高頻度取引の中心であり続けます。HFT は、市場データから注文送信までのパス全体にわたって決定論的な低遅延システムを構築し、それらのシステムをプレッシャーの下でも診断できる程度に理解しやすいものに保つことを目的としているためです。その作業は、規律あるデータ レイアウト、抑制された割り当て、慎重なスレッド化、正直なプロファイリング、再生可能な検証、および速度と同じくらい安定性を重視する文化に依存します。

これが、C++ がその地位を維持し続ける理由です。これにより、エンジニアは、この分野で今でも恩恵を受けている制御レベル、ツールの奥深さ、歴史的な実践を得ることができます。他の言語も取引スタックに貢献する可能性があり、実際に貢献していますが、問題がホット パス自体にある場合、C++ は依然としてパフォーマンスをスローガンから再現可能なエンジニアリング特性に変えるための私たちが知っている最も強力な方法の 1 つです。

参考文献

1. NASDAQ TotalView-ITCH 仕様: ITCH
2. DPDK ドキュメント: https://doc.dpdk.org/guides/
3. Linux ソケット API マニュアル ページ: Linux
4. Linux タイムスタンプに関するドキュメント: Linux
5. Linux PTP ハードウェア クロック インフラストラクチャ: Linux
6. Linux Linux マニュアル ページ: https://man7.org/linux/man-pages/man1/perf.1.html
7. Brendan Gregg による炎グラフ: https://www.brendangregg.com/flamegraphs.html
8. インテル VTune プロファイラーのドキュメント: https://www.intel.com/content/www/us/en/docs/vtune-profiler/overview.html

   システムにすでに圧力がかかっている場合はどのように見えるか

高頻度取引における C++ は、チームが静かな四半期を望んでいたまさにその瞬間に緊急性が高まる傾向があります。機能がすでに顧客の前に提供されているか、プラットフォームがすでに内部依存性を持っており、システムはその洗練された理論と実行時の動作が丁寧に別々の生活を送っていることを明らかにするために、その特定の週を選択しました。これが、多くの本格的なエンジニアリング作業が和解から始まる理由です。チームは、システムが行うと信じていることと、負荷や変更が加えられた状態、そして誰もが少し創造的になり、賢さが少し低下するような期限の下でシステムが実際に行うことを調和させる必要があります。

低遅延システムでは、通常、最も重要なケースは、市場データの取り込み、決定論的な予算に基づく注文ルーティング、回帰制御のためのワークフローのリプレイとプロファイリングです。このような状況は、技術的、予算、信頼、ロードマップ、そして場合によっては評判にも影響を及ぼします。技術的な問題は、複数のチームがそれに依存した瞬間に政治的に大きくなり、なぜそれが未だに壁の中でアライグマのように行動するのか誰も完全に説明できません。夜はうるさく、場所を特定するのは難しく、無視すると費用がかかります。

そのため、動作圧力と配送の現実というレンズを通して問題を読むことをお勧めします。設計は理論的には美しくても、運用的には破滅的なものになる可能性があります。別の設計は、ほとんど退屈なものであっても、測定可能で修理可能であり、トレードオフについて誠実であるため、製品を何年も使い続けることができます。真剣なエンジニアは、2 番目のカテゴリーを好むようになります。これにより、壮大なスピーチが減りますが、誰もが受動態で話し、誰が近道を承認したかを誰も覚えていないような緊急の振り返りも減ります。

常に老化を続ける習慣

最初の永続的な方法は、1 つの代表的なパスを常に測定し続けることです。チームは多くの場合、曖昧なテレメトリを収集しすぎたり、意思決定品質のシグナルが少なすぎたりします。本当に重要な道を選び、それを繰り返し測定し、議論が装飾的なストーリーテリングに流れないようにしてください。高頻度取引における C++ の回避策では、通常、テール レイテンシー、キュー規律、キャッシュの局所性、および運用の再現性が有用な対策となります。それらが可視化されると、残りの決定はより人間的になり、神秘的ではなくなります。

2 番目の永続的な習慣は、証拠と約束を分離することです。エンジニアは、システムがその結論を得る前に、ある方向性が正しいと言うよう圧力をかけられることがよくあります。そのプレッシャーに抵抗してください。特にトピックが顧客やお金に近い場合は、最初に狭い証明を作成します。検証されていない大きな野心よりも、検証された小さな改善の方が商業的価値があります。これは、四半期末のレビューで仮説が期限に変わり、組織全体が楽観主義をスケジュール作成の成果物のように扱うようになるまでは、当然のことのように思えます。

3 番目の永続的な習慣は、所有者の言語で推奨事項を書くことです。 「パフォーマンスを向上させる」または「境界を強化する」という文章は、感情的には心地よいものですが、運用上は役に立ちません。月曜日の朝に実際に生き残るのは、誰が何を、どの順序で、どのロールバック条件で変更するかを述べた段落です。多くのテクニカル ライティングが失敗するのはここです。スケジュール可能であることよりも、先進的に聞こえることを望んでいます。

時間を節約する反例

最も一般的な反例の 1 つは次のようなものです。チームはローカルで大きな成功を収め、システムが理解されたと想定し、測定規律をアップグレードすることなく、アイデアをさらに要求の厳しい環境に拡張します。これは工学的に言えば、ホテルのプールで泳ぎ方を覚えてから、海の天気について自信を持って TED トークをするのと同じことです。水ではなくなるまでは水です。

もう 1 つの反例は、ツールのインフレです。新しいプロファイラー、新しいランタイム、新しいダッシュボード、新しいエージェント、新しい自動化レイヤー、古いラッパーとの調和を約束する新しいラッパー。これらはどれも本質的に悪いことではありません。問題は、誰も明確に名指ししていない境界線の補償を求められたときに何が起こるかということだ。その後、システムはさらに装備され、より印象的になり、場合によってはより理解できるようになります。購入者はこれをすぐに感じます。そのような表現がなくても、積み重ねが決断の代償として高価なものになったことを彼らは嗅ぎ分けることができます。

3 番目の反例は、人間によるレビューを自動化の失敗として扱うことです。実際のシステムでは、多くの場合、人間によるレビューが自動化を商業的に受け入れられる状態に保つための制御となります。成熟したチームは、どこを積極的に自動化するか、どこで承認や解釈を可視化するかを知っています。未熟なチームは、スライド内で「すべて」が効率的に聞こえるため、マシンにすべてを実行させたいと考えます。その後、最初の重大なインシデントが発生し、突然手動レビューが変換体験の誠実さによって再発見されます。

弊社が推奨する配信パターン

仕事が順調に進んでいる場合、最初の成果物は、チームに輪廻議論をやめるのに十分な技術的な読み取りを提供することでストレスを軽減するはずです。その後、次の制限付き実装で 1 つの重要なパスが改善され、再テストによってエンジニアリングとリーダーの両方が方向性を理解できるようになります。その順序は、正確なツールの選択よりも重要です。それは、技術スキルを前進に変えるものだからです。

実際的な観点から言えば、最初のサイクルは狭いことをお勧めします。つまり、アーティファクトを収集し、1 つの厳密な診断を作成し、1 つの限定された変更を出荷し、実際のパスを再テストし、次の決定を平易な言葉で書くというものです。分かりやすい言葉が重要です。買い手が明確さを後悔することはほとんどありません。購入者は、領収書が届く前に感動したことを後悔することがよくあります。

ここでもトーンが重要になります。強力な技術的な作業は、以前にプロダクションに対応したように聞こえるはずです。穏やかで、正確で、誇大宣伝に養われるというよりは、それを少し楽しんでいます。そのトーンは操作信号を伝えます。これは、チームがシステム エンジニアリングの古い真実を理解していることを示しています。マシンは高速であり、ロードマップは脆弱であり、詩的であり続けることを許可されていたすべての仮定に対して、遅かれ早かれ法案が到着します。

これが準備完了であると判断する前に使用するチェックリスト

低遅延システムでは、準備は気分ではありません。それは結果を伴うチェックリストです。より広範な展開に向けて高頻度取引における回避策 C++ を呼び出す前に、可能な限り最善の方法でいくつかのことを退屈なものにしておきたいと考えています。代表的な負荷の下で予測どおりに動作する 1 つのパスが必要です。矛盾しない 1 セットの測定値が必要です。私たちはチームに、境界線がどこにあるのか、そしてそれを壊すことが何を意味するのかを知ってもらいたいと考えています。そして、実装室の外にいる誰かがそこから正しい判断を下せるように、作業の出力が十分に明確であることを望んでいます。

そのチェックリストは通常​​、テール レイテンシー、キュー規律、キャッシュの局所性、および操作の再現性について触れます。数値が正しい方向に進んでいるにもかかわらず、チームが即興でシステムを説明できない場合、作業の準備ができていません。建築が印象的に聞こえても、現場からのささやかな反例に耐えられない場合、その作品はまだ準備ができていません。実装は存在するが、ロールバックの話がタイムスタンプ付きの祈りのように聞こえる場合は、作業の準備ができていません。これらはいずれも哲学的な反論ではありません。それらは単に、高価なサプライズが登場する傾向にある形式にすぎません。

これは、チームが実際の問題を解決しているのか、それともその問題に近い能力を単に練習しているだけなのかを発見する場所でもあります。非常に多くの技術的取り組みは、誰かが再現性、生産の証拠、または予算に影響を与える決定を要求するまでは、成功したように感じられます。その瞬間、弱い作品はぼやけてしまい、強い作品は妙に地味になってしまいます。プレーンが良いです。プレーンとは通常、システムがカリスマ性に依存するのをやめたことを意味します。

結果について話すことを推奨する方法

最終的な説明は、リーダーシップ会議に耐えられるほど簡潔であり、エンジニアリングレビューに耐えられるほど具体的である必要があります。それは思っているよりも難しいことです。過度に専門的な言葉は順序を隠します。過度に単純化された言葉はリスクを隠します。適切な中間点は、勝ち誇ったような感じではなく、穏やかに聞こえる方法で、道筋、証拠、限界のある変化、そして次に推奨されるステップを説明することです。

このような構造を推奨します。まず、どのパスが評価されたのか、そしてそれがなぜ重要なのかを述べます。次に、その道に関して何が間違っていたのか、何が不確実だったかを述べます。 3 番目に、何が変更、測定、または検証されたかを述べます。 4番目に、何が未解決のままなのか、そして次の投資で何が買えるのかを述べます。この構造が機能するのは、エンジニアリングと購買行動の両方を尊重しているからです。エンジニアは詳細を求めています。購入者は順序付けを望んでいます。サプライズを楽しんでいるふりをしている人も含めて、誰もがサプライズを減らしたいと思っています。

このように話すことの隠れた利点は文化的なものです。技術的な作業を明確に説明するチームは、通常、それをより明確に実行します。彼らは曖昧さを洗練されたものとして扱うのをやめます。専門用語では印象を与えることが難しくなり、難しいシステムでは信頼されやすくなります。これは、エンジニアリングの成熟度の最も過小評価されている形態の 1 つです。

私たちがまだ偽造を拒否したいもの

システムが改善された後でも、成熟したチームは低遅延システムにおいて不確実性を正直に保ちます。弱い測定にはより明確な証拠が必要であり、厳しい境界には平易な言葉が必要で、より穏やかなデモには実際の運用準備が必要です。ある程度の不確実性は軽減する必要があります。正直に名前を付けなければならない人もいます。この 2 つの仕事を混同すると、立派なプロジェクトが高価なたとえになってしまいます。

同じルールが、高頻度取引における C++ に関する決定にも適用されます。チームに再現可能なベンチマーク、信頼できるロールバック パス、または重要なインターフェイスの明確な所有者が依然として不足している場合、最も役立つ出力は、より大きな約束ではなく、より明確なノーまたはより狭い次のステップである可能性があります。この規律により、技術的な作業が改善を目的とした現実と一致した状態に保たれます。

このように作業すると、不思議な安心感があります。システムが楽観的なストーリーテリングに依存しなくなると、たとえ作業が困難なままであっても、エンジニアリングに関する会話はよりシンプルになります。そして生産現場では、それは多くの場合、ささやかな恵みとして数えられます。

高頻度取引システムに関する補足事項

HFT では、圧力下でも検査下でも同様に動作する設計が尊敬を集めます。これはマーケティング部門が望むよりもまれであり、スライド内のエレガントな疑似数学よりもはるかに価値があります。決定的なレイテンシはスローガンではありません。これは、何千もの退屈な選択が正しく行われ、ハードウェア、コンパイラ、カーネル、またはワークロードが何らかの小さく侮辱的な方法で変更されたときに再確認された結果です。

また、リプレイとトレード後の調査をスタックの第一級住民として扱うことをお勧めします。それ自体を説明できない高速システムは、高価な文化的問題になります。トレーダーはスピードを求めます。エンジニアは真実を求めています。コンプライアンスには記録が必要です。最高の C++ HFT システムは、同じ会話であるかのように振る舞うことなく、3 つすべてを尊重します。このバランスが、C++ ここで依然として非常に重要な理由の 1 つです。バランスにより、チームが動作を正確に制御できると同時に、周囲の規律に対して十分な余地が残され、スピードが信じられるものになります。

実際の技術レビューからのフィールドノート

C++ システムの配信では、デモが実際の配信、実際のユーザー、実際の運用コストを満たしたときに、作業が本格化します。それは、きちんとしたアイデアがシステムのように動作し始める瞬間であり、システムは有名なドライなユーモアのセンスを持っています。彼らはキックオフデッキがどれほどエレガントに見えるかなど気にしません。彼らは、境界、障害モード、ロールアウト パス、そしてスタックに関する新しい神話をでっち上げずに次のステップを説明できる人がいるかどうかを重視しています。

C++ in High-Frequency Trading: From Market Data to Deterministic Latency の場合、実際的な問題は、ロードマップ、プラットフォーム、またはセキュリティ レビューにすでにプレッシャーを感じている購入者に対して、より強力な配信パスを作成できるかどうかです。その購入者は、霧の中に磨き上げられた講義を必要としません。彼らは使用できる技術的な読み取りを必要としています。

最初に検査するもの

まず、ネイティブ推論、プロファイリング、HFT パス、DEX システム、および C++/Rust モダナイゼーションの選択肢という 1 つの代表的なパスから始めます。その道は測定するには十分に狭く、真実を明らかにするには十分に広くなければなりません。最初のパスでは、割り当て動作、p99 レイテンシ、プロファイル証拠、ABI 摩擦、および信頼性の解放をキャプチャする必要があります。これらの信号が利用できない場合、プロジェクトは依然として白衣を着た意見がほとんどであり、意見はそれ自体を戦略として宣伝してきた長い歴史があります。

最初の有用な成果物は、ベンチマーク、プロファイリング証拠、および範囲を絞った実装計画を含むネイティブ システムの読み取りです。計画会議で誰もが期待したとおりに動作するのではなく、システムが動作するとおりに示す必要があります。トレース、リプレイ、小さなベンチマーク、ポリシー マトリックス、パーサー フィクスチャ、または反復可能なテストは、多くの場合、別の抽象的なアーキテクチャの議論よりも早くストーリーを伝えます。良い工芸品は驚くほど失礼だ。彼らは希望的観測を中断します。

時間を節約する反例

高くつく間違いは、最初の有用な証明よりも大きな解決策で応答することです。チームはリスクや遅延を認識すると、すぐに新しいプラットフォーム、書き換え、全面的なリファクタリング、またはヨガをしているような名前の調達しやすいダッシュボードに手を出します。場合によっては、そのスケールが正当化されることもあります。多くの場合、これは測定を延期する方法です。

より良い動きはより小さく、より鋭いです。境界に名前を付けます。証拠を捕らえます。重要なことを 1 つ変更します。同じパスを再テストします。次に、次の投資がより大きな投資に値するかどうかを決定します。このリズムは変革プログラムほど劇的ではありませんが、予算、リリース カレンダー、および制作上のインシデントに影響されても存続する傾向があります。

弊社が推奨する配送パターン

最も信頼性の高いパターンには 4 つのステップがあります。まず、代表的な成果物を収集します。次に、これらのアーティファクトを 1 つの難しい技術診断に変換します。 3 番目に、1 つの限定された変更またはプロトタイプを出荷します。 4 番目に、同じ測定フレームで再テストし、次の決定をわかりやすい言葉で文書化します。このクラスの作業では、CMake フィクスチャ、プロファイリング ハーネス、小さなネイティブ再現、およびコンパイラ/ランタイム ノートの方が、一般的な方向性に関する別の会議よりも価値があるのが通常です。

分かりやすい言葉が重要です。購入者は出力を読んで、何が変化したのか、何が依然としてリスクが残っているのか、何を待てばよいのか、次のステップで何を購入するのかを理解できる必要があります。推奨事項をスケジュールしたり、テストしたり、所有者に割り当てることができない場合でも、それは装飾的すぎます。装飾的なテクニカルライティングは楽しいものですが、制作システムがその心地よさをもたらすとは知られていません。

結果が役に立ったかどうかを判断する方法

C++ in High-Frequency Trading: From Market Data to Deterministic Latency の場合、結果により配信速度、システムの信頼性、商用化の準備の 3 つのうち少なくとも 1 つが改善されるはずです。これらのどれも改善されない場合、チームは何かを学んだ可能性がありますが、購入者はまだ有用な結果を受け取っていません。その区別が重要です。学ぶことは崇高なことです。有料のエンゲージメントもシステムを動かすはずです。

最も強力な成果は、より狭いロードマップ、危険なパスの自動化の拒否、モデルの境界の改善、よりクリーンなネイティブ統合、書き換えがまだ必要ではないという慎重な証拠、またはリーダーが実際に資金を提供できる短い修復リストなどです。真剣なエンジニアリングとは、より良い意思決定の連続であり、ツールの仮装コンテストではありません。

SToFU はそれにどうアプローチするか

SToFU は、これを最初に配信の問題として扱い、次にテクノロジーの問題として扱います。私たちは関連するエンジニアリングの深さをもたらしますが、その取り組みは、経路、境界、リスク、測定、そして行う価値のある次の変更などの証拠に基づいて行われます。重要なのは、ハードワークを簡単に思わせないことです。重要なのは、次の重大な行動を実行できるほど明確にすることです。

それは、購入者が通常最も重視する部分です。彼らはどこでも意見を採用できます。彼らに必要なのは、システムを検査し、実際の制約に名前を付け、適切なスライスを構築または検証し、通話終了後の混乱を軽減する成果物を残すことができるチームです。騒がしい市場では、明確さはソフトスキルではありません。それはインフラです。