MT5 e la velocità in azione - pagina 63
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
Cari sviluppatori, potreste informarmi come viene calcolato MQL_MEMORY_USED?
Ho fatto un calcolo della memoria che tutte le variabili EA occupano.
È meno del 10%. Se ho capito bene, MQL_MEMORY_USED include la cache History e la cache CopyTicks. Ma è ancora molto meno.
Allo stesso tempo, l'Expert Advisor parallelo consuma diverse volte meno. Ma il principio è lo stesso.
In generale, cosa è incluso in questo valore?
Ho salvato un modello con Expert Advisor e l'ho applicato allo stesso grafico causando il ricaricamento. L'ho visto così.
L'uso della memoria è cambiato di quasi un ordine di grandezza. Finora è difficile spiegarne il significato.
Molti programmi hanno un effetto cumulativo di utilizzo della memoria. Questo è un peccato dei browser e a volte anche di Word. Anche il terminale può essere colpevole di questo. Inoltre, tutti i log sono scritti di default ed è facile passare una settimana se si hanno troppe azioni in un giga. Questo è un male che deve essere gestito. Ma non è chiaro come.
Forse sapete come selezionare programmaticamente uno strumento finanziario e non rimanere bloccati per secoli?
Attraverso un indicatore
Forum sul trading, sistemi di trading automatico e test di strategie di trading
MT5 e la velocità in azione
Renat Fatkhullin, 2020.10.14 04:15
Per il ticchettio di massa mettete più memoria.
4gb (prezzo €20) non vanno bene nel 2020 quando si tratta di analisi e ricerca.
Per i prodotti di mercato questo approccio non va bene da nessuna parte. Dobbiamo bypassare la conservazione di 10 secondi di dati inutili attraverso una tale stampella.
Fare un banale prodotto di mercato sotto forma di un Market Screener non è in realtà un compito realizzabile per MT5 a causa dell'eccessivo consumo di memoria.
Realizzare un banale prodotto di mercato sotto forma di Market Screener non è in realtà un compito realizzabile per la MT5 a causa dell'eccessivo consumo di memoria.
Il terminale mangia così tanta memoria dopo il lancio.
Dopo l'esecuzione dello screener ha iniziato a mangiare 2 giga (TERMINAL_MEMORY_USED e non è diminuito con il tempo). Questo con un solo grafico aperto per 5000 barre M1.
Non ha salvato uno screenshot. Ma ha deciso di gettare un esempio, che mostra la memoria mangiare terminale non in sé, dove è solo stupido.
Lo script fa semplicemente delle copie dei simboli originali del Market Watch. Dovevo aggiungere tutti i simboli su MQ-Demo ed eseguire questo script la prima volta a freddo e poi di nuovo a caldo.
E dopo l'esecuzione a caldo (quando i tick sono già su SSD sotto forma di file tkc) osserverò un enorme esaurimento della memoria dove non è necessario in una corretta implementazione.
Tuttavia, eseguendo lo script, ho riscontrato che si blocca su MQ-Demo. Può essere scaricato solo attraverso la terminazione anomala, dopo la quale il terminale non rilascia più di 1 GB di memoria.
È facile confrontare questa schermata con quella dell'inizio.
Scusa, non sono sicuro se questo è un bug o una caratteristica. Non ho trovato una risposta da solo. Ma la domanda è legata alla performance e suppongo sia meglio farla qui.
Se aggiungiamo, per esempio, 22 buffer di tipo DRAW_SECTION a un indicatore vuoto, allora all'avvio di tale indicatore per un grafico contenente 1000000 barre o più il terminale ritarda notevolmente (causa un carico significativo della CPU) e mangia quantità significative di memoria, anche se l'indicatore non calcola nulla.
Il mio interesse è stato suscitato dal fatto che se si usano buffer con altri tipi, tutto funziona senza problemi e non si osserva tale rallentamento.
Per esempio, ho eseguito il seguente codice su un singolo grafico con 1000000 barre e ha consumato circa 500 MByte e ritarda, soprattutto il grafico stesso.
Ma se cambio il tipo di buffer a, diciamo, DRAW_LINE, il carico sul processore si riduce drasticamente, non si osservano ritardi e la memoria consuma 5 volte meno (circa 100 MByte consumati).
Test simili sono stati fatti su diverse build, fino alle build 2019 e la situazione è la stessa.
Un singolo cittadino ha tirato fuori dai suoi larghi pantaloniun duplicato di un prezioso carico di codice MQL, che mostrava che nelle stesse condizioni la stampella lavorava più velocemente della funzione regolare.
Un test molto semplice:
20 Expert Advisors su EURUSD, cioè tutti i processi OnTick simultaneamente. La costruzione del terminale è 2664. Il test viene eseguito senza ottimizzazione, compilazione e altri carichi aggiuntivi al 100% della CPU - non hai intenzione di eseguire un vero commercio "hft" su questo sfondo, vero?
Tipico registro di test:
Un test molto semplice:
20 EAs su EURUSD, cioè tutti i processi OnTick allo stesso tempo. Terminale build 2664. Il test viene eseguito senza ottimizzazione, compilazione e altri carichi di lavoro aggiuntivi sul 100% della CPU - non hai intenzione di eseguire un vero e proprio trading "hft" su questo sfondo, vero?
Tipico registro di test:
Si creano condizioni da serra facendo 100K iterazioni per 1,5 secondi sullo stesso tick. Io, invece, ho aspettato di proposito i tick che non generavano un OnTick.
Guardando i miei log di trading, noto l'esecuzione di SymbolInfoTick in pochi millisecondi. E so per certo al 100% che la CPU era in pieno Idle in quel momento.
È molto semplice. Ci sono condizionatamente 1 milione di zecche al giorno. Anche lo 0,01% di rallentamento dei tic è di 100 tic al giorno con ritardi. Direte che è una sciocchezza. Dirò che è brutto. Se mi imbatto in un ritardo quando devo fare un ordine, è una potenziale perdita monetaria.
Molto grato che questo ramo non passi inosservato, e su questa caratteristica in particolare, è stato fatto un sacco di lavoro per accelerare le cose. Tuttavia, è stata un po' una sorpresa per me che la stampella terribile potesse superare la funzione regolare in certe situazioni. E forse, se lo risolvesse ed eliminasse quel ritardo, 100 potenziali ritardi al giorno diventerebbero 10.
Io dico che è molto meglio che all'inizio del thread. Ma resta il fatto che ci sono momenti in cui non va bene. E vedo che non vuoi indagare. Rispetto la vostra scelta.
Sopra ha citato l'opzione istantanea per ottenere i prezzi attuali. Mi andrebbe benissimo se non beccasse ritardi di millisecondi sulla macchina Idle-CPU.
Sono anche preoccupato non solo per la velocità di SymbolInfoTick, ma anche per la rilevanza dei prezzi che restituisce. Vedo che non sollevate questa questione. A quanto pare hai deciso di guardarlo dopo.
Si creano condizioni da serra facendo 100K iterazioni entro 1,5 secondi sullo stesso tick. Io, d'altra parte, ho aspettato specificamente i tick che non hanno generato OnTick.
Quando esamino i miei log di trading, noto che SymbolInfoTick è in esecuzione per alcuni millisecondi. So al 100% che la CPU era completamente inattiva in quel momento.È molto semplice. In un giorno ci sono condizionatamente 1 milione di zecche. Anche un ritardo dello 0,01% è di 100 tick al giorno con ritardi. Direte che è una sciocchezza. Dirò che è brutto. Se mi imbatto in un ritardo quando devo fare un ordine, è una potenziale perdita monetaria.
Molto grato che questo ramo non passi inosservato, e su questa caratteristica in particolare, è stato fatto un sacco di lavoro per accelerare le cose. Tuttavia, è stata un po' una sorpresa per me che la stampella terribile potesse superare la funzione regolare in certe situazioni. E forse, se lo risolvesse ed eliminasse quel ritardo, 100 potenziali ritardi al giorno diventerebbero 10.
Io dico che è molto meglio che all'inizio del thread. Ma resta il fatto che ci sono momenti in cui non va bene. E vedo che non vuoi indagare. Rispetto la vostra scelta.
Sopra ha citato l'opzione istantanea per ottenere i prezzi attuali. Mi andrebbe benissimo se non beccasse ritardi di millisecondi sulla macchina Idle-CPU.
Sono anche preoccupato non solo per la velocità di SymbolInfoTick, ma anche per la rilevanza dei prezzi che restituisce. Vedo che non sollevate questa questione. A quanto pare hai deciso di guardarlo dopo.
Queste non sono affatto condizioni calde. Un ciclo per 100000 richieste di prezzo senza Sleep() e simili e in 20 threads simultaneamente è un ovvio stress test. Niente del genere dovrebbe essere anche solo vicino in condizioni reali.
Se pensi che non ci siano altri tic in arrivo in 1,5 secondi - ok, fai 10 milioni di query, non cambierà nulla, la tua "stampella" funziona peggio:L'affermazione che stai facendo è falsa al 100%:
Proprio come questa tua precedente affermazione:
L'accesso ai prezzi tramite SymbolInfoTick è ora molto veloce ed è completamente disaccoppiato dall'elaborazione del flusso di tick. Stai lavorando con una cache dei prezzi già pronta, che viene aggiornata con molta parsimonia e rapidamente.
Tutti i "rallentamenti dello 0,01% di tick rate" si manifestano solo in condizioni di stress test, e questo è un ottimo risultato. In condizioni normali, l'accesso è garantito per essere molto veloce.
Se ammetti che "è stato fatto molto lavoro per velocizzare" SymbolInfoTick, allora dovresti credermi che la "stampella" di ottenere i prezzi tramite PositionSelectByTicket non può essere una soluzione migliore.
Per una semplice ragione - l'implementazione di PositionSelectByTicket è completamente identica all'implementazione originale "lenta" di SymbolInfoTick.
Come ho scritto sopra, questa implementazione non è lenta nel senso letterale della parola, ma sotto un forte carico di CPU, ha una maggiore probabilità di outlier runtime (che è chiaramente visibile nel mio ultimo test).
I tempi qui sono altamente dipendenti dal task scheduler di sistema che gira sotto carico, cioè ci possono essere differenze da un sistema operativo all'altro e anche da una versione all'altra.
E più il carico è pesante, più si testano le prestazioni del task scheduler, non del terminale.
Questa è la fine dell'argomento sulle prestazioni di SymbolInfoTick.
Se i vostri esperti creano un carico a livello di stress test sintetico, c'è solo una soluzione: "l'hardware deve corrispondere ai compiti".
Ho una domanda sulla rilevanza dei tick dati da SymbolInfoTick.
Situazione:
1. Facciamo TimeCurretn(); otteniamo il tempo 18:00:00
2. Eseguire SymbolInfoTick su un simbolo non valido. Abbiamo un segno di spunta con il tempo 17:58:00.
3. Dormire(1)
4. Aggiunge un SymbolInfoTick per il simbolo non a sinistra. Otteniamo un segno di spunta con l'ora 17:59:00.
Cioè, nel quarto elemento abbiamo un nuovo tick, che è un minuto diverso da TimeCurretn().
Vede un problema in questa situazione?
Come fare per trovarsi meno spesso in questa situazione?
Ho una domanda sulla rilevanza dei tick dati da SymbolInfoTick.
Situazione:
1. Facciamo TimeCurretn(); otteniamo il tempo 18:00:00
2. Eseguire SymbolInfoTick su un simbolo senza etichetta. Abbiamo un segno di spunta con il tempo 17:58:00.
3. Dormire(1)
4. Aggiunge un SymbolInfoTick per il simbolo non a sinistra. Otteniamo un segno di spunta con l'ora 17:59:00.
Cioè, nel quarto elemento abbiamo un nuovo tick, che è un minuto diverso da TimeCurretn().
Vede un problema in questa situazione?
Come trovarsi meno spesso in questa situazione?
SymbolInfoTick invia i dati ricevuti dal server del broker. Ciò che il server ha inviato è ciò che si ottiene.
Se ci sono domande sul flusso di tick che viene trasmesso dal tuo broker, allora devi contattare il tuo broker.