![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Sembra che ci sia un malinteso su ciò di cui si parlava qui. Stavo parlando di un esempio di un problema di Tester privato, dove i prezzi interi possono dare un guadagno in certe situazioni. Il caso universale non era in mente. È per questo che il mio Tester, di cui ho dato il link qui sopra, è implementato sui dub, perché è universale.
Non posso essere d'accordo il 100% delle volte.
Lei ha fatto un'affermazione:
Sono quasi certo che se rendete i tick interi, il Tester inizierà a lavorare molto più velocemente.
È assolutamente sbagliato quando si cerca di metterlo in pratica. Sbagliato il 100% delle volte in pratica.
Quindi non c'è bisogno di andare nella teoria o nella sostituzione degli argomenti. L'argomento è "il tester attuale può essere accelerato quando viene convertito in intero". E l'argomento è sbagliato al 100% senza eccezioni.
Lei ha fatto un'affermazione:
È completamente sbagliato quando si cerca di metterlo in pratica. In pratica è sbagliato al 100%.
Quindi non c'è bisogno di entrare nella teoria o di cambiare argomento. L'argomento è "il tester attuale può essere accelerato quando viene convertito in intero". E l'argomento è sbagliato al 100% senza eccezioni.
Si prega di notare che questa è l'unica mia dichiarazione in cui ho originariamente preso la parola Tester tra virgolette. Hai frainteso il punto che ho sollevato.
Questo è un add-on per il tuo Tester, che senza cambiare il codice di qualsiasi EA (con qualsiasi indicatore) fa un passaggio completo con tutti i trade e i profitti. Ma lo fa più velocemente del normale Tester. Tutte le prove riproducibili sono state date. Persone della risorsa hanno verificato queste affermazioni.
Mostraglielo.
E poi dimostrare che si tratta di passare a un meccanismo intero, non che abbiamo implementato in modo inefficiente un meccanismo o un altro attraverso la svista.
Se stiamo parlando dell'impatto del ricalcolo della base delle posizioni aperte, allora ci sono dei veri e propri freni, che sistemeremo nei prossimi giorni.Si prega di notare che questa è l'unica mia dichiarazione in cui la parola Tester è stata originariamente presa da me tra virgolette. Hai frainteso l'argomento che è stato sollevato.
Ho capito bene.
E ha correttamente affrontato l'argomento con dettagli sgradevoli per voi. Se pensate che non abbiamo calcolato il tester intero, vi sbagliate di grosso.
Mostrami.
Mostra.
E poi dimostrare che si tratta di passare a un meccanismo intero, non che abbiamo implementato in modo inefficiente un meccanismo o un altro attraverso la svista.
Ho rinunciato ai tester interi perché non erano versatili. Erano più veloci, ma c'erano più minus che plus. Tuttavia, come fenomeno, possono esistere. Virtual-work - su dub.
Sarebbe fantastico!
Ve lo mostro.
Questo?
https://www.mql5.com/ru/forum/285631/page107#comment_10271917
Sono abbastanza sicuro che se rendete i tick interi, il "Tester" sarà molto più veloce.
Ho confrontato la velocità di double e int in questi due script identici:
Sorprendentemente, la variante con doppio predominante era anche leggermente più veloce sulla mia CPU.
E' piuttosto figo.
Ho ottenuto 347 fps senza antialiasing e 97 con antialiasing su una tela di 2100x550 pixel.
Per informazione, abbiamo un limitatore della velocità di aggiornamento della finestra di 500 fps. Questo mostra quante prestazioni si possono ottenere nella grafica.
Grazie.
In realtà con l'antialiasing i doppi cerchi sono più lenti dell'originale senza antialiasing dei cerchi int di circa il 20%. Ho 300 contro 250 fps.
È solo che apparentemente hai misurato i cerchi anti-alias con le ombre, e l'ombra di un cerchio è molto più vorace del cerchio stesso. L'ombra può essere disabilitata con il parametro draw a shadow? = falso.
Ho confrontato la velocità di double e int in questi due script identici:
Sorprendentemente, la variante dominata dal doppio era anche leggermente più veloce sulla mia CPU.
Attenzione alle conversioni di massa come (int)double o (double)int e int+double nelle operazioni matematiche in generale.
Questo dà l'overhead più selvaggio del processore - proprio un comando assembler così costoso. Se stai contando in doppio, continua a contare in esso e non passare a tipi interi.
Comandi come cvtsi2sd/cvttsd2si sono molto lunghi. Un piccolo suggerimento nell'articolo"L'istruzione x86 più lenta", villano numero 2.
Il manuale di riferimento per l'ottimizzazione delle architetture Intel® 64 e IA-32 dice che il costo dell'istruzione cvtsd2si è di 5 latenze (vedi Appendice C-16). cvtsi2sd, a seconda della vostra architettura, ha una latenza che varia da 1 su Silvermont a più come 7-16 su diverse altre architetture.
Letabelle delle istruzioni di Agner Fog hanno numeri più accurati/sensibili, come la latenza di 5 cicli per cvtsi2sd su Silvermont (con 1 per 2 clock di throughput), o la latenza di 4c su Haswell, con uno per clock di throughput (se si evita la dipendenza del registro di destinazione dalla fusione con la vecchia metà superiore, come gcc di solito fa con pxor xmm0,xmm0).
Grazie.
In realtà con l'antialiasing i doppi cerchi sono più lenti dell'originale senza antialiasing dei cerchi int di circa il 20%. Ho 300 contro 250 fps.
È solo che apparentemente hai misurato i cerchi anti-alias con le ombre, e l'ombra di un cerchio è molto più vorace del cerchio stesso. L'ombra può essere disabilitata con il draw a shadow? = falso.
Si scopre che stavo guardando la frequenza di generazione del web, non la frequenza di uscita.
Sono numeri diversi, multipli l'uno dell'altro.