Discusión sobre el artículo "Cómo reducir el gasto de memoria en los indicadores auxiliares"
El planteamiento es comprensible. Pero la relevancia de la tarea es confusa.
Mientras que un sistema de 64 bits soporta enormes cantidades de RAM, la relevancia de la tarea palidece. Incluso 32 bits con sus 3 Gb puede tirar bastante de tamaños de memoria como el que estás ahorrando. Después de todo, se mire como se mire, la memoria crece linealmente al cargar nuevos indicadores, lo que significa que 48 MB más o menos para los ordenadores modernos no es nada.
Vale, supongamos que la tarea es relevante (estoy de acuerdo en que hay gente a la que le interesa). Pero piénsalo, la tarea de ahorrar memoria está en conflicto directo con la tarea del rendimiento.
Así que también deberías prestar atención a este punto.
Por lo que veo desde mi atalaya, las MQ luchan por el rendimiento y ahí es donde se concentran todos los esfuerzos.
Si necesita ahorrar recursos de memoria en indicadores no dibujados, simplemente transfiera el código del indicador al Asesor Experto. Aquí tendrá un control total sobre la memoria asignada. Al mismo tiempo, podrá ahorrar en la recepción del mismo tipo de datos. Muchos indicadores solicitan los mismos datos cada uno para su propio procesamiento. Habiendo recibido los datos una vez, no necesitará tratarlos en la siguiente ocasión.
Ahora combinemos la velocidad de las tareas y el tamaño de la memoria. La mayoría de los indicadores que no son de dibujo se dedican al cálculo de la última barra, esto es indicado por los mecanismos incorporados de bloqueo del recálculo de toda la matriz. Resulta que en el Asesor Experto será posible asignar 154 celdas de memoria (por ejemplo, para el cálculo de la máscara con el período de 153) con tal ahorro de memoria el rendimiento no será peor que en un indicador regular.
Pero la posibilidad de paralelizar los cálculos se pierde en el Asesor Experto, y esto es un golpe directo bajo el cinturón al rendimiento. En realidad, los indicadores consumen memoria sólo por el paralelismo. Después de todo, cada indicador trabaja en su propio hilo y este hilo debe tener su propia instancia de datos de origen.
- www.mql5.com
El planteamiento es comprensible. Pero la urgencia de la tarea es confusa.
Bueno, en realidad, la idea de escribir este artículo me vino a la mente después de que una persona, a la que escribí un cierto indicador compuesto, se quejara de que este indicador no se instalaba en algunos pares. Al investigar, resultó que hay indicadores muy persistentes, y muchos de ellos no caben en el terminal (es decir, el problema no estaba en el par, sino en el hecho de que antes de este par se abrió una docena más con el mismo indicador persistente). Ese indicador consumía 2 veces más que el indicador de prueba del artículo.
Incluso 32-bit con sus 3GB puede tirar bastante tales tamaños de memoria
Si el comercio en un gran número de pares, no lo hace, ese es el punto.
Por cierto, el terminal no puede asignar más de 2 Gb de memoria (en total: RAM + memoria virtual). En mis experimentos se cerraba en esta marca.
Por supuesto, este problema no debería existir en 64 bits.
OK, supongamos que la tarea es relevante (estoy de acuerdo en que hay gente a la que le importa). Pero piénsalo, la tarea de ahorrar memoria contradice directamente la tarea de rendimiento.
No siempre es así. En el artículo, aquí, la mayoría de los métodos no reducen el rendimiento.
Un Asesor Experto que solicita sólo la última barra de los indicadores es una clase diferente de programa que el considerado en el artículo. Y no siempre es posible/conveniente sustituir uno por otro.
.
Es poco probable que cada indicador en un par común tenga su propia instancia de datos - hay una tabla interesante en el artículo sobre cálculos paralelos, que se puede encontrar por la frase clave "2 indicadores".
El problema de los indicadores es que cada uno de ellos trabaja en su propio hilo y para funcionar debe almacenar todos los datos necesarios en el propio hilo.
Los datos entre hilos se copian mediante CopyBuffer(). Pero aquí está el problema: puedes obtener datos de un hilo, pero no puedes transferirlos allí. Por eso no se pueden construir indicadores mogostage en los que varias instancias de un indicador reciban los mismos datos preprocesados. Pero en este mismo plano pueden residir grandes oportunidades de optimización de los cálculos.
Creo que si MQ resuelve este problema, el trabajo con indicadores será más cómodo y flexible. Ahora los datos sólo pueden ser pasados como parámetros externos y sólo al inicio del hilo.
- 2010.01.12
- MetaQuotes Software Corp.
- www.mql5.com
Muy útil
asi que si entiendo correctamente la corriente de la idea principal, me surge una pregunta
¿por qué todos los indicadores estándar que se encuentran en la instalación MT5 no están diseñados como "clase"?
Entonces ¿por qué maestro asistente no se preocupan de tal idea?
sin limitar las barras máximas desde Herramientas> opciones, una forma rápida que utilizo para reducir el espacio del búfer es
int maxbars =100;// últimos compases limit = rates_total-rates_total+maxbars;
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Cómo reducir el gasto de memoria en los indicadores auxiliares:
Si el indicador implica en sus cálculos los valores de muchos otros indicadores, este tipo de sistema gastará mucha memoria. En el artículo veremos varias maneras de reducir el gasto de memoria al usar los indicadores auxiliares. La memoria ahorrada le permitirá aumentar el número de parejas de divisas, de indicadores y estrategias usadas de manera simultánea en el terminal, incrementando así la fiabilidad de su portfolio comercial. De este modo, esta pequeña gestión de los recursos de su computadora es capaz de convertirse en recursos materiales para su propio uso.
Autor: Andrew