Características del lenguaje mql5, sutilezas y técnicas - página 118

 
No, me equivoqué. FastLog2 sí funciona más rápido cuando Optimize=1. Es un milagro... Tengo que comprobarlo en C++.
 
Alexey Navoykov:

Por cierto, sobre el cero, FastLog2 no comprueba el cero, lo que le da ventaja. Pero sigue siendo 1,5-2 veces más lento que log2 si se prueba correctamente).

¿Y qué tiene de incorrecto?

Porque incluso su versión de la prueba produce:

2019.01.05 04:43:12.372 TestLog (EURUSD,H1)     Result log2:       sum=1400005128  time=297 ms
2019.01.05 04:43:12.635 TestLog (EURUSD,H1)     Result log2_:      sum=1400018381  time=262 ms
2019.01.05 04:43:12.809 TestLog (EURUSD,H1)     Result _FastLog2:  sum=1400004095  time=174 ms
 
Alexey Navoykov:

Por cierto, sobre el cero, FastLog2 no comprueba el cero, lo que le da ventaja. Pero sigue siendo 1,5-2 veces más lento que log2, si se prueba correctamente).

Por supuesto, deberíamos eliminar la comprobación de cero de log2 o añadir la misma a FastLog2.

La pregunta es realmente sobre la velocidad de la parte computacional. En log2, todo se calcula puramente por desplazamientos y sumas. FastLog2 utiliza los valores de la tabla después de realizar conversiones inteligentes que implican una multiplicación. Este código es muy antiguo, se utilizaba en la época de los coprocesadores matemáticos, la situación puede haber cambiado desde entonces.

 
Lo he comprobado en C++. Sí, FastLog2 es efectivamente el más rápido. Sin embargo, un código inteligente ) Tal vez la razón sea que las operaciones a nivel de bits son mucho más rápidas que las operaciones de comparación.
 
He probado todos los códigos en MT4. En MT4 el compilador no realiza ninguna optimización (es decir, la variante con suma muestra los mismos resultados relativos que mi variante original sin suma), y en MT4 log2 corre más rápido que FastLog2. Y en MT5 la optimización ya se realiza sin sumar (es decir, el código aparentemente no se ejecuta por completo), y la variante FastLog2 es más rápida que log2. Qué conclusiones se pueden sacar de esto no lo sé, porque no hay detalles sobre cómo funciona el optimizador de código allí y allá.
 
void f(){
  static int a[]; 
  Print("a[]=",ArraySize(a)); 
  ArrayResize(a, 100); 
  Print("a[]=",ArraySize(a));}


class A
 {
public: A(){ f(); }
 };
 
A _a;

void OnStart()
  {

  }


 
Ilya Malev:

Este es el comportamiento estándar de MQL5: las variables estáticas vienen después de las variables globales.

Se puede llegar a tener un lío muy serio por culpa de esto.
 
fxsaber:

Este es el comportamiento estándar de MQL5: las variables estáticas comienzan después de las variables globales.

¿Es por eso que cada variable estática de una clase/estructura tiene que ser declarada después de la propia estructura? E incluso sin asignarle ningún valor... ¿Tal vez deberíamos sugerir que el compilador haga todo esto automáticamente?

 

Esto es esencialmente un error, una secuencia incorrecta de la ejecución del código del programa. En principio, el compilador no debería permitir esto. Deberías gritar a los desarrolladores más a menudo sobre esto.

En C++ el código es procesado por el compilador estrictamente de arriba a abajo, por lo que todo lo de arriba ya está inicializado y no se puede acceder al código de abajo. Por eso todo está claro. Y ya que los desarrolladores introdujeron sus propias reglas aquí, que proporcionen el orden correcto de ejecución del código.

 
Alexey Navoykov:

En C++, el código es procesado por el compilador estrictamente de arriba a abajo, por lo que todo lo que está en la parte superior ya está inicializado. Y no se puede acceder a la parte inferior. Por eso todo está claro.

Hay menos flexibilidad.

Razón de la queja: