Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
...
Incluso es difícil imaginar un Asesor Experto de este tipo que carezca de la potencia de un núcleo en la vida real. Por ejemplo, si en el probador el Asesor Experto hace una pasada de un símbolo por día en el historial de un año (¡es demasiado! ¡Tal vez deberíamos reescribir el código!), entonces en la vida real, cargará la CPU en un promedio de 1/250 de potencia = 0,4%.
Para un EA en diez símbolos - se obtiene una carga media del 4%. No tiene mucho sentido cargar los otros núcleos.
En cuanto a la idea de Konstantin(Lizar), me parece buena. Pero para este tipo de solución necesitamos separar los eventos que provienen directamente del gráfico y los que se generan de forma personalizada. Para los eventos personalizados, podemos tener dos colas de eventos y dos manejadores de eventos, algo así como OnUserEvents.
Y una adición interesante a los eventos personalizados sería la capacidad de especificar explícitamente su prioridad (digamos de 0 a 9), lo que podría permitir al usuario controlar la anticipación y el manejo de ciertos eventos. Por ejemplo, una función de este tipo permitiría ejecutar eventos con un valor más bajo, y eliminarlos de la cola con un valor más alto (si la cola está llena de eventos más importantes, no se pondría en cola ninguno nuevo).
Nunca he desarrollado software, así que no puedo hablar el lenguaje técnico de los desarrolladores de software. Voy a describir lo que me gustaría obtener de mi ordenador de 4 núcleos y MT5. En general se ve así:
El manejo de varias herramientas es ahora posible y los desarrolladores crearon una solución perfectamente viable.
2. Sobre el trabajo del probador y un montón de núcleos. Es un caso especial y no es correcto comparar este mecanismo con el comercio real. La esencia de la solución del problema del probador es que teniendo varias variantes de Asesor Experto (o más bien un Asesor Experto + un montón de conjuntos únicos de parámetros) es razonable distribuir los cálculos entre todos los núcleos/agentes disponibles. De este modo, obtenemos asincronía para todo el conjunto de tareas, pero desde el punto de vista de un agente individual todo está sincronizado.
3. Cuando se trata de multithreading, no estamos hablando de procesar múltiples herramientas al mismo tiempo, sino de procesar múltiples eventos al mismo tiempo (y dentro de un único agente específico). Eso no estaba presente en ninguna versión del terminal.
Los desarrolladores también son comprensibles: demasiada sobrecarga, mezcla demasiado "variopinta" de usuarios, demasiados problemas con la sincronización de los datos a los que tendrá acceso un Asesor Experto "multihilo", etc.
Por otro lado, la idea con los eventos no se lleva a su conclusión lógica. Vale, es caro y problemático implementar el "multithreading" pero es posible paralelizar al máximo los procesos y flujos de información dentro del propio terminal + crear un conjunto de manejadores suficientes para resolver el máximo número de tareas (y con un conjunto normal de parámetros).
Mi Asesor Experto en M5, en el período 04.01.2010 - 01.09.2011 en 12 monedas hace una sola pasada en 1436 seg (24 minutos) y al mismo tiempo hace 5687 operaciones. Sólo un núcleo está cargado, los otros tres están inactivos. Es decir, en cada pase individual pierdo 3/4 del tiempo porque la plataforma no utiliza la energía del ordenador. Este es un inconveniente importante de la plataforma a la hora de depurar una estrategia. Los núcleos se utilizan completamente sólo durante la optimización. Pero la optimización es mucho más rara que las carreras individuales. Y se pierde mucho tiempo en carreras individuales.
El planteamiento de "perder 3/4 del tiempo" indica que crees que: usar el multithreading es sólo una oportunidad perdida y un claro fallo de los desarrolladores.
Desgraciadamente, el multithreading en las tareas secuenciales (y una sola pasada del probador es una tarea secuencial) no es gratuito. En realidad, el multihilo tiene enormes pérdidas (a veces múltiples) para la sincronización de procesos. De hecho, todos los accesos a los recursos compartidos tienen que estar ligados a los sincronizadores.
Hemos movido deliberadamente el probador fuera de la terminal a un proceso separado sólo para permitirle trabajar en un solo hilo sin ningún tipo de bloqueo durante el 99% del tiempo de prueba. El resultado fue un aumento significativo de la velocidad.
La sugerencia de "metamos la multitarea en cada EA" proviene de una completa incomprensión del coste (ralentización total) del multithreading en este caso y de las consecuencias (ralentización + volar el techo del 99% de los desarrolladores no profesionales).
Hemos resuelto eficazmente los problemas de aplicación de la multitarea en el terminal, en el probador y hemos permitido un escalado casi ilimitado de la potencia en los modos de agente remoto y de red en la nube MQL5.
Si hay 12 cartas diferentes con distintos personajes, significa que cada personaje de cada carta está obviamente funcionando en su propio hilo sin afectar a los demás.
Si los gráficos empiezan a ralentizarse, la razón es banal: uno de los indicadores es muy poco económico. En este caso, ninguna multitarea ayudará, porque la raíz es obra del programador, que escribe indicadores en la cabeza, sin preocuparse por la eficiencia.
No puedo conseguir el gráfico inverso, algo está mal, la nueva barra de glitches en esta variante
se adjunta el indicador original con el que he estado jugueteando
Por favor, indíqueme cuál es el problema.
Estoy escribiendo un programa multidivisa
Obtengo la manija del indicador MA
Estoy haciendo lo mismo para las 10 monedas restantes permitidas en el Campeonato, pero me da error 4801 durante las pruebas, las 12 monedas están en el historial (creo)
Estoy probando en el gráfico EURUSD
el Asesor Experto está probando GBPUSD (lo he puesto así en la configuración, para optimizarlo)
Por favor, indíqueme cuál es el problema.
Estoy escribiendo un programa multidivisa
Obtengo la manija del indicador MA
Estoy haciendo lo mismo para las 10 monedas restantes permitidas en el Campeonato, pero me da error 4801 durante las pruebas, las 12 monedas están en el historial (creo)
Estoy probando en el gráfico EURUSD
el Asesor Experto está probando GBPUSD (lo he puesto así en la configuración, para optimizarlo)
papaklass:
Ahora contéstame a una pregunta tan simple ....
Responderé de forma aún más sencilla, aunque no sea cortés.
Desgraciadamente, te sales completamente del tema y haces afirmaciones que sólo muestran ideas superficiales sobre los procesos.
Me temo que la mayoría de nuestros argumentos técnicos no se entenderán, ni siquiera el problema básico de la sincronización y la pérdida en su prestación.
Por lo tanto, no es necesario hacer peticiones de "dinos tus argumentos y nosotros especularemos", la situación está perfectamente clara
No encuentro respuestas a estas preguntas para un novato:
1) Cuando se añade un elemento más a un array dinámico, ¿es necesario ampliarlo mediante ArrayResize?
2) ¿Existe una función en MQL5 para eliminar un elemento (uno en medio de un array, por ejemplo) de un array dinámico i? Si no, ¿cuál es la mejor manera de hacerlo?
Como novato, no encuentro respuestas a estas preguntas:
1) Cuando añades otro elemento a un array dinámico, ¿tienes que ampliarlo con ArrayResize?