MT5 y la velocidad en acción - página 61
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
Creo que este muro MQ no saldrá adelante sin el apoyo de los miembros del foro. El código es corto, los profesionales deberían ser capaces de resolverlo rápidamente. No hay ningún defecto. Se muestra claramente que los precios a través de las posiciones se obtienen mucho más rápido que a partir de Market Watch. Cómo MQ no puede ver lo obvio, no lo entiendo.
1. Su prueba realmente cuenta un micro porcentaje de iteraciones debido a la condición
En esencia, sólo se cuentan las anomalías en las que el procesador se sobrecarga de tareas y pospone la realización de la tarea dada en el estante lejano, ya que más del 99% de las iteraciones se realizan en menos de 1 microsegundo.
E incluso si se establece la condición >0, sigue sin haber objetividad.
2. La medición del tiempo de estas operaciones rápidas sólo debe hacerse como tiempo de ciclo completo, no de una sola iteración.
3. Pero como el ciclo en su ejemplo está limitado a 10 segundos (¡Por qué! Para los ticks creo que 0,1 segundos es suficiente. Porque bien puede ocurrir que lleguen 3 ticks en un segundo, y que los tres ticks se ejecuten durante 10 segundos cada uno, y en paralelo), por lo que no es necesario temporizar. Es más fácil calcular cuántas iteraciones se ejecutarán en un tiempo determinado. Cuanto más, más productividad.
He modificado su código "un poco". Creo que mi variante refleja mejor la realidad.
El cálculo se hace de uno en uno, para no mezclar las dos variantes. Los números pares son paraSYMBOL_BID, los impares - para GetBid().
He añadido sumas y su salida por si acaso, como un intento de engañar al compilador contra la optimización.
El resultado de la salida es acumulativo.
Mi resultado:
Como puedes ver, la diferencia de rendimiento es tres veces mayor a favor de la versión estándar.
Como puede ver, la diferencia de rendimiento es tres veces mayor que la de la versión original.¿La versión original de fxsaber muestra la ventaja de GetBid, o se trata de un PC más potente/menos cargado?
¿La versión original de fxsaber muestra la ventaja de GetBid, o es un PC más potente/menos cargado?
Su variante también mostró la ventaja de GetBid a plena carga de la CPU. Pero al mismo tiempo mi variante muestra tres veces la ventaja de la función regular con la misma carga.
Esto se debe a que mi variante tiene en cuenta el tiempo medio de todas las iteraciones de obtener el precio de la oferta y su sólo una pequeña fracción con cuelgues anómalos.
Quién sabe por qué razón el procesador se atasca con la función regular (cuando el retraso es superior a 100 µ) en un "minuto" difícil. Pero aún así el tiempo medio es tres veces menor para la función regular
Así, por ejemplo, si (Intervalo##A > 100) este es el caso:
mientras que si (Intervalo##A > 0) ya es bastante diferente, mostrando una distribución aleatoria de retrasos anormales entre la versión regular y la alternativa de obtener el precio de la Oferta
al mismo tiempo mi prueba con la misma carga de CPU muestra:
Por lo tanto, creo que la versión de fxsaber de la prueba está lejos de ser objetiva.
No he cargado la CPU con agentes, sino con este script. Era más eficiente.
tras una ligera modificación de la prueba fxsaber para demostrar claramente qué porcentaje de iteraciones se tiene en cuenta en los cálculos:
es decir, aproximadamente el 0,01%.
Ya lo creo.
Si el tiempo medio de ejecución de SymbolInfoDouble(_Symbol, SYMBOL_BID) es de unos 50 nanosegundos, sólo se tienen en cuenta los que tienen un tiempo de ejecución superior a 100 000 nanosegundos.
tras una ligera modificación de la prueba fxsaber para demostrar claramente qué porcentaje de iteraciones se tiene en cuenta en los cálculos:
es decir, aproximadamente el 0,01%.
Por supuesto.
Si el tiempo medio de ejecución de SymbolInfoDouble(_Symbol, SYMBOL_BID) es de unos 50 nanosegundos, sólo se cuentan las iteraciones superiores a 100 000 nanosegundos.
Podríamos haber hecho simplemente que la condición no fuera más de 100 µs, sino más de 3 µs. El resultado fue aparentemente el mismo. Se pensó en un estudio segmentado y en diferentes condiciones de ejecución puede haber una diferencia en diferentes segmentos y en diferentes secciones. Las prioridades de ejecución suelen hacerse en función de cualquier cosa. A poca carga unas prioridades, a mucha carga otras, a las críticas, las que no dejan que el ordenador se cuelgue y se cuelgue, y el rendimiento pasa a un segundo plano.
En general, operar con una carga superior al 70% del hardware no es correcto. Es un rendimiento casi crítico. La carga de hierro en los EA de combate no debe superar el 60%.
y ¿ya tiene corredores de HFT?)
intente probar SymbolInfoTick cuando hay un solo símbolo en la visión general del mercado y cuando hay docenas de símbolos, pero pida una herramienta - como en su ejemplo
hay una alta probabilidad de que el servidor esté enviando tráfico comprimido y que SymbolInfoTick esté experimentando esta ralentización intermitente al descomprimir los datos
es decir, cuando hay muchos símbolos, se producirán caídas más frecuentes o profundas en el tiempo de prueba
En las construcciones recientes, la recepción del flujo de ticks no tiene ningún efecto, ni siquiera teóricamente. Prácticamente, SymbolInfoTick ya funciona con caché, pero algunos ciudadanos siguen buscando un gato negro.
Ni siquiera está al 80% en la prueba. Hay 6 agentes funcionando en 4 núcleos, es decir, 100% garantizado.
La única cuestión es cómo maneja la situación el programador de tareas de su sistema. Al mismo tiempo, se está afirmando que la culpa es de la implementación del terminal.
Es decir, se crea artificialmente una situación en la que un ordenador se sobrecarga, en la que literalmente todo en él se ralentiza, y entonces se hacen algunas reclamaciones en forma de "Oh, mira, por qué el terminal se retrasa a veces".
Cerremos los ojos al hecho de que incluso en tales condiciones es "alrededor del 0,01%" - ¡al diablo con los detalles! Basta con decir que "a nadie le importa la temperatura media del hospital", "los desfases causan problemas al operar" y "queremos HFT".
Además, por supuesto que queremos HFT en 20 expertos en un viejo escritorio de oficina o una máquina virtual muerta.
PS PositionSelectByTicket() en su implementación ciertamente tiene acceso a un recurso compartido con sincronización de acceso. Y si no seleccionas la posición en cada llamada, estás leyendo el precio antiguo. Era más fácil hacer un "snapshot" a través de SymbolInfoDouble.