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
Acontece que eu estava olhando para a freqüência de geração da web, não para a freqüência de saída.
Estes são números diferentes, múltiplos uns dos outros.
Acontece que eu estava calculando a freqüência de geração da web (sem saída) e a freqüência de saída (sem geração) um pouco errada
Aqui está uma versão mais correta.
Resultados sobre meu processador:
Se você tomar o tempo simplesmente gerando um quadro de 200 círculos alisados sem saída, isso acontece a cerca de 500 quadros por segundo.
formando uma moldura de 200 círculos não molhados sem saída - cerca de 1000 fps.
A freqüência da saída da imagem (tela) em si (função de atualização) é de cerca de 650 fps.
Você realmente trabalhou muito!
Cuidado com as conversões em massa dos tipos (int)double ou (double)int e a mistura int+double em operações de esteiras em geral.
Isto dá a mais selvagem sobrecarga ao processador - apenas um comando de montagem tão caro. Se você contar em dobro, continue contando em dobro e não mude para os tipos inteiros.
Comandos como cvtsi2sd/cvttsd2si são muito longos. Uma pequena dica no artigo"A instrução x86 mais lenta", vilão número 2.
Obrigado por um artigo muito valioso.
Mas, para ser honesto, não entendo por que então, neste simples roteiro:
a soma de longo com conversão do tipo duplo em longo é muito mais rápida do que a soma do duplo da mesma matriz sem conversão
Em primeiro lugar, deve-se observar o código de montagem e o resultado de otimizações de casos extremamente simples (os supermicrossintéticos têm sido enganosos há muito tempo). É fácil encontrar um caso ideal de implementação de esteiras transportadoras.
Em segundo lugar, quase ninguém pode garantir como este ou aquele código será compilado e quanto tempo levará para ser executado.
Basta adicionar mais uma linha/comando no código e a velocidade muda drasticamente. O código/dados reais podem muito bem sair do cache L1/L2 e pronto.
Como funcionou para você? Em teoria/super-sintéticos parece que os comandos inteiros ajudarão na velocidade, mas em código real é um dreno. Como há dezenas/centenas de vezes mais código, não há convectorização, saltar constantemente do inteiro para cálculos reais e a otimização é limitada.
Por que a inicialização de matrizes de qualquer tipo na MQL4 é mais de 10 vezes mais lenta do que na MQL5?
Por que a inicialização de matrizes de qualquer tipo na MQL4 é mais de 10 vezes mais lenta do que na MQL5?
Porque todas as matrizes lá são dinâmicas e a linguagem é dez vezes mais lenta.
Um indicador ultra-rápido de centenas de médias móveis, implementado em Tela.
100 linhas MA (período etapa 10) - tempo de cálculo e exibição na tela - 4-7 milissegundos
1000 linhas MA (período etapa 1) - tempo de cálculo e exibição - 20-30 milissegundos.
Eu não testei muito o código. Pode haver insetos. Implementado apenas para uma barra de espessura de um pixel (é forçado a esta escala). Também a taxa de atualização da tela não é otimizada. Todas as linhas são calculadas e a saída completa a cada tick.
Um indicador ultra-rápido de centenas de médias móveis, implementado em Tela.
100 linhas MA (período etapa 10) - tempo de cálculo e exibição na tela - 4-7 milissegundos
1000 linhas MA (período etapa 1) - tempo para cálculo e exibição - 20-30 milissegundos
frio, com indicadores padrão tudo estaria morto
frio, os indicadores padrão teriam pendurado tudo.
e depois haveria uma milha de código...
talvez até mesmo isso só possa ser feito com um modelo. Não sei quanto à limitação do número de linhas indicadoras no corpo de um indicador.
...
Não ciente da limitação do número de linhas indicadoras no corpo de um indicador.
Há um limite. Podem ser feitos até 512 buffers indicadores >>>https://www.mql5.com/ru/docs/indicators