【CJ 応用編 続編 08/30 · 通算第36回】
利益の源泉を見極める前にマイクロ秒単位の最適化を始めるのは、たいてい、まだ存在しない優位性を最適化しているにすぎません。
Pythonは、データやシグナル、コストモデルをすばやく検証するのに適しています。戦略が実際に高い並行処理負荷や遅延のテール、実行のブロッキングに直面して初めて、言語やランタイムがボトルネックになっているかを調べる必要があります。Rustは、より厳格な型制約と、より制御しやすい実行性能を提供できます。しかし、誤ったエントリー判断を自動的に修正してくれるわけでも、一方向に動く相場をなくしてくれるわけでもありません。
開発の順序は、まず戦略ロジックを検証し、次に実際のボトルネックを測定してから、適切な実装方法を選ぶべきです。あらゆる問題を「速度が足りない」と片づけると、より難しく、しかしより重要な問いを避けてしまいがちです。データは正しいか、リスクを制御できているか、失敗したときに停止できるか。
テストでは、平均速度と最も遅いときの速度も区別する必要があります。普段は速くても、混雑時に長時間ブロックされるなら、安定しているものの少し遅いシステムより管理が難しいかもしれません。書き換えるかどうかは、言語名がもたらす専門的な印象ではなく、測定結果と障害時の挙動によって判断すべきです。
速さは目的ではありません。適切なところで速くできてこそ、エンジニアリングの価値があります。
次回:市場が休場なのに、なぜ先物価格は動いているのか?
#量化工程 #Rust