Teoria dell'accelerazione EA quando si usa un indicatore personalizzato (funzione - iCustom)
Il compilatore può fare molte cose, ma non questo :-)
E questo caso può essere ottimizzato. Primo, l'indicatore stesso dovrebbe essere scritto in modo intelligente (non ricalcolare tutte le barre su ogni tick), secondo, l'indicatore dovrebbe essere super pesante, per rallentare in qualche modo l'EA... Per farla breve...
E qui c'è un articolo interessante su "Ridurre il consumo di memoria degli indicatori ausiliari".
Avevo un Expert Advisor multivaluta che riceveva letture di indicatori per 28 simboli per 8 timeframes.
Erano 28*8=224 copie di indicatori... Ho lottato su come ottimizzare il processo. L'operazione multivaluta ha consumato quasi 700 MB di RAM... Ho risolto facilmente - ho solo impostato un piccolo valore per il campo "Max bars in window" nelle impostazioni del terminale nella scheda "Charts"... Per quanto mi ricordi il minimo per questo campo è di 5 mila barre...
- 2011.03.18
- Andrew
- www.mql5.com
Ho misurato l'aumento del tempo di test di un fattore da 1,2 a 1,3, che è abbastanza insignificante rispetto ai benefici dati dagli indicatori personalizzati.
La conclusione sui 5 buffer è sbagliata. Se i parametri sono gli stessi, verrà caricato un solo indicatore.
Integer:
La conclusione sui 5 buffer non è corretta. Se i parametri sono gli stessi, verrà caricato un solo indicatore.
Sì, sono d'accordo.
Ci saranno 5 chiamate della funzione CopyBuffer() con diversi argomenti (numero di buffer). E la copia dell'indicatore - maniglia - sarà la stessa.
L'autore ha dato un titolo altisonante all'argomento "Teoria dell'accelerazione..." ma non sa nulla delle cose fondamentali.
-Aleks, ci sono molti articoli su questo argomento!
Sì, sono d'accordo.
Ci saranno 5 chiamate alla funzione CopyBuffer() con diversi argomenti (numero di buffer). E ci sarà solo una copia dell'indicatore - maniglia.
L'autore ha dato un titolo altisonante all'argomento "Teoria dell'accelerazione..." ma non sa nulla delle cose fondamentali.
-Aleks-, ci sono molti articoli sul tema dell'indicatore!
Denkir, sto parlando del lavoro dell'EA durante l'ottimizzazione, il numero di candele sul grafico influenza la quantità di calcoli? Ho studiato l'articolo, so che ci sono varianti di ottimizzazione degli indicatori. Tuttavia, in questo caso, voglio credere che l'indicatore sia perfetto ed esaminare il metodo di passaggio dei dati dall'indicatore all'EA. Non sono un programmatore e trovo difficile controllare l'ottimizzazione del codice dell'indicatore - al massimo posso prescrivere in TOR - 1 barra di ritardo e la limitazione della storia per i calcoli.
Ho misurato l'aumento del tempo di test in 1,2 - 1,3 volte, che è assolutamente insignificante rispetto ai benefici forniti dagli indicatori personalizzati.
La mia conclusione sui 5 buffer non è corretta. Se i parametri sono gli stessi, verrà caricato un solo indicatore.
Cosa stavi misurando? E il 30% non è così poco per me.
Riguardo ai 5-buffer, se ho capito bene, allora con gli stessi parametri di input dell'indicatore, il calcolo viene eseguito per un solo indicatore quando l'Expert Advisor chiama l'ultimo più volte e riceve informazioni da diversi buffer?
Se è così, allora la combinazione di indicatori personalizzati dovrebbe accelerare il lavoro dell'Expert Advisor? Per esempio, allora in un indicatore si può implementare la logica di diversi indicatori con impostazioni indipendenti, quando uno di essi viene chiamato, l'informazione di tutti i buffer viene ricevuta in una volta sola e utilizzata nel caso di richiesta di informazione da un altro buffer con gli stessi parametri?
VDev:
Ho provato a misurare la velocità di chiamata degli indici incorporati e dei loro analoghi attraverso iCustom. Quelli integrati sono circa il 20-50% più veloci. Molto probabilmente perché sono scritti in C++ e non in MQL.
Articolo estremamente interessante "Media delle serie di prezzi senza buffer aggiuntivi per i calcoli intermedi " di GODZILLA.
È stato scritto nel 2010.
C'è una sezione 3. Confronto dell'indicatore ottenuto usando le classi con i suoi analoghi con chiamate di indicatori tecnici e personalizzati nel codice
- 2010.10.25
- Nikolay Kositsin
- www.mql5.com
Sì, sono d'accordo.
Ci saranno 5 chiamate alla funzione CopyBuffer() con diversi argomenti (numero di buffer). E ci sarà solo una copia dell'indicatore - maniglia.
L'autore ha chiamato a gran voce l'argomento "Teoria dell'accelerazione..." e non ha la minima idea delle cose fondamentali.
-Aleks-, ci sono molti articoli sul tema dell'indicatore!
E tu puoi semplicemente confutare la mia ipotesi (il 4, preferibilmente), confermando le mie parole con dei numeri?
L'argomento riguarda la mia teoria - il titolo è ok :)
Denkir, sto parlando delle prestazioni dell'EA durante l'ottimizzazione, il numero di candele sul grafico influenza la quantità di calcoli?
-Aleks-, a proposito del tester È necessario chiedere allo sviluppatore ...
Ma penso che ci sia un problema con i termini nella discussione. Vuoi ridurre la velocità dei calcoli o risparmiare la RAM per lavorare con l'indicatore?
-Aleks-, a proposito del tester. Dovete chiedere agli sviluppatori...
Ma per come la vedo io, c'è un problema con i termini nella discussione. Cosa volete, ridurre la velocità dei calcoli o risparmiare la RAM per lavorare con l'indicatore?
Mi sembra che il mio metodo risolva entrambi i problemi. Potrei sbagliarmi.
Quando si ottimizza, la velocità è importante, ma una volta che la RAM è intasata, di nuovo, secondo le mie osservazioni, la velocità di elaborazione per passaggio diminuisce.
Qualcuno può confrontare la velocità di questo approccio, c'è una logica dietro?
Questo approccio ridurrà il consumo di memoria dell'indicatore (circa un multiplo della differenza nel numero di buffer prima e dopo), ma aumenterà il carico sul processore (sia il "montaggio" che la "decomposizione" devono essere fatti costantemente).
E se l'indicatore ha 5 buffer, allora la prima chiamata di iCustom calcolerà tutti i buffer, le chiamate successive e le richieste di altri buffer leggeranno solo le informazioni pronte (fino alla comparsa di nuovi dati per il calcolo).
Se avete un indicatore davvero pesante, pensate a un vostro sistema di cache, in modo che alla prima chiamata i dati siano calcolati e scritti nel file, e alle chiamate successive siano solo letti. L'ho fatto in questo modo, è molto più veloce.
Ma nel 95% dei casi non c'è bisogno di tutto questo, il tester è abbastanza veloce così com'è, e in 5 si può anche collegare il cloud.
Buona fortuna!
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Inizierò dicendo che non sono un programmatore e potrei sbagliarmi, ma mi piacerebbe sentire l'opinione di un professionista sull'idea proposta qui sotto, basata su calcoli.
L'uso di indicatori personalizzati è una questione di attualità quando si sviluppa un Expert Advisor in diverse fasi. È particolarmente importante quando i programmatori si sostituiscono a vicenda, e allora è meglio incollare parte della logica dell'Expert Advisor nell'indicatore - testare la logica (per controllare i calcoli e la loro pertinenza) e poi lavorare su una nuova parte dell'idea. Come risultato, otteniamo un Expert Advisor non molto complesso che richiede effettivamente informazioni dall'indicatore e prende una decisione confrontando i dati attesi e quelli reali.
Ma questo approccio ha uno svantaggio significativo: la velocità di un tale Expert Advisor. Il fatto è che più spesso i dati sono richiesti dagli indicatori personalizzati, più lento è il calcolo e più risorse (memoria) sono richieste per l'ottimizzazione.
Finora lavoro in MT4, ma il principio di questo problema, come lo capisco, è lo stesso.
E il problema non è nella velocità di calcolo dell'indicatore iCustom in sé, ma nella sua connessione con l'Expert Advisor.
Supponiamo che l'indicatore usi 5 buffer del grafico e che l'EA richieda informazioni da quei buffer, allora ha bisogno di usare 5 funzioni iCustom nel suo codice e di mettere effettivamente 5 indicatori sul grafico invece di un indicatore, il che richiede 5 volte più risorse. Forse mi sbaglio, e il compilatore analizza questa circostanza - calcola per un indicatore e dà a tutte le funzioni i dati per i buffer richiesti in una volta sola? In questo caso le mie ulteriori speculazioni sono vane.
Ma, se non è così, perché non unire le informazioni dell'indicatore in un unico pacchetto?
Propongo di fare un esperimento su questo argomento con la misurazione delle prestazioni dell'Expert Advisor.
Questo richiederà di prendere un indicatore personalizzato con più di 1 buffer e aggiungere un buffer aggiuntivo.
L'algoritmo è logico (non matematico):
1. Convertire i buffer nell'indicatore in numeri interi, a seconda delle cifre per numero, un totale di 3 buffer, era: 1,21101; 1,13; 5, è diventato: 121101;113;5
2. Contiamo quante cifre mettere dopo il primo numero - nel nostro caso 4, poi nel numero successivo quello successivo - 1, questi valori sono il grado del moltiplicatore:
1,21101*10^4=1211010000
1.13*10^1=113
5*10^0=5 (controllare lo 0)
3. Somma i numeri e ottieni 1211011135.
4. Scrivere il valore nel 4. buffer
5. Richiediamo il buffer di 4 indicatori nell'Expert Advisor e scomponiamo il valore in componenti in ordine inverso e otteniamo 3 cifre che possono essere ulteriormente utilizzate per il lavoro dell'Expert Advisor.
Qualcuno può confrontare la velocità di questo approccio, c'è una logica dietro?