【CJ 进阶续篇 08/30 · 总第 36 篇】
Bevor man die Profitquelle überhaupt gemessen hat, fängt man schon an, Mikrosekunden zu optimieren—meist optimiert man dabei einen vermeintlichen Vorteil, der noch gar nicht existiert.
Python eignet sich, um Daten, Signale und Kostenmodelle schnell zu verifizieren; wenn eine Strategie dann jedoch wirklich mit hoher Parallelität, langen Latenz-Schwänzen und Ausführungsblockaden konfrontiert wird, ist es erst dann sinnvoll zu prüfen, ob Sprache oder Laufzeit zum Engpass werden.
Rust kann strengere Typ-Zusicherungen und besser kontrollierbare Laufzeit bieten, aber er behebt nicht automatisch fehlerhafte Logik beim Einstieg—und er lässt auch keinen Seitwärts-/Einseitmarkt einfach verschwinden.
Die Reihenfolge im Engineering sollte sein: erst die Logik der Strategie belegen, dann die realen Engpässe messen, und dann die passende Implementierung wählen. Wenn man alle Probleme auf „zu langsam“ reduziert, umgeht man leicht die schwierigeren, aber wichtigeren Fragen: Sind die Daten korrekt? Ist das Risiko beherrschbar? Kann man beim Scheitern rechtzeitig stoppen?
Auch beim Testen sollte man zuerst zwischen durchschnittlicher Geschwindigkeit und den langsamsten Zeitpunkten unterscheiden. Im Alltag ist es vielleicht schnell, aber wenn es bei Engpässen zu Blockaden über lange Zeit kommt, kann das schwerer zu managen sein als eine stabile, aber etwas langsamere Performance. Ob man neu schreibt, sollte durch Messresultate und das Fehlerbild entschieden werden—nicht durch das Fachurteil, das allein der Name einer Sprache mit sich bringt.
Schnell ist kein Selbstzweck. Nur dort schneller zu werden, wo es richtig ist, ist der wahre Engineering-Wert.
Nächster Beitrag: Der Markt ist geschlossen—warum bewegen sich die Kontraktpreise trotzdem weiter?
#量化工程 #Rust