MT5 e la velocità in azione - pagina 61
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
Sento che questo muro di MQ non passerà senza il sostegno dei membri del forum. Il codice è breve, i professionisti dovrebbero essere in grado di capirlo rapidamente. Non ci sono difetti. Si dimostra chiaramente che i prezzi attraverso le posizioni sono ottenuti molto più velocemente che da Market Watch. Come MQ non riesca a vedere l'ovvio - non lo capisco.
1. Il tuo test conta davvero una micro percentuale di iterazioni a causa della condizione
In sostanza si contano solo le anomalie in cui il processore è sovraccarico di compiti e rimanda l'esecuzione del dato compito sul ripiano più lontano, poiché oltre il 99% delle iterazioni viene eseguito in meno di 1 microsecondo.
E anche se si imposta la condizione >0, non c'è ancora obiettività.
2. La misurazione del tempo di tali operazioni veloci dovrebbe essere fatta solo come tempo di ciclo completo, non come singola iterazione.
3. Ma poiché il ciclo nel tuo esempio è limitato a 10 secondi (Perché! Per i tic credo che 0,1 secondi siano sufficienti. Perché può benissimo succedere che 3 tick arrivino in un secondo, e tutti e tre i tick saranno eseguiti per 10 secondi ciascuno, e in parallelo), quindi non è necessario alcun timing. È più facile calcolare quante iterazioni saranno eseguite in un dato tempo. Più, più produttività.
Ho modificato "un po'" il tuo codice. Penso che la mia variante rifletta meglio la realtà.
Il calcolo viene fatto uno alla volta, per non mischiare le due varianti. I tick pari sono perSYMBOL_BID, quelli dispari - per GetBid().
Ho aggiunto le somme e il loro output per sicurezza, come tentativo di ingannare il compilatore contro l'ottimizzazione.
Il risultato dell'uscita è cumulativo.
Il mio risultato:
Come potete vedere, la differenza di prestazioni è tre volte a favore della versione standard.
Come potete vedere la differenza di prestazioni è tre volte a favore della versione originale.La versione originale di fxsaber mostra il vantaggio di GetBid, o si tratta di un PC più potente/meno carico?
La versione originale di fxsaber mostra il vantaggio di GetBid, o è un PC più potente/meno carico?
La sua variante ha anche mostrato il vantaggio di GetBid a pieno carico della CPU. Ma allo stesso tempo la mia variante mostra tre volte il vantaggio della funzione regolare allo stesso carico.
Questo perché la mia variante prende in considerazione il tempo medio di tutte le iterazioni per ottenere il prezzo Bid e la sua solo una minuscola frazione con appese anomale.
Chissà per quale motivo il processore si impantana con la funzione regolare (quando il ritardo è superiore a 100 µ) in un "minuto" difficile. Ma ancora il tempo medio è tre volte inferiore per la funzione regolare
Così, per esempio, se (Intervallo##A > 100) questo è il caso:
mentre se (Intervallo##A > 0) è già abbastanza diverso, mostrando una distribuzione casuale di ritardi anomali tra la versione regolare e quella alternativa di ottenere il prezzo Bid
allo stesso tempo il mio test con lo stesso carico di CPU mostra:
Pertanto, penso che la versione di fxsaber del test sia tutt'altro che obiettiva.
Non ho caricato la CPU con gli agenti, ma con questo script. Era più efficiente.
dopo una leggera modifica del test fxsaber per dimostrare chiaramente quale percentuale di iterazioni viene considerata nei calcoli:
cioè circa lo 0,01%.
Ci puoi scommettere.
Se il tempo medio di esecuzione di SymbolInfoDouble(_Symbol, SYMBOL_BID) è di circa 50 nanosecondi, solo quelli con tempo di esecuzione superiore a 100 000 nanosecondi sono presi in considerazione.
dopo una leggera modifica del test fxsaber per dimostrare chiaramente quale percentuale di iterazioni viene considerata nei calcoli:
cioè circa lo 0,01%.
Ci puoi scommettere.
Se il tempo medio di esecuzione di SymbolInfoDouble(_Symbol, SYMBOL_BID) è di circa 50 nanosecondi, vengono contate solo le iterazioni maggiori di 100 000 nanosecondi.
Avremmo potuto semplicemente rendere la condizione non più di 100 µs, ma più di 3 µs. Il risultato è stato apparentemente lo stesso. Il pensiero era che uno studio segmentale e in diverse condizioni di esecuzione ci può essere una differenza in diversi segmenti e in diverse sezioni. Le priorità di esecuzione sono spesso fatte in funzione di qualsiasi cosa. A un carico leggero alcune priorità, a un carico elevato altre, a quelli critici, quelli che non fanno bloccare il computer e crash, e le prestazioni passano in secondo piano.
In generale, il commercio con un carico superiore al 70% dell'hardware non è corretto. È una performance quasi critica. Il carico di ferro sugli EA da combattimento non dovrebbe essere superiore al 60%.
e avete già broker HFT?).
provare a testare SymbolInfoTick quando c'è un solo simbolo nella panoramica del mercato e quando ci sono decine di simboli, ma chiedere un solo strumento - come nel tuo esempio
c'è un'alta probabilità che il server stia inviando traffico compresso e che SymbolInfoTick stia sperimentando questo rallentamento intermittente quando decomprime i dati
cioè, quando ci sono molti simboli, ci saranno cali ancora più frequenti o più profondi nel tempo di prova
Nelle ultime build, la ricezione del flusso di tick non ha alcun effetto, anche teoricamente. In pratica, SymbolInfoTick funziona già con la cache, ma alcuni cittadini continuano a cercare un gatto nero.
Non è nemmeno l'80% nel test. Ci sono 6 agenti in esecuzione su 4 core, cioè garantiti al 100%.
L'unica domanda è come il task scheduler del suo sistema sta gestendo la situazione. Allo stesso tempo, alcuni sostengono che la colpa è dell'implementazione del terminale.
Cioè, si crea artificialmente una situazione in cui un computer è sovraccarico, quando letteralmente tutto su di esso rallenta, e poi si fanno delle affermazioni sotto forma di "Oh, guarda, perché il terminale a volte lagga".
Chiudiamo gli occhi sul fatto che anche in queste condizioni è "circa lo 0,01%" - al diavolo i dettagli! Basta dire che "a nessuno interessa la temperatura media dell'ospedale", "i ritardi causano problemi nel trading" e "vogliamo l'HFT".
Inoltre, ovviamente vogliamo HFT in 20 esperti su un vecchio desktop da ufficio o una macchina virtuale morta.
PS PositionSelectByTicket() nella sua implementazione ha certamente accesso a una risorsa condivisa con sincronizzazione degli accessi. E se non selezioni la posizione su ogni chiamata, stai leggendo il vecchio prezzo. Era più facile "fotografare" tramite SymbolInfoDouble.