El esplendor y la pobreza de la OLP - página 7

[Dmitry Fedoseev]

¡Lo encontré! Aún así, conseguí una mayor velocidad con el PLO. Sí, los beneficios son innegables.

[Dmitry Fedoseev]

dimeon:

Entonces escribamos todo en lenguaje ensamblador. Sería más rápido de todos modos.

No entiendo el problema. Nunca he visto un Asesor Experto o indicador con 1 MB de código.

La llamada de cualquier función también lleva algún tiempo. ¡Renunciemos también a las funciones!

El control de los grandes proyectos es mucho más cómodo con la POO.

Además, la velocidad de ejecución del código no suele ser tan crítica como el tiempo de ping al broker y la respuesta a la orden del broker.

Comprueba los algoritmos HFT. Requieren la máxima velocidad, pero no encontrarás cálculos complejos.

PS. Normalmente no se necesita un supercoche o una moto de nieve para ir del punto A al punto B. ¡Un ciclomotor es suficiente! ¡Un ciclomotor es suficiente!

Hay una persona aquí que, en lugar de escribir una función, escribe código en el archivo y lo incluye.

[Alexey Navoykov]

Integer:

¡Lo encontré! Aún así, conseguí una mayor velocidad con el PLO. Sí, los beneficios son innegables.

¿Cuál era el código?

[Dmitry Fedoseev]

meat:
Entonces, ¿cuál era el código?

Llamar a iCustom() con diferente número de parámetros, un caso diferente para cada número de parámetros, o una clase diferente para cada número de parámetros en la variante OOP.

[Renat Fatkhullin]

En la nueva compilación del compilador MQL, ya hemos incluido la optimización de sustituir un método virtual por una llamada directa si es el último método de una cadena de métodos virtuales y no hay enlaces a bibliotecas externas.

Este método simplificará y acelerará las llamadas virtuales a muchos programas que trabajan con clases.

Los resultados del ejemplo test.mq4 del primer post en la compilación 670:

switch: 172
OOP:    312

Hubo que aumentar el bucle de 10.000.000 a 50.000.000 para evitar trabajar con medidas de tiempo minúsculas de 32-64 ms. Se muestra el tiempo en ms, cuanto más pequeño es el número, más rápido es el código.

Esto es lo que obtuve con el nuevo compilador en el mismo código:

switch: 157
OOP:     93

OOP ganó con una explosión. ¿Pero por qué?

En primer lugar, el método virtual se convirtió en un método regular, y luego se zinó y optimizó a cero. De hecho, la llamada a la función y el cuerpo desaparecieron por completo, dejando un bucle puro:

  mov     int[i] <- int[0]

$label:
                                        <- тут когда-то было тело, но оно оптимизировалось в ноль
  add     int[i] <- int[i], int[1]
  jlt     int[i], int[50000000] --> $label

Se adjuntan los archivos, incluida la nueva beta del compilador de consola. Puedes comparar cualquier ejemplo usando la compilación regular 670 de MetaEditor (compilador incorporado) y el compilador de consola.

Lo que esto demuestra:

1. Lo que se comprueba es la calidad del optimizador del compilador.
2. Las pruebas deben ser escritas con una comprensión completa de cómo se optimiza todo
3. Como he dicho - mostró en un ejemplo existente cómo es posible engañar (OOP repente ganó), si usted no sabe peculiaridades de la optimización del código