Discussione sull’articolo "Diminuzione del consumo di memoria tramite indicatori ausiliari"

 

Il nuovo articolo Diminuzione del consumo di memoria tramite indicatori ausiliari è stato pubblicato:

Se un indicatore utilizza i valori di molti altri indicatori per i suoi calcoli, consuma molta memoria. L'articolo descrive diversi metodi per ridurre il consumo di memoria quando si utilizzano indicatori ausiliari. La memoria salvata consente di aumentare il numero di coppie di valute, indicatori e strategie utilizzate contemporaneamente nel terminale del cliente. Aumenta l'affidabilità del portafoglio. Una così semplice cura delle risorse tecniche del tuo computer può trasformarsi in risorse monetarie sul tuo deposito.

Probabilmente, hai già utilizzato o creato Expert Advisor o indicatori che utilizzano altri indicatori ausiliari per il loro funzionamento.

Ad esempio, il famoso indicatore MACD utilizza due copie dell'indicatore EMA (Exponential Moving Average) calcolando la differenza tra i loro valori:


Un tale indicatore composito è equivalente ad altri diversi e semplici, infatti. Ad esempio, il MACD menzionato in precedenza consuma la memoria e il tempo del processore tre volte più del singolo EMA, poiché deve allocare memoria per i buffer dell'indicatore principale e per i buffer di tutti i suoi indicatori ausiliari.

Autore: ds2

 

L'approccio è comprensibile. Ma la rilevanza del compito è confusa.

Mentre un sistema a 64 bit supporta enormi quantità di RAM, la rilevanza del compito impallidisce. Persino un sistema a 32 bit, con i suoi 3 Gb, è in grado di gestire una quantità di memoria come quella che si sta risparmiando. Dopotutto, a prescindere da come la si guardi, la memoria cresce linearmente quando si caricano nuovi indicatori, il che significa che 48 MB in più o in meno per i computer moderni non sono nulla.

