A lona é legal!

Renat Fatkhullin 2019.01.15 21:37 #151

No nível atual de processador, você pode esquecer os freios de dupla matemática. Não há atrasos.

E os métodos de otimização por conversão para o inteiro já estão realmente ultrapassados. Você perderá muitas vezes mais na conversão do que ganha na matemática.

Levando em conta o código de 64 bits e nosso compilador, você deve esquecer o número inteiro na classe de tarefas com base em cálculos duplos.

Aqui está uma amostra anterior das tentativas de otimização do Nikolai: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332

O compilador conseguiu combinar cálculos de duas raízes duplas de 64 bits de diferentes expressões em um comando assembler de 128 bits. Quando se trabalha com matemática dupla, não é fortemente recomendado saltar/converter para tipos inteiros. Há despesas gerais de CPU em conversão (não nossas).

Ошибки, баги, вопросы

2018.03.11
www.mql5.com

Общее обсуждение: Ошибки, баги, вопросы

Interessante assumir a OLP Erros, bugs, perguntas Regressão Bayesiana - Alguém

Renat Fatkhullin 2019.01.15 21:42 #152

Nikolai Semko:

Não é preciso arredondar nada.

Aqui está um roteiro como exemplo.

Executá-lo primeiro com parâmetros padrão (com círculos anti-serrilhados e coordenadas e dimensões do tipo duplo)

e depois execute-o com o parâmetro typ = not_smoothed_circles (com círculos e coordenadas e tamanhos do tipo int nãomoothed - da classe CCanvas).

Isso funcionou muito bem.

Tenho 347 fps sem antialiasing e 97 com antialiasing em lona com 2100x550 pixels.

Para informação, temos um limitador de taxa de atualização de janela de 500fps. Isto mostra quanto desempenho pode ser alcançado nos gráficos.

Executar roteiro através do Como minimizar o tamanho Quaisquer perguntas de recém-chegados

fxsaber 2019.01.15 21:42 #153

Renat Fatkhullin:

No nível atual dos processadores, você pode esquecer a frenagem da dupla matemática. Não há freios.

E os métodos de otimização por conversão para o inteiro já estão realmente ultrapassados. Você perderá muitas vezes mais na conversão do que ganha na matemática.

Levando em conta o código de 64 bits e nosso compilador, você deve esquecer o número inteiro na classe de tarefas com base em cálculos duplos.

Aqui está uma amostra anterior das tentativas de otimização do Nikolai: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332

O compilador conseguiu combinar cálculos de duas raízes duplas de 64 bits de diferentes expressões em um comando assembler de 128 bits. Quando se trabalha com matemática dupla, não é fortemente recomendado saltar/converter para tipos inteiros. Há despesas gerais de CPU em conversão (não nossas).

Tenho quase certeza de que se fizermos os carrapatos inteiros, o Testador começará a trabalhar muito mais rápido.

Алексей Тарабанов 2019.01.15 22:35 #154

Artyom Trishkin:

Não, isso não é morphing. É um estiramento para chamá-lo de "morphing":

Na verdade, eu mesmo era preguiçoso demais para fazer um de verdade - eu o encontrei nas pastas de exemplo.

Morphing, literalmente - mortificação.

Алексей Тарабанов 2019.01.15 22:48 #155

fxsaber:

É quase certo que se você fizer o tique inteiro, o Testador começará a trabalhar muito mais rápido.

É claro para o cavalo, como disse Elena Yurievna.

Renat Akhtyamov 2019.01.15 23:03 #156

Nikolai Semko:

Baseado no Doom e no conselho de @fxsaber.

Eu usei algoritmodeste site com algumas pequenas modificações.

Realmente legal!

O que você usa para fazer fotos, Nikolai?

Renat Fatkhullin 2019.01.15 23:06 #157

fxsaber:

É quase certo que se você fizer o tique inteiro, o Testador começará a trabalhar muito mais rápido.

Não.

Para começar, perceba isso:

tudo terá que ser convertido em ints.
obter um monte de atrasos na conversão de dados
obter consumo de memória selvagem
ter 100% de chance de transbordamento em cada operação e morte completa do sistema
obter uma desconsideração dos desenvolvedores que são oferecidos para ler seus indicadores e trabalhar em ints em vez de dubs
E ta da, não há mais diferença entre dubs e ints na velocidade. Difícil de acreditar, mas sim.

Eu não citei as provas acima por nada. Lá Nikolai tentou aplicar o método de otimização através de tabelas de raízes pré-calculadas e perdeu para o cálculo rltime das raízes no processo.

Erros, bugs, perguntas Minha abordagem. O núcleo Demonstrando a abordagem de

Artyom Trishkin 2019.01.15 23:08 #158

Алексей Тарабанов:

Morphing, literalmente - morte.

Não vale a pena discutir aqui, mas Morphing ( morphing) Onde você vê pessoas mortas, sóbrio...

Алексей Тарабанов 2019.01.15 23:17 #159

Artyom Trishkin:

Não vale a pena discutir aqui, mas Morphing ( morphing- transformação) Onde você vê pessoas mortas - sóbrio...

A análise morfométrica é a análise de células mortas. Primeiro os matamos, depois os colocamos sob o microscópio.

fxsaber 2019.01.15 23:18 #160

Renat Fatkhullin:

Não.

#define  BENCH(A)                                                              \
{                                                                             \
  const ulong StartTime = GetMicrosecondCount();                              \
  A;                                                                          \
  Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \
}  

template <typename T>
T Tester( const int Amount = 1 e7 )
{
  T Sum = 1;
  T Price = 1;
  
  for (int i = 0; i < Amount; i++)
  {
    Price = 1 - Price;
    
    Sum += (Sum > Price) ? 1 : 0;
  }
  
  Print(Sum);
  
  return(Sum);
}

void OnStart()
{
  BENCH(Tester<int>());
  BENCH(Tester<double>());
}

O dobro da int é duas vezes mais rápido que o dobro

10000001
Time[Tester<int>()] = 25523
10000001.0
Time[Tester<double>()] = 51253

A lona é legal! - página 16