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
Resulta que estaba mirando la frecuencia de generación de la red, no la frecuencia de salida.
Son números diferentes, múltiplos uno del otro.
Resulta que estaba calculando la frecuencia de generación de la web (sin salida) y la frecuencia de salida (sin generación) un poco mal
Esta es una versión más correcta.
Resultados en mi procesador:
Si se toma el tiempo puramente generando un fotograma de 200 círculos suavizados sin salida, ocurre a unos 500 fotogramas por segundo.
formando un fotograma de 200 círculos sin alisar y sin salida - unos 1000 fps.
La frecuencia de la propia salida de la imagen (lienzo) (función de actualización) es de unos 650 fps.
Has trabajado mucho.
Cuidado con las conversiones masivas de tipos (int)double o (double)int y con mezclar int+double en las operaciones mat en general.
Esto da la sobrecarga más salvaje al procesador - sólo un comando de ensamblador tan caro. Si cuentas en doble, sigue contando en doble y no cambies a tipos enteros.
Comandos como cvtsi2sd/cvttsd2si son muy largos. Un pequeño consejo en el artículo"La instrucción x86 más lenta", villano número 2.
Gracias por un artículo tan valioso.
Pero para ser honesto, no entiendo por qué entonces en este simple script:
la suma de long con conversión de tipo double a long es mucho más rápida que la suma de double del mismo array sin conversión
En primer lugar, hay que fijarse en el código ensamblador y en el resultado de las optimizaciones de casos extremadamente sencillos (hace tiempo que la supermicrosíntesis es engañosa). Es fácil encontrarse con un caso ideal de implantación de transportadores.
En segundo lugar, casi nadie puede garantizar cómo se compilará tal o cual código y cuánto tiempo tardará en ejecutarse.
Sólo hay que añadir una línea/comando más en el código y la velocidad cambia drásticamente. El código/datos reales bien podrían salir de la caché L1/L2 y eso es todo.
¿Cómo le ha funcionado? En teoría/superestética parece que los comandos enteros ayudarán en la velocidad, pero en el código real es una sangría. Porque hay decenas/centenares de veces más código, no hay convección, se salta constantemente de cálculos enteros a reales y la optimización es limitada.
¿Por qué la inicialización de arrays de cualquier tipo en MQL4 es más de 10 veces más lenta que en MQL5?
¿Por qué la inicialización de arrays de cualquier tipo en MQL4 es más de 10 veces más lenta que en MQL5?
Porque todas las matrices allí son dinámicas y el lenguaje es diez veces más lento.
Un indicador ultrarrápido de cientos de medias móviles, implementado en Canvas.
100 líneas MA (paso de periodo 10) - tiempo de cálculo y visualización en pantalla - 4-7 milisegundos
1000 líneas MA (periodo paso 1) - tiempo de cálculo y visualización - 20-30 milisegundos.
No he probado demasiado el código. Es posible que haya errores. Implementado sólo para barras de un píxel de grosor (se fuerza a esta escala). También la tasa de refresco de la pantalla no está optimizada. Todas las líneas se calculan y se emiten completamente en cada tic.
Un indicador ultrarrápido de cientos de medias móviles, implementado en Canvas.
100 líneas MA (paso de periodo 10) - tiempo de cálculo y visualización en pantalla - 4-7 milisegundos
1000 líneas MA (paso de periodo 1) - tiempo de cálculo y visualización - 20-30 milisegundos
Genial, con los indicadores estándar todo estaría muerto
genial, los indicadores estándar lo habrían colgado todo.
y luego habría una milla de código...
quizás incluso eso sólo se pueda hacer con una plantilla. No sé sobre la limitación del número de líneas del indicador en el cuerpo de un indicador.
...
No conozco la limitación del número de líneas del indicador en el cuerpo de un indicador.
Hay un límite. Se pueden hacer hasta 512 buffers de indicadores >>>https://www.mql5.com/ru/docs/indicators