Ok, supponiamo che il compito sia rilevante (sono d'accordo sul fatto che ci sono persone che se ne preoccupano). Ma pensateci bene, il compito di risparmiare memoria è in diretto conflitto con il compito delle prestazioni.

Quindi dovreste prestare attenzione anche a questo punto.

Per quanto posso vedere dal mio punto di vista, gli MQ combattono per le prestazioni ed è lì che si concentrano tutti gli sforzi.

Se avete bisogno di risparmiare risorse di memoria sugli indicatori non disegnati, trasferite il codice dell'indicatore nell'Expert Advisor. Qui avrete il pieno controllo della memoria allocata. Allo stesso tempo, potrete risparmiare sulla ricezione dello stesso tipo di dati. Molti indicatori richiedono gli stessi dati, ciascuno per la propria elaborazione. Avendo ricevuto i dati una volta, non sarà necessario affrontarli in seguito.

Ora combiniamo la velocità delle operazioni e la dimensione della memoria. La maggior parte degli indicatori che non disegnano sono impegnati nel calcolo dell'ultima barra, come indicano i meccanismi integrati che bloccano il ricalcolo dell'intero array. Risulta che nell'Expert Advisor sarà possibile allocare 154 celle di memoria (ad esempio, per il calcolo della maschera con il periodo di 153) con tale risparmio di memoria le prestazioni non saranno peggiori di quelle di un indicatore regolare.

Ma la possibilità di parallelizzare i calcoli viene meno nell'Expert Advisor, e questo è un colpo diretto alle prestazioni. In realtà, gli indicatori consumano memoria proprio a causa del parallelismo. Dopo tutto, ogni indicatore lavora in un proprio thread e questo thread deve avere la propria istanza di dati sorgente.

Документация по MQL5: Основы языка / Переменные
Документация по MQL5: Основы языка / Переменные
  • www.mql5.com
Основы языка / Переменные - Документация по MQL5
[Eliminato]  

Sono d'accordo, le prestazioni sono la priorità principale e non ha senso risparmiare memoria (a meno che non si utilizzi più di 1Gb, il che è improbabile).

 
Urain:

L'approccio è comprensibile. Ma l'urgenza del compito è confusa.

In realtà, l'idea di scrivere questo articolo mi è venuta in mente dopo che una persona, per la quale ho scritto un certo indicatore composto, si è lamentata del fatto che questo indicatore non veniva installato su alcune coppie. Indagando, si è scoperto che ci sono indicatori molto persistenti, e molti di essi non si adattano al terminale (cioè, il problema non era nella coppia, ma nel fatto che prima di questa coppia ne erano state aperte altre decine con lo stesso indicatore persistente). Quell'indicatore consumava 2 volte di più dell'indicatore di prova riportato nell'articolo.

Anche il 32-bit con i suoi 3GB è in grado di gestire una tale quantità di memoria.

Se si opera su un gran numero di coppie, non è così, questo è il punto.

A proposito, il terminale non può allocare più di 2 Gb di memoria (in totale: RAM + memoria virtuale). Nei miei esperimenti si è chiuso a questo punto.

Naturalmente, questo problema non dovrebbe esistere a 64 bit.

Ok, supponiamo che il compito sia rilevante (sono d'accordo che ci sono persone che se ne preoccupano). Ma pensateci, il compito di risparmiare memoria è in diretta contraddizione con il compito delle prestazioni.

Non sempre. Nell'articolo, qui, la maggior parte dei metodi non riduce le prestazioni.

Se è necessario risparmiare risorse di memoria sugli indicatori non disegnabili, basta spostare il codice dell'indicatore nell'Expert Advisor.

Un Expert Advisor che richiede solo l'ultima barra agli indicatori è un programma diverso da quello considerato nell'articolo. E non sempre è possibile/conveniente sostituire l'uno con l'altro.

Ma in un Expert Advisor si perde la possibilità di parallelizzare i calcoli e questo è un colpo diretto alle prestazioni. In realtà, gli indicatori consumano memoria proprio a causa del parallelismo. Dopo tutto, ogni indicatore lavora in un proprio thread e questo thread deve avere la propria istanza di dati sorgente.
.

È improbabile che ogni indicatore su una coppia comune abbia la propria istanza di dati - nell'articolo sui calcoli paralleli è riportata una tabella interessante, che può essere trovata con la frase chiave "2 indicatori".

 
ds2:

Il problema degli indicatori è che ognuno di essi lavora nel proprio thread e per funzionare deve memorizzare tutti i dati necessari nel thread stesso.

I dati tra i thread vengono copiati tramite CopyBuffer(). Ma il problema è questo: è possibile ottenere i dati da un thread, ma non è possibile trasferirli lì. Ecco perché non è possibile costruire indicatori mogostage in cui diverse istanze di un indicatore ricevono gli stessi dati pre-elaborati. Ma proprio in questo piano possono nascondersi grandi opportunità di ottimizzazione dei calcoli.

Credo che se MQ risolverà questo problema, il lavoro con gli indicatori diventerà più comodo e flessibile. Ora i dati possono essere passati solo come parametri esterni e solo all'inizio del thread.



Как написать индикатор в MQL5
Как написать индикатор в MQL5
  • 2010.01.12
  • MetaQuotes Software Corp.
  • www.mql5.com
Что представляет собою индикатор? Это набор вычисленных значений, которые мы хотим отобразить на экране монитора удобным для нас образом. Наборы значений представляются в программах в виде массивов. Таким образом, создание индикатора - это написание алгоритма, который обрабатывает одни массивы (массивы цен) и записывает результаты обработки в другие массивы (значения индикаторов). На примере создания индикатора True Strength Index в статье рассказывается, как писать индикаторы на MQL5
 

Molto utile

Quindi, se ho capito bene il flusso di idee principali, mi sorge una domanda:

perché tutti gli indicatori standard presenti nell'installazione di MT5 non sono progettati come "classe"?

Allora perché il master wizard non si preoccupa di questa idea?

 

senza limitare le barre massime da Strumenti> Opzioni, un modo rapido che uso per ridurre lo spazio del buffer è

int maxbars =100;// ultime battute
limit = rates_total-rates_total+maxbars;