Blog

I backtest multi-timeframe fanno trapelare il futuro attraverso una barra di timeframe superiore ancora in formazione, la cui chiusura finale non esiste ancora. Non si può raggiungere la certezza con una semplice code review — bisogna testarlo. Riproduciamo esattamente la regola closed-bar del bot live, poi dimostriamo l'assenza di leakage con una probe a futuro perturbato: perturbiamo ogni barra futura e verifichiamo che ogni segnale e trade passato resti bitwise invariato. 25/25 controlli di parità superati, e la probe ha i denti.

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.

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.

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.

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.

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à.

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.