High-Performance Backtest Engines
How to build a backtest engine that runs hundreds of times faster without changing a single PnL number — data layout, caching, adaptive resolution, and architecture, from first speedups to production internals.
- 01
Jun 26, 2026#algotradingLa Scala di Velocità del Backtest: 298x su una CPU da Laptop, PnL Identico Fino all'Ultimo Trade
Cinque implementazioni dello stesso sweep di parametri a 80 combo, tutte verificate per produrre lo stesso PnL: pandas rolling.apply impiega 69.9 secondi, numpy 3.1, numba 2.0, numba parallelo 0.23 — uno speedup misurato di 298x su un Apple M2 Max a parità di hardware, e ancora ~13x rispetto a una baseline vettorizzata competente. Cosa guadagna ogni gradino, perché una GPU non è il pezzo mancante, e dove si trova il vero collo di bottiglia nella ricerca massiva di parametri.
- 02
Jul 2, 2026#algotradingLa tassa del framework: quando la tua libreria di backtest è più lenta di un ingenuo ciclo pandas
Abbiamo messo a confronto otto motori di backtest su un'unica identica ricerca di parametri — 150k barre, 80 combinazioni di incrocio HMA, parità del conteggio operazioni bloccata a 2707. Due dei framework event-driven più popolari sono risultati più lenti di un ciclo pandas scritto a mano, mentre un motore vettorizzato/compilato ha eseguito lo stesso lavoro ~13,000× più velocemente. Uno studio sull'overhead per barra che le librerie popolari non sono mai state costruite per ammortizzare.
- 03
Mar 16, 2026#algotradingCache Parquet Aggregata: Come Accelerare i Backtest Multi-Timeframe di Centinaia di Volte
Come precalcolare i timeframe e gli indicatori dalle candele al minuto, salvarli in parquet e utilizzarli per il testing di massa delle strategie senza ricalcoli ridondanti.
- 04
Jul 3, 2026#algotradingLo spazio dei parametri a due assi: perché gran parte del tuo sweep dovrebbe essere quasi gratis
Non tutti i parametri costano allo stesso modo in fase di ricerca. I parametri di una strategia si dividono in un asse costoso (gli indicatori — ricalcolati sull'intera serie) e un asse economico (le soglie decisionali — una passata O(n) su segnali precalcolati). Poiché gli indicatori sono invarianti rispetto alle soglie, li calcoli una volta sola e scandagli migliaia di configurazioni di soglie a ~5,600 cfg/s — circa 1,600x più economico che ricalcolare a ogni configurazione. Una riprezzatura della maledizione della dimensionalità.
- 05
Mar 17, 2026#algotradingDrill-Down Adattivo: Backtest con Granularità Variabile dai Minuti ai Trade Grezzi
Come la granularità adattiva dei dati accelera i backtest e risparmia spazio di archiviazione: drill-down da 1m a 1s, 100ms e trade grezzi solo dove il prezzo si è mosso significativamente o il volume è aumentato, non sull'intera serie storica.
- 06
Jul 5, 2026#trading algoritmicoIl Fidelity Gate: il Backtesting dal Grossolano al Fine Ti Inganna Più in Fretta a Meno che il Proxy Economico non Classifichi Come Quello Costoso
La ricerca drill-down / multi-fedeltà (ASHA, successive halving, Hyperband) filtra economicamente migliaia di configurazioni e promuove solo i sopravvissuti alla costosa valutazione completa. È un'accelerazione autentica — ma collassa silenziosamente se il ranking a bassa fedeltà non concorda con quello ad alta fedeltà. Abbiamo misurato la correlazione di rank tra fold: con un solo fold lo Spearman ρ può essere 0.03 (classifica quasi a caso), salendo a 0.43, 0.67, 0.78, 0.91 man mano che i fold si accumulano. La soluzione è un gate obbligatorio — misurare prima ρ(economico, completo) e alzare automaticamente la fedeltà minima al primo livello in cui ρ ≥ 0.5.
- 07
Jul 4, 2026#algotradingRicerca casuale vs ricerca intelligente: il punto di incrocio è il costo di valutazione, non l'algoritmo
Quando un singolo backtest è economico, una sequenza Sobol scombinata e stupida vince in termini di puro throughput — i sampler "intelligenti" (TPE, CMA-ES, ASHA) pagano una tassa ask/tell in Python che li rallenta di 20 volte, facendo sì che valutino molti meno punti a parità di tempo reale trascorso, e perdono. Rendi ogni valutazione costosa (multi-TF + fold walk-forward) e il punto di incrocio si ribalta. Abbiamo misurato entrambi i regimi, e perché la fedeltà del rango tra fold (ρ@1 che sale da 0.03 a 0.43) è la precondizione perché il pruning ripaghi.
- 08
Mar 11, 2026#algotradingDiscesa per Coordinate vs Ottimizzazione Bayesiana: Chi Trova i Parametri Migliori
Perché la ricerca esaustiva è impossibile per 12+ parametri, come la discesa per coordinate perde le interazioni e come Optuna con un campionatore TPE trova in 500 iterazioni ciò che OAT non riesce a trovare in 96. Esempi di codice pratici, confronto dei campionatori e ottimizzazione multi-obiettivo.
- 09
Jul 6, 2026#algotradingLa trappola della precisione GPU: come un backtest in fp32 su Apple Metal restituisce silenziosamente spazzatura
La GPU Metal di Apple non ha float64. Porta ingenuamente un backtest vettorizzato su di essa e la tentante WMA a somma prefissa manda in overflow l'fp32 — errore relativo massimo 211× — eppure gira comunque e restituisce numeri dall'aspetto plausibile. La soluzione non è più precisione; è una formulazione diversa: una convoluzione a finestra diretta, sicura in fp32 fino a 8×10⁻⁷ e 55,9× più veloce del numba a thread singolo. La trappola, l'aritmetica e come dimostrare di non esserci caduto.
- 10
Jul 7, 2026#algotradingQuando la GPU Ripaga: Il Roofline dello Sweep di Parametri, Dove un 167x da Titolo è in Realtà 27x di Algoritmo per 6.2x di Hardware
Il vantaggio della GPU sulla CPU cresce con la dimensione del batch — da 54.5x a un combo per chiamata fino a 359.6x a 61 sul nostro precompute di indicatori multi-timeframe — perché uno sweep piccolo non può ammortizzare l'overhead di lancio dei kernel e di trasferimento. Scomponiamo un 167x da titolo in una vittoria algoritmica di 27x che aiuta anche la CPU e una vittoria hardware di 6.2x, mostriamo che il vero vantaggio GPU-vs-migliore-CPU è solo 3.2x single-timeframe e 6.2x multi, e diamo una guida decisionale su quanto largo debba essere uno sweep prima che una GPU valga l'investimento.
- 11
Jun 30, 2026#algotradingLa Tassa IPC: Metti il Motore di Backtest Dietro un Socket e Perdi il 13% — Ma Quasi Nulla è Colpa del Socket
Abbiamo portato un kernel di backtest numba riga per riga in Rust e lo abbiamo chiamato attraverso un confine di processo in quattro modi diversi, con un gate di equivalenza che conferma un PnL identico fino all'ultimo trade. Spedire l'intera serie di prezzi da 1.2 MB attraverso un Unix socket costa ~2 ms — circa lo 0.1% del lavoro. Codificare lo stesso payload in JSON costa 1348 volte più dei byte raw, le chiamate chatty per-combo rispediscono i dati 80 volte, e un pattern di chiamata per-barra pagherebbe 2.1 s di puro IPC su un job da 2.0 s. Il confine è economico; la tassa sta in come lo attraversi.