Características da linguagem mql5, subtilezas e técnicas - página 118

Novo comentário
 
Não, eu estava errado. FastLog2 funciona mais rápido quando Optimize=1. É um milagre... Tenho de o verificar em C++.
 
Alexey Navoykov:

A propósito, cerca de zero, FastLog2 não verifica o zero, o que lhe dá um avanço. Mas ainda é 1,5-2 vezes mais lento que o log2 se testado correctamente).

E o que há de errado nisso?

Porque até a sua versão do teste produz:

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:

A propósito, cerca de zero, FastLog2 não verifica o zero, o que lhe dá um avanço. Mas ainda é 1,5-2 vezes mais lento que o log2, se testado correctamente).

Claro, devemos remover a verificação zero do log2 ou adicionar a mesma ao FastLog2.

A questão é realmente sobre a velocidade da parte computacional. Em log2, tudo é calculado puramente por turnos e adições. FastLog2 utiliza valores de tabela após conversões inteligentes envolvendo multiplicação. Este código é muito antigo, era utilizado nos tempos dos coprocessadores de matemática, a situação pode muito bem ter mudado desde então.

 
Verificou-o em C++. Sim, FastLog2 é de facto o mais rápido. Código inteligente, no entanto ) Talvez a razão seja que as operações bitwise são muito mais rápidas do que as operações de comparação.
 
Testei todos os códigos no MT4. No MT4 o compilador não realiza qualquer optimização (ou seja, a variante com soma mostra os mesmos resultados relativos da minha variante original sem soma), e no MT4 o log2 corre mais rápido do que FastLog2. E no MT5 a optimização já é executada sem soma (ou seja, o código aparentemente não é executado completamente), e a variante FastLog2 é mais rápida do que o log2. Que conclusões se podem tirar disto não sei, porque não há pormenores sobre como o optimizador de códigos funciona ali e ali.
  
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 é o comportamento padrão da MQL5: as variáveis estáticas vêm depois das variáveis globais.

Pode ficar muito confuso por causa disto.
 
fxsaber:

Este é o comportamento padrão da MQL5: as variáveis estáticas começam depois das variáveis globais.

É por isso que cada variável estática de uma classe/estrutura tem de ser declarada após a própria estrutura? E mesmo sem lhe atribuir qualquer valor... Talvez devêssemos sugerir que o compilador faça tudo isto automaticamente?

 

Isto é essencialmente um bug, uma sequência incorrecta de execução do código do programa. O compilador não deve permitir isto em princípio. Deve-se gritar mais vezes com os programadores sobre isto.

Em C++ o código é processado pelo compilador estritamente de cima para baixo, pelo que tudo o que vem de cima já está inicializado. E não se pode aceder ao código de baixo. É por isso que tudo é claro. E desde que os criadores introduziram aqui as suas próprias regras, deixem-nos fornecer a ordem correcta de execução do código.

 
Alexey Navoykov:

Em C++, o código é processado pelo compilador estritamente de cima para baixo, por isso qualquer coisa em cima já está inicializada. E não se pode aceder ao de baixo. É por isso que tudo é claro.

Há menos flexibilidade.

1...111112113114115116117118119120121122123124125...247
Novo comentário