Discusión sobre el artículo "Comparando MQL5 y QLUA - ¿Por qué las operaciones comerciales en MQL5 son hasta 28 veces más rápidas?" - página 3
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
Simultáneamente, es cuando usted tiene una diferencia en las mediciones flotando como 10%.
Pero cuando según los resultados de decenas de pruebas tienes una diferencia estable de 4-5 veces, no hay nada que discutir.
La diferencia (no estable) en MT5 fue de hasta dos veces. Por eso decidí que si medimos el rendimiento, deberíamos fijarnos en la frecuencia máxima (tiempo mínimo entre paquetes vecinos) con la que llegan los paquetes. Escribí un Asesor Experto correspondiente
Y obtuve el resultado
Y si ~10ms entre eventos BookEvent vecinos es plausible. Pero 0.035ms no lo es. Resulta que un evento BookEvent se crea por el mismo principio que un evento Tick:
Por lo tanto, esta implementación de medición no es adecuada para eventos Tick/Calculate/BookEvent. Y cómo supervisar la llegada de un nuevo paquete de red de cotización en MQL5 no está claro todavía.
Cualquier prueba debe contener protección contra el arranque en frío.
Así que saltarse N ticks es un indicador de que somos conscientes de este hecho y lo tenemos en cuenta. Solo para evitar la obviamente esperada reclamación de "por qué no compensasteis el impacto del arranque en frío".
El vídeo sobre el inicio de la sesión de tres terminales se preparó el 25 de agosto de 2016 para otra reclamación de un trader que afirmaba que MT5 se ralentiza al inicio de la sesión. Como resultó después, este trader no utilizaba MT5 en absoluto, sino que difundía especulaciones del foro. También resultó que algunos operadores no eran conscientes de que para los instrumentos bursátiles los gráficos no se construyen por Bid, sino por los precios Last negociados. Ellos percibieron el cambio de ofertas y no mostrarlas en los gráficos como "frenos MT5".
Por supuesto, no hay frenos.
La diferencia (no estable) en MT5 era de hasta dos veces. Así que decidí que si medimos el rendimiento, deberíamos fijarnos en la frecuencia máxima (tiempo mínimo entre paquetes vecinos) con la que llegan los paquetes. Escribí un Asesor Experto correspondiente
Y obtuve el resultado
Y si ~10ms entre eventos BookEvent vecinos es plausible. Pero 0.035ms no lo es. Resulta que un BookEvent se crea por el mismo principio que un evento Tick:
Plausible.
Los datos llegan transaccionalmente y el hecho de haber visto dos transacciones consecutivas con tiempos cortos es una gran prueba de la corrección de nuestro procesamiento y del rendimiento tanto del propio terminal como del subsistema MQL5.
Es muy adecuado.
Mira nuestro código - mide específicamente no datos cortos individuales, pero estúpidamente recoge ticks durante 30 segundos. Esto nivela cualquier fluctuación y cualquier error.
En el video de arriba, MQL5 recibió 1.278 ticks en 30 segundos, mientras que QLUA recibió sólo 254 ticks. Esto es un cruel fastidio para QLUA algotrading.
Plausible.
Los datos vienen transaccionalmente y el hecho de que hayas visto dos transacciones consecutivas con tiempos cortos es una gran prueba de la corrección de nuestro procesamiento y rendimiento tanto del terminal como del subsistema MQL5.
Pero llegaron en un paquete en un paquete de red. Quiero medir la velocidad de la puerta de enlace.
Es un buen ajuste.
Mira nuestro código - mide especialmente no solo datos cortos, sino que estúpidamente recoge ticks durante 30 segundos. Esto nivela cualquier fluctuación y cualquier error.
En el vídeo de arriba, MQL5 recibió 1.278 ticks en 30 segundos, mientras que QLUA recibió sólo 254 ticks. Este es un cruel fastidio para QLUA algotrading.
Pero venían agrupados en el paquete de red. Quiero medir la velocidad de la pasarela.
No importa.
Simplemente los ticks vinieron uno tras otro, y el terminal MT5 se las arregló para dártelos bien y sin frenos.
Me has entendido mal. No me importa QLUA-freno - todo está claro con él (y no hay preguntas al artículo). Quiero obtener características de rendimiento de MT5 sí mismo. Y sólo el MaxFrequency-manera, como he implementado, no encaja. Porque MT5 tiene una peculiaridad con la creación de eventos Tick/Calculate/BookEvent. Ejecute el Asesor Experto en su lugar - lo verá muy rápidamente.
El principio"cada tick es una transacción enviada independientemente" significa que ideológicamente todo está construido correctamente. Y cómo puede estar mal si construimos 5 plataformas desde cero y pasamos por todos los escollos más de una vez.
Conseguisteis un rendimiento muy alto. El hecho de que hayas empezado a inventarte la frecuencia es una tontería evidente. Tenemos datos cuando tenemos datos cuando tenemos datos. Así que hablar de "estabilidad/inestabilidad de la frecuencia" no tiene ningún sentido lógico. No estás probando la estabilidad del oscilador de cuarzo, estás intentando estabilizar el proceso aleatorio de aparición de precios en el cristal.
Es sólo Quick que originalmente construyó todos los procesos sobre el control de la frecuencia instantánea. Con un resultado natural.
No importa.
Simplemente los ticks venían uno tras otro, y el terminal MT5 se las arreglaba para dártelos bien y sin frenos.
El principio "cada tick es una transacción enviada independientemente" significa que ideológicamente todo está construido correctamente. Y cómo puede estar mal si construimos 5 plataformas desde cero y pasamos por todos los escollos más de una vez.
Conseguisteis un rendimiento muy alto. El hecho de que hayas empezado a inventarte la frecuencia es una tontería evidente. Tenemos datos cuando tenemos datos cuando tenemos datos. Así que hablar de "estabilidad/inestabilidad de la frecuencia" no tiene ningún sentido lógico. No estás probando la estabilidad de un oscilador de cuarzo, estás intentando estabilizar el proceso aleatorio de aparición de precios en el cristal.
Puedo explicar fácilmente el principio de la frecuencia. La pila la forma la propia bolsa a una velocidad inestable, porque depende de las acciones de los participantes en el mercado.
Quería medir la frecuencia máxima de actualización de las pilas, es decir, cuántas pilas puede generar MT5 por unidad de tiempo. Resultó que las estacas llegan a MT5 en paquetes. Es posible que las estacas de la bolsa ni siquiera se pierdan, pero TODAS llegan. Y el evento BookEvent se crea no para un paquete, sino para todas las apuestas del paquete (de la más antigua a la más reciente). Es imposible obtener la hora de formación de la pila en MQL5. La hora de llegada del paquete es la misma. Por lo tanto, resulta que mi implementación de la medición de la característica de rendimiento MT5 correspondiente no muestra lo que quiero ver.
El hecho de que BookEvent se forme en paquetes - lo apoyo con todas mis extremidades. Es máxima información y mínima molestia para el Asesor Experto. El único problema con la medición del rendimiento es lo que he descrito.
Puedo explicar fácilmente el principio de frecuencia. El stack lo forma la propia bolsa a un ritmo variable, porque depende de las acciones de los participantes en el mercado.
Yo quería medir la frecuencia máxima de actualización de stacks - cuántos stacks puede generar MT5 por unidad de tiempo. Resultó que las estacas llegan a MT5 en paquetes. Es posible que las estacas de la bolsa ni siquiera se pierdan, pero TODAS llegan. Y el evento BookEvent se crea no para un paquete, sino para todas las apuestas del paquete (de la más antigua a la más reciente). Es imposible obtener la hora de formación de la pila en MQL5. La hora de llegada del paquete es la misma. Por lo tanto, resulta que mi implementación de la medición de la característica de rendimiento MT5 correspondiente no muestra lo que quiero ver.
El hecho de que BookEvent se forme en paquetes - lo apoyo con todas mis extremidades. Es máxima información y mínima molestia para el Asesor Experto. Pero sólo hay un problema con la medición del rendimiento que he descrito.
Repito una vez más - no tiene sentido para medir la frecuencia de esta manera y hacer tales conclusiones.
No trate de medir la frecuencia de un proceso aleatorio de la aparición de precios en la pila sobre la base de la diferencia de tiempo entre dos garrapatas. Obviamente, obtendrá una dispersión salvaje de números del 1 al XXXXX.
Te has equivocado de pregunta, has calculado mal y has sacado conclusiones erróneas. Al mismo tiempo pones una sombra en el mimbre con la afirmación "MT5 no muestra lo que quieres ver, no puedes medirlo".
No hay problema de "medición del rendimiento", porque has medido lo equivocado y de forma equivocada. Te has equivocado de característica y fundamentalmente de cálculo.
ps: pero en las pruebas medimos correctamente la frecuencia de llegada de las cotizaciones recogiendo las cotizaciones durante 30 segundos y dividiendo por el tiempo transcurrido.
Lo repetiré una vez más: no tiene sentido medir la frecuencia de esa manera y sacar esas conclusiones.
No intente medir la frecuencia de un proceso aleatorio de aparición de precios en el cristal basándose en la diferencia de tiempo entre dos ticks. Obviamente, obtendrá una dispersión salvaje de números del 1 al XXXXX.
Usted ha formulado la pregunta equivocada, ha calculado incorrectamente y ha sacado conclusiones erróneas. Al mismo tiempo has ensombrecido los mimbres con la afirmación "MT5 no muestra lo que quieres ver, no puedes medirlo".
ps: pero la frecuencia de llegada de cotizaciones la medimos correctamente en las pruebas recogiendo cotizaciones durante 30 seg y dividiendo por el tiempo transcurrido.
Yo mido la frecuencia MÁXIMA, ¡no la actual! Describí con todo detalle la razón de tales mediciones, los resultados y di la fuente. Por alguna razón sientes que estoy haciendo sombra a MT5.
Cualquier veterano del foro que lea esta discusión entenderá lo que quise decir. Y no verá ninguna sombra hacia MT5. Mi aplicación resultó ser errónea. La mía, no la tuya. Que te estás defendiendo donde yo ni siquiera he dado una razón.
Es mi implementación la que no te permite medir lo que quieres. MQL5 no tiene esa posibilidad y es normal. Igual que es normal que yo quiera zumo, pero MQL5 no da tal posibilidad.
Sólo compartí el resultado de que si alguien quiere medir el tiempo entre las llamadas vecinas de los eventos correspondientes e interpretarlo como rendimiento. Es necesario darse cuenta claramente de lo que realmente se mostrará.
Usted está fundamentalmente equivocado.
¿Cuál es la frecuencia máxima, cuando en realidad va a medir el delta de un proceso aleatorio, donde dos eventos tienen delta 0?
Si la entrega de garrapatas se implementa correctamente (y lo tenemos correctamente), obviamente obtendrá la máxima "frecuencia" = (tiempo de procesamiento de la llamada MQL5 con el código del programa) / (error del temporizador).
Teóricamente, si usted cumple con la precisión del temporizador y obtener 0 microsegundos, la frecuencia será infinito. Bueno y el error crítico de la división por cero (no tiene control de la división por cero en su código).
Usted está fundamentalmente equivocado.
¿Cuál es la frecuencia máxima, cuando en realidad se va a medir el delta de un proceso aleatorio, donde dos eventos tienen delta 0?
Si la entrega de la garrapata se implementa correctamente (y lo tenemos correctamente), que sin duda obtener la máxima "frecuencia" = (tiempo de procesamiento de MQL5 llamada con el código del programa) / (error del temporizador).
Sí, así es como lo entiendo. Resultó que estaba midiendo un proceso aleatorio, y quería medir el proceso de entrega de paquetes de red. Pero no funcionó.
Teóricamente, si puedes cumplir la precisión del temporizador y obtener 0 microsegundos, la frecuencia será infinita. Bueno, y un error crítico de división por cero(no tienes control de división por cero en tu código).