Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
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).
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.
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.
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.
É 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.
Baseado no Doom e no conselho de @fxsaber.
Eu usei algoritmodeste site com algumas pequenas modificações.
O que você usa para fazer fotos, Nikolai?
É 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:
Morphing, literalmente - morte.
Não vale a pena discutir aqui, mas Morphing ( morphing) Onde você vê pessoas mortas, sóbrio...
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.
Não.
O dobro da int é duas vezes mais rápido que o dobro