Warum liefern Sie einen Build und nicht den Quellcode?
Die Optimierungsmethode ist unser Know-how. Deshalb liefern wir eine statische oder dynamische Bibliothek mit C-Header und einem schlanken Rust-Wrapper. Die Einbindung erfordert eine Zeile in Cargo.toml. Die Korrektheit wird durch Äquivalenztests belegt, die Herkunft durch Signatur und Provenance.
Was passiert, wenn ich meinen Code ändere?
Rust-Integration und Rückkehr zum Original werden für die Bibliothek vereinbart. Ändert sich der optimierte Kern, sind neue Version und Messung nötig; CI benötigt einen gesonderten angenommenen Auftrag. Quellcode-Escrow kann vor Zahlung über eine qualifizierte Escrow-Box gemäß Rider angefragt werden.
Muss ich Ihnen meine Strategie schicken?
Für eine vorläufige Spanne nicht: Das kostenlose Harness erzeugt ein Messpaket ohne Quellcode. Für den Build brauchen wir den Code, der in der heißen Schleife läuft, und nur ihn, meist den Simulator, die Indikatoren und den Portfoliozustand. Er fällt unter die NDA, wird nicht für Arbeiten für andere Kunden verwendet und fristgerecht gelöscht. Ein Teil Ihrer Daten kann bis zur Abnahme bei Ihnen bleiben: Verdeckte Eingaben werden verschlüsselt gesendet, den Schlüssel übergeben Sie, sobald der Build fertig ist.
Warum nicht einfach mehr Kerne?
Beides. Unabhängige Läufe einer Parametersuche verteilen sich gut auf Kerne, und unser Build macht jeden dieser Läufe auf jedem zusätzlichen Kern schneller. Mehr Kerne helfen nicht bei einer einzelnen Simulation entlang einer Historie, in der jeder Schritt vom vorigen abhängt, und genau diesen Code beschleunigen wir. Weniger Kernstunden für dieselbe Suche bedeuten außerdem eine kleinere Cloud-Rechnung.
Was, wenn die zugesagte Beschleunigung nicht eintritt?
Bei Stufe 1 bezahlen Sie ein bereits gemessenes Ergebnis, dieser Fall kann also nicht eintreten. Bei Stufe 2 nennen wir ein garantiertes Minimum; wird es nicht erreicht, schreiben wir den Betrag gemäß der Tabelle im Vertrag Ihrem Guthaben gut, und eingezahltes Guthaben zahlen wir auf Anfrage aus.
Wie werden Zeilen gezählt?
Wir bauen Ihren Code mit -C instrument-coverage im selben Profil und für dieselbe Plattform wie im Messpass und führen den Benchmark des Messpasses auf den offenen Eingaben aus. Gezählt werden die Rust-Zeilen, die laut llvm-cov mindestens einmal ausgeführt wurden. Nicht gezählt werden Leerzeilen und Kommentare, nie ausgeführter Code, Tests und Benchmark-Gerüst, Fremdabhängigkeiten außerhalb des Auftragsumfangs sowie Assembler; eine generische Funktion zählt einmal. Diese Zahl wird vor der Zahlung in den Messpass eingetragen. Daten zählen nicht, nur Ihr Code. Zur Orientierung: Beim Entpacken des Silesia-Korpus mit bzip2-rs werden 598 Zeilen seines Codes ausgeführt, beim Kodieren von fünf Xiph-Clips mit rav1e 12.809 von 55.419 Zeilen.
Welche Plattformen werden unterstützt?
Öffentliche Demos benötigen Linux x86-64 mit AVX2/FMA. TA-Lib und vn.py wurden auf AMD Zen 3 und Zen 4 gemessen. CPU-Funktionen, Betriebssystem, ABI und Abnahmehardware werden je Auftrag festgelegt; Intel, ARM und andere Umgebungen brauchen eine eigene Prüfung.
Welcher Code lässt sich schlecht beschleunigen?
Decoder für Formate, für die es bereits seit Langem optimierte C-Bibliotheken gibt (LZ4, zstd, deflate): Diese haben wir bisher nicht übertroffen. Ausgereifte Codecs mit handgeschriebenem SIMD und Assembler (x264, x265), kryptografische Primitive wie SHA-256 und ChaCha20, die Verarbeitung zufälliger, nicht komprimierbarer Daten sowie sehr kurze Aufrufe, bei denen die gesamte Zeit auf Overhead entfällt. In solchen Fällen zeigt die kostenlose Einschätzung ehrlich einen geringen Gewinn, und Sie müssen nichts bezahlen.
Meine Taktzahlen weichen von Ihren ab. Warum?
Takte hängen vom CPU-Modell, von Taktfrequenz, Turbo, Speicher und Eingabedaten ab. Vertragszahlen werden auf dem Messstand nach dem Messpass erhoben. Das Harness liest dieselben Zähler, daher sollten Ihre Zahlen bei gleichem CPU-Modell und gleichen Einstellungen nahe an unseren liegen. Die Zahl der Instruktionen hängt viel weniger von der Maschine ab: Vergleichen Sie zuerst sie.
Wie sieht es mit Gleitkommaarithmetik aus?
Standardmäßig stimmen die Ausgaben Bit für Bit überein, mit einer begrenzten Ausnahme für NaN-Payloads aus Gleitkommaarithmetik, wo Rust unterschiedliche Payloads zulässt. Ausdrücklich bewahrte NaN-Kodierungen und alle anderen Ausgaben bleiben exakt, sofern Sie im Messpass nichts anderes vereinbaren. Der Messpass kann auch exakte NaN-Payloads verlangen. Jede andere vereinbarte Abweichung wird im Messpass festgelegt und durch Tests geprüft.
Stürzt der Build auf einem alten Server ab?
Prüfen Sie die CPU-Anforderungen jedes Pakets. Öffentliche Binärdateien können AVX2/FMA benötigen und laufen dann nicht auf älteren CPUs. Funktionen und ein möglicher Fallback bezahlter Builds werden im Messpass vereinbart; nicht jede Binärdatei besitzt einen Fallback.
Senkt das die Latenz meines Live-Handels?
Nur wenn das Profiling zeigt, dass die Berechnung der Engpass ist. Für einen Live-Pfad messen wir den ganzen Weg vom Marktereignis bis zur Order, etwa sein p99 auf Ihrem Server, nicht eine einzelne Funktion: Oft entfällt der Großteil der Zeit auf Netzwerk und Börse. Unsere stärksten Ergebnisse sind Batch-Berechnungen: Backtests, Training und Parametersuchen.
Arbeiten Sie mit C, C++ und Python?
Ja, als individuelle Aufträge. Für C und C++ liefern wir eine direkt austauschbare Bibliothek mit derselben ABI, sodass Ihre Programme und Python-Code, der die Bibliothek aufruft, unverändert funktionieren (siehe den Fall TA-Lib). Für Python-Code liefern wir ein natives Programm oder Modul mit derselben Ausgabe (siehe den Fall vn.py). Das ist Ingenieursarbeit der Stufe 2 mit individuellem Preis; die Selbstbedienung im Dashboard nimmt derzeit Rust-Crates an.