Discusión sobre el artículo "Aumente la velocidad de los cálculos con la red en la nube de MQL5"
¿Y la genética? Ahí, "100 veces" es inalcanzable. Bueno, si es 20-30 veces, o incluso menos.
¿Y la genética? Ahí, "100 veces" es inalcanzable. Bueno, si es 20-30 veces, o incluso menos.
https://www.mql5.com/ru/forum/4927/page114
stringo 2012.02.02 15:50
En el cálculo de algoritmo genético toda la siguiente generación (de 64 a 256 trabajos de cálculo) se da a la nube
En una búsqueda completa, se da una pila de 512 trabajos a cada servidor de la nube. A continuación, cuando se completa un determinado número de trabajos, se añade el doble de trabajos (es decir, un servidor en nube informa de que se han completado 5 trabajos, inmediatamente añade 10 trabajos).
por lo que la aceleración del AG no es de 20-30, sino de al menos 64 veces, como máximo 256 veces.
El AG no puede ser más rápido que la enumeración de un número similar de parámetros. El cuello de botella del AG es la espera del agente más lento. Y se produce (de media) de 10240 / 256 a 10240 / 64 veces (de 40 a 160 veces, según los datos de stringo). Y es el agente más lento que determina la velocidad. Además, en el artículo Rosh tenía 4 agentes locales propios -> el límite de speedup para GA puede ser 256 / 4 = 64 veces (esto para hablar de valores comparables), pero en la vida es mucho menor.
Como muchos notaron, los servidores en la nube detectan los agentes lentos automáticamente y redistribuyen los pases "lentos" a otros agentes (tanto en la enumeración completa como en la genética).
Además, los agentes con PR>100 son aceptados en genética, lo que reduce seriamente las consecuencias de usar agentes lentos.
Por lo tanto, las condiciones de prueba - 4 núcleos Intel Core i5-2500 a 3,3 GHz, 4 GB de RAM, Windows XP de 64 bits, terminal x64 bild 581 (PR = 160-180). Durante las pruebas, se estaba ejecutando un navegador y viendo una película. Se utilizaron las mismas condiciones que en el artículo (Moving Avarege Expert Advisor, H1, en OHLC a 1 m. + genética). Configuración:
Prueba en los núcleos locales:
Test on Cloud:
Sin dudarlo, vemos que Cloud contó 8,7 veces más rápido. Eso es todo. Pero, de hecho, la red es aún más lenta porque se utilizó la caché de cálculo.
Así, los núcleos locales realizaron 8704 - 3666 = 5038 pasadas en 30 min. 2 seg = 1802 segundos -> 0,3577 segundos por pasada de media.
La nube realizó 8704 - 4455 = 4249 pasadas en 3 min. 28 seg = 208 segundos -> el tiempo de espera para una pasada de Cloud es de 0,049 segundos de media.
En total, Cloud aceleró el cálculo por un factor de 0,3577 / 0,049 = 7,3 veces (¡!).
Mis suposiciones iniciales de que la cifra probablemente llegaría a 20 veces resultaron ser un poco optimistas. Y ni siquiera podemos hablar de cientos.
Sí, utilicé núcleos potentes, es decir, hice un poco de trampa. Pero el hecho es que incluso esas 4249 pasadas con genética la red hizo en 208 segundos y 14040 pasadas con búsqueda completa en 164 segundos (el tiempo de espera para una pasada es de 0,0117 segundos). Total, las pruebas genéticas de una pasada en Cloud son de media más lentas que la fuerza bruta (en el ejemplo del EA en cuestión) en 0,049 / 0,0177 = 2,8 veces.
No estoy criticando la red - ciertamente Cloud Network es lo mejor que se ha hecho desde que existe el software de trading. Y algo muy necesario (aunque no se utilice mucho, pero eso vendrá con el tiempo).
Me gustaría más corrección en los eslóganes publicitarios. Ok, bygones
Si realiza pruebas con el tiempo de una pasada inferior a un segundo, debe tener en cuenta la latencia de la red, que a menudo es mayor o igual que el tiempo de una tarea "rápida". Hemos hecho muchos esfuerzos para librarnos de la sobrecarga del sistema en la latencia de la red mediante la agrupación de tareas. Y lo hemos conseguido, aunque este problema no se puede vencer por completo.
Tu ejemplo demuestra plenamente que has competido en una lucha a corto plazo con un tiempo de tránsito que se sabe que es inferior al retardo de la red. Para evaluar realmente la potencia de claud, hay que alejarse de las tareas con tiempos de ejecución inferiores a un segundo y acercarse a otras más costosas.
He ejecutado la genética con una tarea similar pero con un tiempo de paso superior a 10 segundos en un procesador i7. Publicaré los resultados al terminar dentro de una hora.
Durante 3 min. 28 segundos de uso de la red, me cobraron 2 o 3 céntimos (en el terminal - 3, en el sitio - 2, y 3 congelados). Que sea 3, o incluso para simplificar, el uso de la red para la genética cuesta 1 centavo por un minuto. Total, una hora son 60 céntimos, 24 horas = 14,4 dólares. Eso me parece muy caro. Los precios deberían reducirse al menos tres veces para hacerlo atractivo a los consumidores (mucha gente prueba EAs, pero no todo el mundo puede/está dispuesto a pagar unos 15$ al día por Cloud, y si fueran 5$ o menos - habría más gente dispuesta).
Además, ya he descubierto por mí mismo cómo preestimar el coste de la optimización de cualquier EA (en promedio, por supuesto). Algoritmo para la genética (de manera similar para la fuerza bruta):
1) Ejecuta la genética Moving Avarage en los núcleos locales (+ también puedes conectar tus agentes remotos); al final, calcula el tiempo de espera de una pasada -> T1
2) Calcula T1 / 0.049 = T2 - cuántas veces se acelera la optimización por genética en Cloud.
3) Ejecute la optimización en los núcleos locales (+ también puede conectar sus agentes remotos; debe estar configurado como en el paso 1) del EA requerido y espere, por ejemplo, 100 pasadas. Calcule el tiempo de una pasada (a través del log - encuentre el primer y último registro) -> T3
4) 10240 * T3 / T2 = T4 -> tiempo estimado de prueba en Cloud.
5) T4 / 60 = coste de las pruebas en céntimos.
(también puede tener en cuenta sus núcleos, para ello utilizamos T2' = T2 + 1).
Todo esto es una estimación basada en la optimización de Moving Avarage. Puede que dentro de uno o dos meses se conecten núcleos más potentes y las cifras cambien, así como el coste.
Creo que mi línea de pensamiento está clara
Tu ejemplo muestra completamente que estabas compitiendo en una lucha a corto plazo con un tiempo de paso que se sabe que es menor que el retardo de la red.
Sí, lo sospechaba, pero no lo tuve en cuenta. Esperemos tus resultados.
Y mi post anterior, párr. 2 tendrá que ser corregido después de tus pruebas.
- 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 Aumente la velocidad de los cálculos con la red en la nube de MQL5:
¿Cuántos procesadores tiene tu ordenador? ¿Cuántos ordenadores puedes usar para optimizar una estrategia de trading? Aquí mostraremos cómo usar la red en la nube de MQL5 para acelerar los cálculos recibiendo la capacidad de procesamiento a través de la red mundial con solo el clic de un ratón. La frase "el tiempo es dinero" se hace más evidente aun con el paso de los años, y no podemos permitirnos esperar para realisar cálculos importantes durante decenas de horas o incluso días.
Autor: MetaQuotes Software Corp.