MT5 y la velocidad en acción - página 16
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
Sería interesante comparar el mismo script con otras plataformas de trading.
MT4 b1280.
Sólo tres resbalones y luego muy raramente aparecieron. Probablemente es difícil crear un freno ya que no hay HistorySelect y CopyTicks.
por lo que ambos son Haswell, xeon tiene una frecuencia de funcionamiento mucho más baja, habrá una degradación del rendimiento en las pruebas de rendimiento y simple, sólo en la optimización multihilo será una ventaja. El i3 de los últimos modelos debería ser mucho más rápido de ejecutar
pregunte a los desarrolladores sobre el efecto del nivel de caché en la velocidad y, en general, la velocidad de Zen2 y los últimos Intel
añadir
Ryzen 3700x que tengo, puedes hacer pruebas con Intel
por ejemplo con este script MQL5\Scripts\UnitTests\Stat\TestBenchmark.mq5
hacer un bucle varias veces con un temporizador
No estamos hablando de pruebas, sino de retrasos en la ejecución de órdenes. Este retraso está ahí y es flotante. Y eso nos molesta bastante tanto al TS como a mí.
Sólo aparecieron tres cosas y muy pocas veces. Debe ser difícil crear un freno ya que no hay HistorySelect y CopyTicks.
Esperado en MT4 también.
TimeLocal en 36 milisegundos. Elija un símbolo con un volumen de ticks mayor.
Para quien esté interesado, aquí están las instrucciones de reproducción.
Que piensa que no se va a tocar.
Escogió un símbolo con un volumen de ticks mayor.
Ni siquiera voy a comprobarlo. Imagine el símbolo más popular de FORTS con una suscripción de garrapatas. En lugar de la lógica OnTick en OnBookEvent. Los retrasos deben ser terribles.
Necesito asesoramiento oficial sobre qué hacer para minimizar los retrasos.
Para reproducir los frenos, es necesario ejecutar el script en múltiples caracteres de UN carácter - conseguir que OnTick sea llamado al mismo tiempo. Entonces, las alertas se activarán en cada tic.
El gráfico de carga de la CPU muestra que terminal64.exe carga hasta el 30% de los ocho núcleos lógicos. Son sólo cuatro gráficos de EURUSD con el script en funcionamiento. Puedes ver claramente cuánto se carga cada gráfico a la vez.
¿Adónde van a parar tantos recursos?
Esta pregunta es fácil de responder.
Aquí se copian muchos datos:
En realidad está dando un comando para tomar todo el historial de operaciones disponible de la base de datos de la terminal en el entorno del EA, para su uso posterior. Está tratando de hacer funcionar a propósito un posible algoritmo de almacenamiento en caché de peticiones idénticas.
Pero no se utilizan todos estos datos, sino que se restablecen inmediatamente en la línea siguiente:
Obviamente, la base del terminal es aquí un recurso compartido con acceso sincronizado. Y usted ha creado deliberadamente miles de pedidos y tratos en él.
Toda esta acción sin sentido se repite 10 veces con cada tic de varios hilos a la vez. Y estás haciendo deliberadamente que estas acciones ocurran simultáneamente desde varios hilos.
Así que usted sabe muy bien lo que está haciendo y por qué, dónde se gastan los recursos, y al mismo tiempo afirma que "el retraso se debe a la excesiva carga de la CPU por parte de MT5".
Dicho esto, está claro que tienes un problema con tu ordenador. Es decir, sí, está moviendo activamente cantidades significativas de memoria, pero no debería afectar al tiempo de ejecución de las funciones, especialmente las no relacionadas con HistorySelect() de ninguna manera.
En nuestras pruebas b2582, incluso con 1000 veces por tick y 5 EAs en gráficos de un carácter, es decir, órdenes de magnitud mayores que sus condiciones por defecto, no se observó ni una sola Alerta.
Nuestro sistema de prueba: Windows 10 build 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
Esta pregunta es fácil de responder.
Aquí es donde se copian muchos datos:
En realidad está dando un comando para tomar todo el historial de operaciones disponible de la base de datos de la terminal en el entorno del EA, para su uso posterior. Intentar aleatoriamente perturbar el posible algoritmo de almacenamiento en caché de peticiones idénticas.
Pero no se utilizan todos estos datos, sino que se restablecen inmediatamente en la línea siguiente:
Obviamente, la base del terminal es aquí un recurso compartido con acceso sincronizado. Y usted ha creado deliberadamente miles de pedidos y tratos en él.
Toda esta acción sin sentido se repite 10 veces con cada tic de varios hilos a la vez. Y estás haciendo deliberadamente que estas acciones ocurran simultáneamente desde varios hilos.
Así que usted sabe muy bien lo que está haciendo y por qué, dónde se gastan los recursos, y al mismo tiempo afirma que "el retraso se debe a la excesiva carga de la CPU por parte de MT5".
Dicho esto, está claro que tienes un problema con tu ordenador. Es decir, sí, está moviendo activamente cantidades significativas de memoria, pero no debería afectar al tiempo de ejecución de las funciones, especialmente las no relacionadas con HistorySelect() de ninguna manera.
En nuestras pruebas b2582, incluso con 1000 veces por tick y 5 EAs en gráficos de un carácter, es decir, órdenes de magnitud mayores que sus condiciones por defecto, no se observó ni una sola Alerta.
Nuestro sistema de prueba: Windows 10 build 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
Colegas,
es hora de que salgas del círculo del modelismo aeronáutico.
Estas son las condiciones de la batalla: 4 terminales, unos 300 Asesores Expertos, unos 30 instrumentos. Un tercio de ellos están abonados a los bombos. Todo esto en FORTS. Simular en estas condiciones.
Colegas,
es hora de que salgas del círculo del modelismo aeronáutico.
Estas son las condiciones de combate: 4 terminales, unos 300 EAs, unos 30 instrumentos. Un tercio de los EA están suscritos a los bombos. Todo esto en FORTS. Simular en estas condiciones.
"Aquí tienes" se acepta como un archivo zip, además de una descripción detallada del problema. De lo contrario, es una conversación vacía.
Lo que se discute aquí es el código del EA presentado y la eficacia de su ejecución. A partir de los problemas detectados, se ha trabajado en la optimización del código del terminal.
"Aquí tienes" se acepta como un archivo zip, además de una descripción detallada del problema. De lo contrario, es una conversación vacía.
En este caso, la discusión se centra en el código presentado por el EA y la eficiencia de su ejecución. El código del terminal ha sido optimizado para los problemas identificados.
No tengo ningún problema, no hay nada que enviar.
fxsaber tiene problemas, ya escribió 16 páginas aquí.
Y Mikhail tiene los mismos problemas desde 2014, ya ha escrito 149 páginas: https://www.mql5.com/ru/forum/38456/page149.
Ambos están lo suficientemente cualificados para darte toda la información que necesitas.
Esta pregunta es fácil de responder.
Aquí es donde se copian muchos datos:
En realidad, está dando un comando para tomar todo el historial de operaciones disponible de la base de datos del terminal en el entorno del EA, para su uso posterior. Aleatorizar a propósito tratando de desbaratar el posible algoritmo de almacenamiento en caché de peticiones idénticas.
No has seguido la cronología del desarrollo de este hilo, por lo que te permites notas acusatorias en tus afirmaciones.
He eliminado la línea MathRand. Este es un breve registro.
Pero no utilizas todos estos datos, sino que los vuelcas inmediatamente en la siguiente línea:
Obviamente, la base del terminal es aquí un recurso compartido con acceso sincronizado. Y usted ha creado deliberadamente miles de pedidos y tratos en él.
Lo pruebo en cuentas reales donde las órdenes de más de 10K son la norma. No se trata de órdenes falsas, ya que el 70% de ellas se ejecutaron.
En la captura de pantalla, por cierto, 9331+576 != 12529.
Toda esta acción sin sentido se repite 10 veces en cada tic de varios hilos a la vez. Y usted está haciendo deliberadamente que estas acciones de múltiples hilos ocurran simultáneamente.
Estoy teniendo problemas en diferentes personajes. Se sugiere un único símbolo para reproducir el problema más rápidamente.
Repetir 10 veces en cada tic es una necesidad vital. Ya que es normal que un EA contenga una docena de CTs con diferentes especialidades.
Así que sabes muy bien lo que haces y por qué, y a dónde van los recursos, y sin embargo afirmas que "La latencia se debe a la excesiva carga de la CPU por parte de MT5".
Dicho esto, está claro que tienes un problema con tu ordenador. Es decir, sí, estás moviendo activamente cantidades significativas de memoria, pero no debería afectar al tiempo de ejecución de las funciones, especialmente no relacionadas con HistorySelect() de ninguna manera.
No puedo acusarle de incompetencia, pero lo que ha escrito, por decirlo suavemente, causa desconcierto. HistorySelect es el hallazgo de cuatro índices (principio/fin para la tabla de pedidos y principio/fin para la tabla de operaciones). Las tablas están ordenadas por tiempo, por lo que hay (debería haber) una búsqueda binaria en el peor de los casos. Para las órdenes de 10K es instantáneo (calcular el logaritmo binario). ¡Qué movimiento de volumen de memoria! Aquí nadie habla del temido HistorySelectByPosition. El elemental HistorySelect se ve afectado.
En nuestras pruebas b2582, incluso con 1000 veces por tick y 5 EAs en gráficos de un carácter, es decir, órdenes de magnitud mayores que sus condiciones por defecto, no se observa ni una sola Alerta.
Nuestro sistema de prueba: Windows 10 build 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
Indique aquí los datos de acceso a la cuenta de operaciones en la que se realizaron las pruebas.