Teoría de la aceleración del EA cuando se utiliza un indicador personalizado (función - iCustom)
El compilador puede hacer muchas cosas, pero no eso :-)
Y este caso se puede optimizar. En primer lugar, el indicador en sí debe ser escrito de forma inteligente (no recalcular todas las barras en cada tick), en segundo lugar, el indicador debe ser súper pesado, para de alguna manera ralentizar el EA... Para resumir la historia...
Y aquí hay un interesante artículo sobre "Reducción del consumo de memoria de los indicadores auxiliares".
Tenía un Asesor Experto multidivisa que recibía lecturas de indicadores para 28 símbolos para 8 marcos temporales.
Fueron 28*8=224 copias de indicadores... Me esforcé por optimizar el proceso. La operación multidivisa consumió casi 700 MB de RAM... Lo resolví fácilmente: sólo puse el campo "Barras máximas en la ventana" en la configuración del terminal en la pestaña "Gráficos" a un valor pequeño... Que yo recuerde el mínimo para este campo es de 5 mil barras...
- 2011.03.18
- Andrew
- www.mql5.com
He medido el aumento del tiempo de prueba en un factor de 1,2 a 1,3, lo cual es bastante insignificante en comparación con las ventajas que ofrecen los indicadores personalizados.
La conclusión sobre los 5 buffers es errónea. Si los parámetros son los mismos, sólo se cargará un indicador.
Integer:
La conclusión sobre los 5 topes es incorrecta. Si los parámetros son los mismos, sólo se cargará un indicador.
Sí, estoy de acuerdo.
Habrá 5 llamadas a la función CopyBuffer() con diferentes argumentos (número de buffer). Y la copia del indicador - mango - será la misma.
El autor tituló el tema a bombo y platillo "Teoría de la aceleración..." pero no tiene ni idea de lo básico.
-Aleks, ¡hay muchos artículos sobre este tema!
Sí, estoy de acuerdo.
Habrá 5 llamadas a la función CopyBuffer() con diferentes argumentos (número de buffer). Y sólo habrá una copia del indicador - mango.
El autor tituló el tema a bombo y platillo "Teoría de la aceleración..." pero no tiene ni idea de lo básico.
-Aleks-, ¡hay muchos artículos sobre el tema de los indicadores!
Denkir, me refiero al trabajo del EA durante la optimización, ¿el número de velas en el gráfico afecta a la cantidad de cálculos? He estudiado el artículo, sé que hay variantes de optimización de indicadores. Sin embargo, en este caso, quiero creer que el indicador es perfecto y examinar el método de pasar los datos del indicador al EA. No soy un programador y me resulta difícil comprobar la optimización del código del indicador - como mucho puedo prescribir en TOR - 1 barra de retraso y la limitación de la historia para los cálculos.
He medido, el aumento del tiempo de prueba en 1,2 - 1,3 veces, que es absolutamente insignificante en comparación con los beneficios proporcionados por los indicadores personalizados.
Mi conclusión sobre los 5 buffers no es correcta. Si los parámetros son los mismos, sólo se cargará un indicador.
¿Qué estabas midiendo? Y el 30% no es tan poco para mí.
Sobre los 5 buffers, si te he entendido bien, entonces con los mismos parámetros de entrada del indicador, el cálculo se realiza para un solo indicador cuando el Asesor Experto llama al último varias veces y obtiene información de diferentes buffers?
Si es así, ¿la combinación de indicadores personalizados debería acelerar el trabajo del Asesor Experto? Por ejemplo, ¿entonces en un indicador se puede implementar la lógica de diferentes indicadores con configuraciones independientes, cuando se llama a cualquiera de ellos, la información de todos los buffers se recibe a la vez y se utiliza en caso de solicitud de información de otro buffer con los mismos parámetros?
VDev:
He tratado de medir la velocidad de llamada de los índices incrustados y sus análogos a través de iCustom. Las incorporadas son un 20-50% más rápidas. Probablemente porque están escritos en C++ y no en MQL.
Interesantísimo artículo "Promedio de series de precios sin topes adicionales para cálculos intermedios " de GODZILLA.
Fue escrito en 2010.
Hay una sección 3. Comparación del indicador obtenido usando clases con sus análogos con llamadas de indicadores técnicos y personalizados en el código
- 2010.10.25
- Nikolay Kositsin
- www.mql5.com
Sí, estoy de acuerdo.
Habrá 5 llamadas a la función CopyBuffer() con diferentes argumentos (número de buffer). Y sólo habrá una copia del indicador - mango.
El autor llamó a gritos al tema "Teoría de la aceleración..." y no tiene ni idea de lo básico.
-Aleks-, ¡hay muchos artículos sobre el tema de los indicadores!
¿Y puedes simplemente refutar mi hipótesis (sobre el 4, preferiblemente), confirmando mis palabras con números?
El tema es sobre mi teoría - el título está bien :)
Denkir, me refiero al rendimiento del EA durante la optimización, ¿el número de velas en el gráfico afecta a la cantidad de cálculos que hay?
-Aleks-, sobre el probador Tienes que pedirle al desarrollador...
Pero creo que hay un problema con los términos de la discusión. ¿Qué quieres, reducir la velocidad de los cálculos o ahorrar memoria RAM para trabajar con el indicador?
-Aleks-, sobre el probador. Tienes que preguntar a los desarrolladores...
Pero tal y como yo lo veo, hay un problema con los términos de la discusión. ¿Qué quieres, reducir la velocidad de los cálculos o ahorrar RAM para trabajar con el indicador?
Me parece que mi método resolverá estos dos problemas. Puede que me equivoque.
Cuando se optimiza, la velocidad es importante, pero una vez que la RAM está obstruida, de nuevo, según mis observaciones, la velocidad de procesamiento por pasada disminuye.
¿Puede alguien comparar la velocidad de este enfoque, hay una razón detrás de él?
Este enfoque reducirá el consumo de memoria del indicador (aproximadamente un múltiplo de la diferencia en el número de búferes antes y después), pero aumentará la carga del procesador (tanto el "ensamblaje" como la "descomposición" deben realizarse constantemente).
Y si el indicador tiene 5 búferes, entonces la primera llamada de iCustom calculará todos los búferes, las siguientes llamadas y solicitudes de otros búferes sólo leerán la información lista (hasta la aparición de nuevos datos para el cálculo).
Si tiene un indicador muy pesado, piense en su propio sistema de caché, de modo que en la primera llamada los datos se calculen y se escriban en el archivo, y en las siguientes llamadas sean sólo de lectura. Yo lo he hecho así, es mucho más rápido.
Pero en el 95% de los casos no hace falta todo eso, el probador es lo suficientemente rápido como es, y en el 5 también puedes conectar la nube.
Buena suerte.
- 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
Empezaré diciendo que no soy programador y puedo estar equivocado, pero me gustaría conocer la opinión de un profesional sobre la idea que se sugiere a continuación, basada en cálculos.
El uso de indicadores personalizados es un tema de actualidad cuando se desarrolla un Asesor Experto en varias etapas. Es especialmente importante cuando los programadores se sustituyen, y entonces es mejor pegar parte de la lógica del Asesor Experto en el indicador - probar la lógica (para comprobar los cálculos y su relevancia) y luego trabajar en una nueva parte de la idea. Como resultado, obtenemos un Asesor Experto no muy complejo que realmente solicita información al indicador y toma una decisión comparando los datos esperados y los reales.
Pero, este enfoque tiene una desventaja significativa - la velocidad de tal Asesor Experto. El hecho es que cuanto más a menudo se solicitan los datos de los indicadores personalizados, más lento es el cálculo y más recursos (memoria) se requieren para la optimización.
Hasta ahora trabajo en MT4, pero el principio, según entiendo, es el mismo.
Y el problema no está en la velocidad de cálculo del indicador iCustom en sí, sino en su conexión con el Asesor Experto.
Supongamos que el indicador utiliza 5 buffers del gráfico y el EA requiere información de esos buffers, entonces necesita utilizar 5 funciones iCustom en su código y realmente poner 5 indicadores en el gráfico en lugar de un indicador, lo que requiere 5 veces más recursos. Tal vez me equivoque y el compilador analice esta circunstancia: ¿calcula para un indicador y da los datos de los búferes necesarios a todas las funciones a la vez? En ese caso, mis especulaciones adicionales son vanas.
Pero, si no es así, ¿por qué no fusionar la información del indicador en un solo paquete?
Me propongo hacer un experimento sobre este tema con la medición del rendimiento del Asesor Experto.
Esto requerirá tomar un indicador personalizado con más de 1 búfer y añadir un búfer adicional.
El algoritmo es lógico (no matemático):
1. Convertir los topes del indicador en enteros, según los dígitos por número, un total de 3 topes, era: 1,21101; 1,13; 5, se convirtió en: 121101;113;5
2. Contamos cuántos dígitos poner después del primer número - en nuestro caso 4, luego en el siguiente número el siguiente número es 1, estos valores son el grado del multiplicador:
1,21101*10^4=1211010000
1.13*10^1=113
5*10^0=5 (comprobar el 0)
3. Suma los números y obtén 1211011135.
4. Escribe el valor en el 4. buffer
5. Solicitamos el buffer de 4 indicadores en el Asesor Experto y descomponemos el valor en componentes en orden inverso y obtenemos 3 cifras que pueden ser utilizadas posteriormente para el trabajo del Asesor Experto.
¿Puede alguien comparar la velocidad de este enfoque, hay una razón detrás de él?