MT5 e la velocità in azione - pagina 16
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
Sarebbe interessante confrontare lo stesso script con altre piattaforme di trading.
MT4 b1280.
Solo tre scivoloni e poi sono spuntati molto raramente. Probabilmente è difficile creare un freno dato che non c'è HistorySelect e CopyTicks.
così sono entrambi Haswell, xeon ha molto più bassa frequenza operativa, ci sarà degrado delle prestazioni in prestazioni e test singolo, solo in ottimizzazione multi-threaded sarà un vantaggio. L'i3 degli ultimi modelli dovrebbe essere molto più veloce da eseguire
chiedere agli sviluppatori l'effetto del livello di cache sulla velocità e in generale la velocità di Zen2 e degli ultimi intel
aggiungere
Ryzen 3700x che ho, si possono fare prove con Intel
per esempio con questo script MQL5\Scripts\UnitTests\Stat\TestStatBenchmark.mq5
fare il loop più volte con un timer
Qui non stiamo parlando di test, ma di ritardi nell'esecuzione degli ordini. Questo ritardo c'è ed è fluttuante. E questo preoccupa molto sia me che il TS.
Solo tre cose sono saltate fuori e poi sono saltate fuori molto raramente. Deve essere difficile creare un freno visto che non ci sono HistorySelect e CopyTicks.
Atteso anche su MT4.
TimeLocal in 36 millisecondi. Scegli un simbolo con un volume di tick maggiore.
Per chiunque sia interessato, ecco le istruzioni per la riproduzione.
Chi pensa che non sarà toccato.
Ha scelto un simbolo con un volume di tick maggiore.
Non ho nemmeno intenzione di controllarlo. Immaginate il simbolo FORTS più popolare con una sottoscrizione a tick. Invece della logica OnTick in OnBookEvent. I ritardi devono essere terribili.
Ho bisogno di un consiglio ufficiale su cosa fare per minimizzare i ritardi.
Per riprodurre i freni, è necessario eseguire lo script su più grafici a UNO carattere - ottenere che OnTick sia chiamato allo stesso tempo. Poi, gli avvisi saranno inviati ad ogni tick.
Il grafico del carico della CPU mostra che terminal64.exe carica fino al 30% degli otto core logici. Sono solo quattro grafici EURUSD con lo script in esecuzione. Si può vedere chiaramente quanto ogni grafico è caricato alla volta.
Dove vanno a finire così tante risorse?
È facile rispondere a questa domanda.
Qui si copiano molti dati:
In realtà stai dando un comando per prendere tutta la storia di trading disponibile dal database del terminale nell'ambiente EA, per un uso successivo. State volutamente cercando di mettere in crisi un possibile algoritmo di caching per richieste identiche.
Ma voi non usate tutti questi dati, ma li resettate immediatamente nella riga successiva:
Ovviamente la base terminale qui è una risorsa condivisa con accesso sincronizzato. E lei ha deliberatamente creato migliaia di ordini e accordi in esso.
Tutta questa azione senza senso viene ripetuta 10 volte ad ogni tick da diversi thread alla volta. E state deliberatamente facendo accadere queste azioni simultaneamente da diversi thread.
Quindi sapete molto bene cosa state facendo e perché, dove vengono spese le risorse, e allo stesso tempo sostenete che "il ritardo è causato da un eccessivo carico della CPU da parte di MT5".
Detto questo, è chiaro che hai un problema con il tuo computer. Cioè, sì, state attivamente spostando quantità significative di memoria, ma non dovrebbe influenzare il tempo di esecuzione delle funzioni, specialmente non legate a HistorySelect() in alcun modo.
Nei nostri test b2582, anche con 1000 volte per tick e 5 EAs su grafici di un carattere, cioè ordini di grandezza più grandi delle vostre condizioni di default, non è stato osservato un solo Allarme.
Il nostro sistema di test: Windows 10 build 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
È facile rispondere a questa domanda.
Qui è dove si copiano molti dati:
In realtà stai dando un comando per prendere tutta la storia di trading disponibile dal database del terminale nell'ambiente EA, per un uso successivo. Cercando volutamente in modo casuale di disturbare il possibile algoritmo di caching di richieste identiche.
Ma voi non usate tutti questi dati, ma li resettate immediatamente nella riga successiva:
Ovviamente la base del terminale qui è una risorsa condivisa con accesso sincronizzato. E lei ha deliberatamente creato migliaia di ordini e accordi in esso.
Tutta questa azione senza senso viene ripetuta 10 volte ad ogni tick da diversi thread alla volta. E state deliberatamente facendo accadere queste azioni simultaneamente da diversi thread.
Quindi sapete molto bene cosa state facendo e perché, dove vengono spese le risorse, e allo stesso tempo sostenete che "il ritardo è causato da un eccessivo carico della CPU da parte di MT5".
Detto questo, è chiaro che hai un problema con il tuo computer. Cioè, sì, state attivamente spostando quantità significative di memoria, ma non dovrebbe influenzare il tempo di esecuzione delle funzioni, specialmente non legate a HistorySelect() in alcun modo.
Nei nostri test b2582, anche con 1000 volte per tick e 5 EAs su grafici di un carattere, cioè ordini di grandezza maggiori delle tue condizioni di default, non è stato osservato un solo Allarme.
Il nostro sistema di test: Windows 10 build 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
Colleghi,
è ora che tu esca dal cerchio dell'aeromodellismo.
Ecco le condizioni di battaglia: 4 terminali, circa 300 Expert Advisors, circa 30 strumenti. Un terzo di loro è abbonato ai tumbler. Tutto questo su FORTS. Simulare in queste condizioni.
Colleghi,
è ora che tu esca dal circolo dei modellisti di aerei.
Ecco le condizioni di combattimento: 4 terminali, circa 300 EAs, circa 30 strumenti. Un terzo degli EA sono abbonati ai tumbler. Tutto questo su FORTS. Simulare in queste condizioni.
"Here you go" viene accettato come file zip, più una descrizione dettagliata del problema. Altrimenti è una conversazione vuota.
Ciò che viene discusso qui è il codice dell'EA presentato e l'efficacia della sua esecuzione. Sulla base dei problemi identificati, si è lavorato per ottimizzare il codice del terminale.
"Here you go" viene accettato come file zip, più una descrizione dettagliata del problema. Altrimenti è una conversazione vuota.
In questo caso, la discussione riguarda il codice presentato dall'Expert Advisor e l'efficienza della sua esecuzione. Il codice del terminale è stato ottimizzato per i problemi identificati.
Non ho nessun problema, non c'è niente da inviare.
fxsaber ha problemi, ha già scritto 16 pagine qui.
E Mikhail ha gli stessi problemi dal 2014, ha già scritto 149 pagine: https://www.mql5.com/ru/forum/38456/page149.
Sono entrambi abbastanza qualificati per darvi tutte le informazioni di cui avete bisogno.
È facile rispondere a questa domanda.
Qui è dove si copiano molti dati:
In realtà stai dando un comando per prendere tutta la storia di trading disponibile dal database del terminale nell'ambiente EA, per un uso successivo. Randomizzare volutamente cercando di disturbare il possibile algoritmo di caching di richieste identiche.
Lei non ha seguito la cronologia di sviluppo di questo thread, quindi si permette delle note accusatorie nelle sue affermazioni.
Ho rimosso la linea MathRand. Ecco un breve resoconto.
Ma tu non usi tutti questi dati, li scarichi immediatamente nella riga successiva:
Ovviamente la base terminale qui è una risorsa condivisa con accesso sincronizzato. E lei ha deliberatamente creato migliaia di ordini e accordi in esso.
Lo provo su conti reali dove gli ordini superiori a 10K sono la norma. Questi non sono ordini falsi, poiché >70% di essi sono stati eseguiti.
Nello screenshot, a proposito, 9331+576 != 12529.
Tutta questa azione insensata viene ripetuta 10 volte ad ogni tick da più fili contemporaneamente. E state deliberatamente facendo in modo che queste azioni da più thread si verifichino simultaneamente.
Sto avendo problemi su diversi personaggi. Si suggerisce un unico simbolo per riprodurre più rapidamente il problema.
Ripetere 10 volte per ogni spunta è una necessità vitale. Poiché è normale che un EA contenga una dozzina di TC con diverse major.
Quindi sai molto bene cosa stai facendo e perché, e dove vanno le risorse, eppure affermi che "La latenza è dovuta a un carico eccessivo della CPU da parte di MT5".
Detto questo, è chiaro che hai un problema con il tuo computer. Voglio dire, sì, state attivamente spostando quantità significative di memoria, ma non dovrebbe influenzare il tempo di esecuzione delle funzioni, specialmente non legate a HistorySelect() in alcun modo.
Non posso accusarla di incompetenza, ma quello che ha scritto, per usare un eufemismo, provoca sconcerto. HistorySelect è la ricerca di quattro indici (inizio/fine per la tabella degli ordini e inizio/fine per la tabella degli affari). Le tabelle sono ordinate per tempo, quindi c'è (dovrebbe esserci) una ricerca binaria al peggio. Per 10K ordini è istantaneo (calcolare il logaritmo binario). Che movimento del volume della memoria! Nessuno qui sta parlando della temuta HistorySelectByPosition. L'elemento HistorySelect è interessato.
Sui nostri test b2582, anche con 1000 volte per tick e 5 EAs su grafici di un carattere, cioè ordini di grandezza maggiori delle vostre condizioni di default, non si osserva un solo Allarme.
Il nostro sistema di test: Windows 10 build 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
Si prega di fornire i dettagli di accesso per il conto di trading su cui sono stati condotti i test qui.