FórumSeções

MT5 e velocidade em ação - página 46

Novo comentário
Renat Fatkhullin:

O temporizador de milissegundos já existe há muito tempo: EventSetMillisecondTimer()

Você está completamente fora do circuito. Suponha que você precise abrir duas posições na OnTick. O primeiro OrderSend é de alguns milissegundos. Depois disso, você precisa fazer um instantâneo. E então o segundo OrderSend deve ser chamado.

Somente o OnTick pode ser executado por centenas de milissegundos. E você sugere fotografar um pouco do OnTimer.

Renat Fatkhullin:

Há também problemas com a própria biblioteca de medição. Há muitas coisas desnecessárias, incluindo as despesas gerais.

Argumentos no estúdio!

Renat Fatkhullin:

Aqui está meu código e tempo de execução estável: sem centenas ou milhares de microssegundos em 20 gráficos em paralelo

Quantos núcleos você tem e que tipo de processador? i7-2600?

8 núcleos.

2020.10.06 02:27:59.464 Terminal        MetaTrader 5 x64 build 2630 started for MetaQuotes Software Corp.
2020.10.06 02:27:59.465 Terminal        Windows 10 build 19042, Intel Core i7-2700 K  @ 3.50 GHz, 7 / 15 Gb memory, 19 / 29 Gb disk, IE 11, Admin, GMT+3

Teste de estresse oculto novamente com milhões de pedidos em paralelo?

Já lhe disse muitas vezes que o assessor de combate. Minimizar ao máximo o número de ligações. Em teoria (não o medi) até 10 chamadas por OnTick.


Seja mais transparente. Só porque você postou um par de chamadas _B simples não é prova de suas outras reivindicações. Você esquece abruptamente o código e a descrição real das condições, assim que faz reivindicações inusitadas.

Você não precisa imaginar nada em sua mente - contar e mostrar o que você realmente chama e testar. Não um resultado arrancado de "ter feito um teste de estresse desconhecido e esperar por um alerta para mostrar ao mundo", mas exatamente o código completo do teste.

Estou publicando os resultados da EA ao vivo. Há ali arquivos de 70 mqh, incluindo o WinAPI. Se você realmente o entende e não apenas palavras, eu lhe darei o código fonte. Você reproduzirá os freios muito rapidamente.

fxsaber:

Você está completamente fora do circuito. Digamos que você precisa abrir duas posições na OnTick. O primeiro OrderSend é de alguns milissegundos. Depois disso, você precisa fazer um instantâneo. E então o segundo OrderSend deve ser chamado.

Somente o OnTick pode ser executado por centenas de milissegundos. E você sugere fotografar um pouco do OnTimer.

Eu não sugeri que se partisse, eu respondi a uma pergunta direta sobre o temporizador de milissegundos.

Ela está lá, embora no testador atual ela ainda seja acionada em 1 segundo. No novo testador que estamos escrevendo, vamos tentar mudar isso.
fxsaber:

8 núcleos.

Muitas vezes disse conselheiro de combate. Minimizar ao máximo o número de ligações. Em teoria (não o medi) até 10 chamadas por OnTick.


Estou publicando os resultados do Expert Advisor. Há ali arquivos de 70 mqh, incluindo o WinAPI. Se você não apenas falar sobre isso, mas realmente entender, eu lhe darei o código fonte. Você jogará os freios muito rapidamente.

Nós vamos descobrir, nos dê o código fonte.
fxsaber:

Argumentos sobre a mesa!

Toda a sua referência está sobrecarregada de lixo e, de fato, aqui é uma versão limpa e compreensível (ao contrário de sua desordem de código):


