Pourquoi livrez-vous un build et non le code source ?
La méthode d’optimisation est notre savoir-faire : nous livrons donc une bibliothèque statique ou dynamique avec un en-tête C et une fine surcouche Rust. L’intégration tient en une ligne dans Cargo.toml. L’exactitude est confirmée par les tests d’équivalence, l’origine par la signature et la provenance.
Que se passe-t-il si je modifie mon code ?
L’intégration Rust et le retour à l’original sont convenus pour la bibliothèque. Un cœur modifié demande une nouvelle version et une mesure ; CI exige une commande distincte acceptée. Le séquestre peut être demandé avant paiement via une boîte qualifiée selon l’avenant.
Dois-je vous envoyer ma stratégie ?
Pas pour une fourchette préliminaire : le harness gratuit produit un paquet de mesures sans code source. Pour le build, il nous faut le code qui s’exécute dans la boucle chaude, et lui seul : en général le simulateur, les indicateurs et l’état du portefeuille. Il est couvert par le NDA, ne sert pas aux travaux pour d’autres clients et est supprimé dans les délais prévus. Une partie de vos données peut rester chez vous jusqu’à la recette : les entrées cachées sont envoyées chiffrées, et vous fournissez la clé une fois le build prêt.
Pourquoi ne pas simplement ajouter des cœurs ?
Faites les deux. Les exécutions indépendantes d’un balayage se répartissent bien sur les cœurs, et notre build accélère chacune d’elles sur chaque cœur ajouté. Plus de cœurs n’aident pas une simulation unique le long d’un historique, où chaque pas dépend du précédent, et c’est précisément ce code que nous accélérons. Moins d’heures-cœur pour le même balayage, c’est aussi une facture cloud plus petite.
Et si l’accélération promise n’est pas au rendez-vous ?
Au niveau 1, vous payez un résultat déjà mesuré : ce cas ne peut donc pas se produire. Au niveau 2, nous annonçons un minimum garanti ; s’il n’est pas atteint, la somme est recréditée sur votre solde selon le barème du contrat, et les fonds versés présents sur le solde sont restitués sur demande.
Comment les lignes sont-elles comptées ?
Nous compilons votre code avec -C instrument-coverage dans le même profil et pour la même plateforme que dans le passeport, puis nous exécutons le benchmark du passeport sur les entrées ouvertes. Nous comptons les lignes Rust exécutées au moins une fois selon llvm-cov. Ne sont pas comptés : les lignes vides et les commentaires, le code jamais exécuté, les tests et l’outillage du benchmark, les dépendances tierces hors du périmètre des travaux, ainsi que l’assembleur ; une fonction générique compte une seule fois. Ce nombre est inscrit dans le passeport avant paiement. Les données ne comptent pas, seulement votre code. À titre indicatif : la décompression du corpus Silesia avec bzip2-rs exécute 598 lignes de son code, et l’encodage de cinq clips Xiph avec rav1e exécute 12 809 lignes sur 55 419.
Quelles plateformes sont prises en charge ?
Les démos publiques ciblent Linux x86-64 avec AVX2/FMA. TA-Lib et vn.py ont été mesurés sur AMD Zen 3 et Zen 4. Fonctions CPU, OS, ABI et matériel d’acceptation sont fixés par commande ; Intel, ARM et autres environnements nécessitent une évaluation propre.
Quel code s’accélère mal ?
Les décodeurs de formats qui disposent déjà de bibliothèques C optimisées de longue date (LZ4, zstd, deflate) : nous ne les avons pas encore battues. Les codecs matures avec SIMD et assembleur écrits à la main (x264, x265), les primitives cryptographiques comme SHA-256 et ChaCha20, le traitement de données aléatoires incompressibles et les appels très courts, où tout le temps part en surcoût d’appel. Dans ces cas, l’estimation gratuite montre honnêtement un gain faible, et vous n’aurez rien à payer.
Mes comptes de cycles diffèrent des vôtres. Pourquoi ?
Les cycles dépendent du modèle de CPU, de la fréquence, du turbo, de la mémoire et des données d’entrée. Les chiffres contractuels sont relevés sur le banc selon le passeport de mesure. Le harness lit les mêmes compteurs : avec le même modèle de CPU et les mêmes réglages, vos chiffres devraient être proches des nôtres. Le nombre d’instructions dépend bien moins de la machine : comparez-le en premier.
Et les calculs en virgule flottante ?
Par défaut, les sorties correspondent au bit près, avec une exception limitée pour les payloads de NaN produits par l’arithmétique en virgule flottante lorsque Rust autorise des payloads différents. Les encodages de NaN explicitement préservés et les autres sorties restent exacts, sauf accord contraire dans le passeport. Le passeport peut aussi exiger des payloads de NaN exacts. Tout autre écart convenu est défini dans le passeport et vérifié par des tests.
Le build va-t-il planter sur un vieux serveur ?
Vérifiez les exigences CPU de chaque paquet. Les binaires publics peuvent exiger AVX2/FMA et ne pas fonctionner sur un ancien CPU. Fonctions et éventuel repli d’un binaire payé sont convenus dans sa fiche ; le repli n’est pas acquis pour chaque binaire.
Cela réduira-t-il la latence de mon trading en direct ?
Seulement si le profilage montre que le calcul est le goulet d’étranglement. Pour un chemin en direct, nous mesurons tout le trajet de l’événement de marché à l’ordre, par exemple son p99 sur votre serveur, et non une seule fonction : le plus souvent, l’essentiel du temps part dans le réseau et la bourse. Nos meilleurs résultats concernent les calculs par lots : backtests, entraînement et balayages de paramètres.
Travaillez-vous avec C, C++ et Python ?
Oui, en commandes individuelles. Pour C et C++, nous livrons une bibliothèque de remplacement avec la même ABI : vos programmes, et le code Python qui appelle la bibliothèque, fonctionnent sans modification (voir le cas TA-Lib). Pour du code Python, nous livrons un programme ou un module natif avec la même sortie (voir le cas vn.py). C’est un travail d’ingénierie de niveau 2, au prix individuel ; le libre-service du tableau de bord accepte pour l’instant des crates Rust.