Erros, bugs, perguntas - página 2165
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
Não estou a obter um gráfico de optimização para valores negativos.
Os dados estão disponíveis nos resultados da optimização.
Tente definir valores negativos nos seus EAs. Os valores podem ser * -1 para verificar.
Uma verificação revelou que:
Este código transforma-se no seguinte código SSE do assembler:
Esta é uma obra de arte, na verdade. 8 raízes foram calculadas em 4 chamadas de uma instrução de assembler. Dois números duplos são avaliados numa chamada.
A conclusão geral: a matemática ganhou na MQL5 devido a uma optimização perfeita. Não são as arrays que perdem aqui, mas a matemática ganha.
Muito obrigado pela valiosa informação.
A notícia é, evidentemente, mais alegre. É muito fixe!
Eu sempre disse que os MQs são belezas!
Mas também percebo que se tem de ter muito cuidado com a mistura de tipos de dados. Mas o alerta é premeditado.
Seria óptimo obter alguns conselhos dos criadores a esta luz.
Agora vou fazer experiências com os tipos de variáveis e matrizes comuns. Pergunto-me o que sairá.
Tenho estado a fazer experiências.
Continuo a não conseguir montar o puzzle.
Fiz duas variantes. O primeiro - converteu tudo em tipo int. A segunda - para duplicar.
Sim, tornou-se um pouco mais rápido. Mas mesmo assim, os travões principais ainda estão presentes.
Aqui está o bloco de travagem principal com a variante int:
Tem apenas tipo int e nenhum tipo de mistura. A própria matriz SQRT tornou-se int.
Funciona apenas 10% mais rápido.
A situação com a variante dupla é semelhante.
Bem, tudo é idêntico - apenas no primeiro caso é a função sqrt() a ser calculada e há mistura de tipos.
Enquanto que o segundo caso se refere a uma matriz int e não há mistura de tipos, e em teoria só deve ser utilizada ALU.
Mas a segunda via é 3 vezes mais lenta. Bem, qualquer que seja a razão, é a matriz.
Há mais uma coisa importante.
No exemplo int, se a tela tiver o tamanho 100x100, ou seja, com os seguintes parâmetros
obtemos uma vantagem de velocidade ao aceder à matriz.
Isto é, quando se utiliza uma matriz SQRT de tamanho 20 000, ganhamos 15-20%, e quando se utiliza uma matriz de tamanho 3 000 000, perdemos 200%, apesar de uma matemática absolutamente idêntica.
Então o tamanho da matriz é a causa dos travões?
Há muito que as pessoas perderam a capacidade de compreender os resultados dos compiladores C++ modernos.
Além disso, tem uma confusão de código, o que significa quase zero possibilidade de construir axiomas ingénuos "se estas condições, então o resultado será este". Ou seja, a optimização final irá reorganizar tudo de tal forma que as suas hipóteses produzirão resultados dezenas de por cento diferentes, mesmo com alterações minúsculas no código.
Dê outra vista de olhos ao enfiar 8 raízes em 4 comandos assembler e perceba que não tem oportunidade de afirmar, exigir ou apelar à sua lógica. Os optimistas há muito que operam a níveis proibitivos para além do alcance dos programadores.
A forma como o compilador decompõe as raízes é uma arte. E está a tentar vencê-lo com arrays sem sequer compreender a restrição mais simples - a leitura a partir de uma matriz já é um fracasso. Trabalho de registo perfeito e cálculo de lote de raízes vs. ramificação (penalizações) e escalada em memória com frequentes falhas de cache.
Está a perguntar "porque é que é mais rápido em tampão pequeno e falha miseravelmente em tampão grande", porque não sabe nada sobre L1/L2/L3 caches de processador. Se entrou em cache, foi contado rapidamente. Não apanhado - esperar uma dúzia de ciclos de leitura de dados da cache superior ou da memória.Há muito que as pessoas perderam a capacidade de compreender os resultados dos compiladores C++ modernos.
Além disso, tem uma confusão de código, o que significa quase zero possibilidade de construir axiomas ingénuos "se estas condições, então o resultado será este". Ou seja, a optimização resultante irá reorganizar tudo de tal forma que as suas hipóteses produzirão resultados dezenas de por cento diferentes, mesmo com alterações minúsculas no código.
Dê outra vista de olhos ao enfiar 8 raízes em 4 comandos assembler e perceba que não tem oportunidade de afirmar, exigir ou apelar à sua lógica. Os optimistas há muito que operam a níveis proibitivos para além do alcance dos programadores.
Posso ver perfeitamente bem os resultados da vossa comparação VS e estou encantado com isso.
Mas a questão mantém-se.
Peço desculpa pelo caótico código de trabalho, mas estamos apenas a falar desta secção do código e a comparar as duas opções de execução:
Aqui não há lixo.
Disse que"a optimização doacesso à matriz dinâmica é excelente, para além dos elogios".
Mas... ver a minha mensagem anterior.
Como explica a minha última experiência?
"Ou seja, quando usamos uma matriz SQRT de tamanho 20.000, estamos a um ganho de 15-20%, e quando usamos uma matriz de tamanho 3.000.000, perdemos 200% com exactamente a mesma matemática.
Então o tamanho da matriz é a causa dos travões"?
Leia atentamente a minha resposta anterior - está completa com uma resposta exacta.
Explicarei as vossas perguntas de forma simples: leiam cinco artigos técnicos cuidadosamente sobre o design do processador em termos de desempenho e factores que o afectam. Não se pode ter uma discussão sem isso, pois é preciso explicar o básico.
A forma como o compilador decompôs as raízes é uma arte. E está a tentar vencê-lo com matrizes sem sequer compreender a restrição mais simples - a leitura a partir de uma matriz já é um fracasso. Trabalho de registo perfeito e cálculo de lote de raízes vs. ramificação (penalizações) e escalada em memória com frequentes falhas de cache.
Pergunta-se "porque é que é mais rápido num pequeno tampão e surdamente falha num grande" porque não se sabe nada sobre L1/L2/L3 caches de processador. Se entrou em cache, foi contado rapidamente. Se não o tiver, terá de esperar por algumas dezenas de ciclos de leitura de dados do cache superior ou da memória.Leia atentamente a minha resposta anterior - está terminada com uma resposta exacta.
Deixem-me explicar as vossas perguntas de uma forma simples: leiam cinco artigos técnicos cuidadosamente sobre o design do processador em termos de desempenho e factores que o afectam. Não se pode ter uma discussão sem isso, uma vez que é necessário explicar coisas básicas.
Yay!!!
Finalmente!
Você, Renat, deve ser beliscado por tudo.
A imagem é agora mais clara para mim.
Estava errado quando culpava o seu compilador. Desculpem, estava enganado. Eu poderia ter adivinhado que a razão estava em caches limitados do processador. Sou muito mau em processadores modernos e preciso mesmo de ler sobre isso.
Mesmo assim, não foi por nada que escrevi este código - rato de laboratório - e fiz esta onda.
Assim, para os programadores que lerem este tópico, vou resumir o que descobri pessoalmente como resultado desta onda:
Fui corrigir o meu código com base nesta informação. Muitas vezes abusei do tamanho das matrizes.
Obrigado a todos!
como sei se o botão da mira é premido ou solto?
pode apanhar quando a roda do rato é pressionada, mas se o rato não estiver a ser utilizado, como pode fazer isso?
como sei se o botão da mira é premido ou solto?
Pode apanhar o clique da roda do rato, mas se o rato não estiver a ser utilizado, o que é que tem?
Que tal forçá-lo ou empurrá-lo de volta quando necessário?
FERRAMENTA_DE_TRAVESSA_DE_CHAVETA
Activar/desactivar o acesso à ferramenta "mira" premindo o botão central do rato
bool (valor por defeito verdadeiro)
Pode ser forçado ou empurrado para trás, se necessário?
FERRAMENTA_DE_TRAVESSA_DE_CHAVETA
Activar/desactivar o acesso à ferramenta "mira" premindo o botão central do rato
bool (verdadeiro por defeito)
tanto quanto sei, apenas acede à ferramenta, mas não a desliga.