//--- benchmark macros
#define _B(_function,_alert_interval)               \
          {                                         \
           ulong _latency=GetMicrosecondCount();    \
           _function;                               \
           _latency=GetMicrosecondCount()-_latency; \
           if(_latency > _alert_interval)           \
              ::Alert("Time[" + __FILE__ + " " + (string)__LINE__ + " in " + __FUNCTION__+ ": " + #_function + "] = " + (string)_latency + " mсs"); \
          }



//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnTick()
  {
   MqlTick Tick;
   
   _B(SymbolInfoTick(_Symbol,Tick),0);
   _B(SymbolInfoTick(_Symbol,Tick),0);
  }

Quais são seus problemas:

  1. código não legível

  2. Ligado a uma classe com muitas despesas gerais

  3. o custo de armazenagem de 50 resultados na pilha
      static bool Set( const string Str )
  {
    if (BENCHMARK::Amount == BENCHMARK::ReserveSize)
      BENCHMARK::ReserveSize = ::ArrayResize(BENCHMARK::Bench, BENCHMARK::ReserveSize + BENCHMARK_RESERVE);

    BENCHMARK::Bench[BENCHMARK::Amount++].Set(Str);

    return(true);
  }
  4. obter resultados - um sólido overhead e lixo nas amarrações de objetos
      static ulong Get( const uint AlertInterval = 0 )
  {
    const int Pos = BENCHMARK::Amount - 1;
    const ulong Res = (Pos < 0) ? 0 : BENCHMARK::Bench[Pos].Get();

    if (Pos >= 0)
    {
      if (AlertInterval && (Res > AlertInterval))
        ::Alert("Time[" + BENCHMARK::Bench[Pos].Str + "] = " + (string)Res + " mсs.");

      BENCHMARK::Amount = Pos;
    }

    return(Res);
  }


Espero que você não tenha desativado a otimização do código para testes?

Quero dizer, o parâmetro global Optimize=0 no metaeditor.ini

Renat Fatkhullin:

Toda a sua referência está sobrecarregada de lixo e, de fato, aqui é uma versão limpa e compreensível (ao contrário de sua desordem de código):

Sua versão está, infelizmente, no estágio inicial de compreensão da conveniência. Conveniente é quando você pode fazer isso assim.

Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos

Bibliotecas: Benchmark

fxsaber, 2020.10.01 23:49

Agora tentamos descobrir onde o soluço está na variante padrão. Acrescentamos alguns símbolos ao código fonte.

    for (long Chart = _B2(::ChartFirst()); (Chart != -1) && !Res; Chart = _B2(::ChartNext(Chart)))
      Res = (Chart != chartID) && _B2(::ChartGetInteger(Chart, CHART_IS_MAXIMIZED));

E veja imediatamente a razão.

2020.10.02 00:45:14.113 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 878 mсs.
2020.10.02 00:45:14.114 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 943 mсs.
2020.10.02 00:45:14.114 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 297 mсs.
2020.10.02 00:45:14.116 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 1787 mсs.
2020.10.02 00:45:14.116 Alert: Time[Test9.mq5 35 in IsInvisible: ::ChartNext(Chart)] = 2 mсs.
2020.10.02 00:45:14.117 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 980 mсs.
2020.10.02 00:45:14.117 Alert: Time[Test9.mq5 35 in IsInvisible: ::ChartNext(Chart)] = 2 mсs.
2020.10.02 00:45:14.117 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 59 mсs.
2020.10.02 00:45:14.118 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 803 mсs.
2020.10.02 00:45:14.119 Alert: Time[Test9.mq5 36 in IsInvisible: ::ChartGetInteger(Chart,CHART_IS_MAXIMIZED)] = 1059 mсs.

CHART_IS_MAXIMIZED é muito lento para os gráficos de outra pessoa. O relatório do bug está pronto! Foi muito fácil com a biblioteca.


Qual é o problema?

  1. código não legível

  2. se amarrando em uma classe com muita sobrecarga

  3. custo de armazenagem em pilha de 50 resultados
  4. obtendo resultados - uma enorme sobrecarga e lixo nas amarrações de objetos

A usabilidade se sobrepõe às parcas despesas gerais. É miserável se você olhar de perto como ele é implementado. Por exemplo, o ArrayResize é uma sobrecarga, portanto seu uso é minimizado.

Espero que você não tenha desativado a otimização do código para testes?

Quero dizer o parâmetro global Optimize=0 no metaeditor.ini

Não está interessado em modos lentos. Estou olhando para o desempenho da EA de combate, prestando atenção também à otimização algorítmica e à otimização do compilador, é claro.

Renat Fatkhullin:

Toda a sua referência está sobrecarregada de lixo e, de fato, aqui é uma versão limpa e compreensível (ao contrário de sua desordem de código):

Qual é o seu problema?

  1. código não legível

  2. amarrar em uma classe com muita sobrecarga

  3. custo de armazenagem em pilha de 50 resultados
  4. resultados interessantes - todas as despesas gerais e lixo nas amarrações de objetos


Espero que você não tenha desativado a otimização do código para testes?

Quero dizer, o parâmetro global Optimize=0 no metaeditor.ini

Aqui é no estilo C, é simples e realmente livre de lixo. Obrigado pelo exemplo.

Um dos professores de línguas C recomendou melhor não usar o underscore _B em nomes de usuários
. Como este prefixo é usado por desenvolvedores de bibliotecas, programas, etc.
E para não se sobrepor, ele recomendou melhor não usá-lo.

Em mql5 é possível sobrepor-se a seus nomes?
Ou nomes personalizados são completamente protegidos de nomes MQ ?

Roman:

Um dos professores da C recomendou não usar o sublinhado _B em nomes de usuários
, porque este prefixo é usado por desenvolvedores de bibliotecas, software, etc.
E para evitar sobreposições, ele recomendou não usá-lo.

Em C, os nomes que começam com "_" são usados como serviço, sistema ou nomes especiais. Neste caso, acho que é permissível. Como esta função é utilizada para manutenção e exame de códigos.

Edgar Akhmadeev:

Nomes que começam com "_" são usados em C como serviço, sistema ou nomes especiais. Neste caso - aceitável, eu acho. Como esta função é utilizada para manutenção e exame de códigos.

Esse é o ponto, além do mql5, há os nomes dos serviços MQ do desenvolvedor.

1...394041424344454647484950515253...94
Novo comentário