MQL5 vs QLUA - Por que operações de negociação no MQL5 são até 28 vezes mais rápidas? - página 3
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
Simultaneamente, é quando você tem uma diferença nas medições que flutua em torno de 10%.
Mas quando, de acordo com os resultados de dezenas de testes, você tem uma diferença estável de 4 a 5 vezes, não há o que discutir.
A diferença (não estável) no MT5 foi de até duas vezes. Por isso, decidi que, se medirmos o desempenho, devemos observar a frequência máxima (tempo mínimo entre pacotes vizinhos) com a qual os pacotes chegam. Escrevi um Expert Advisor correspondente
E obtive o resultado
E se ~10ms entre eventos BookEvent vizinhos é plausível. Mas 0,035 ms não é. Acontece que um evento BookEvent é criado pelo mesmo princípio que um evento Tick:
Portanto, essa implementação de medição não é adequada para eventos Tick/Calculate/BookEvent. E como monitorar a chegada de um novo pacote de rede de cotação em MQL5 ainda não está claro.
Qualquer teste deve conter proteção contra partida a frio.
Portanto, ignorar N ticks é um indicador de que estamos cientes desse fato e o levamos em consideração. Apenas para evitar a reclamação obviamente esperada "por que vocês não compensaram o impacto da partida a frio".
O vídeo sobre o início da sessão de três terminais foi preparado em 25 de agosto de 2016 para outra reclamação de um operador que afirmou que o MT5 fica mais lento no início da sessão. Como se descobriu mais tarde, esse operador não usava o MT5, mas transmitia especulações do fórum. Descobriu-se também que alguns operadores não sabiam que, para instrumentos de câmbio, os gráficos são construídos não por Bid, mas por preços Last negociados. Eles consideraram a alteração das ofertas e a não exibição delas nos gráficos como "freios do MT5".
É claro que não há freios.
A diferença (não estável) no MT5 foi de até duas vezes. Então, decidi que, se medíssemos o desempenho, deveríamos observar a frequência máxima (tempo mínimo entre pacotes vizinhos) com a qual os pacotes chegam. Escrevi um Expert Advisor correspondente
E obtive o resultado
E se ~10ms entre eventos BookEvent vizinhos é plausível. Mas 0,035 ms não é. Acontece que um BookEvent é criado pelo mesmo princípio que um evento Tick:
Plausível.
Os dados chegam de forma transacional e o fato de você ter visto duas transações consecutivas com tempo curto é uma grande prova da correção do nosso processamento e do desempenho do próprio terminal e do subsistema MQL5.
É muito adequado.
Veja nosso código - ele não mede especificamente dados curtos únicos, mas estupidamente coleta ticks por 30 segundos. Isso elimina quaisquer flutuações e erros.
No vídeo acima, o MQL5 recebeu 1.278 ticks em 30 segundos, enquanto o QLUA recebeu apenas 254 ticks. Isso é uma grande chatice para o algotrading do QLUA.
Plausível.
Os dados chegam de forma transacional, e o fato de você ter visto duas transações consecutivas com tempo curto é uma grande prova da correção do nosso processamento e do desempenho do terminal e do subsistema MQL5.
Mas elas vieram em um pacote em um pacote de rede. Quero medir a velocidade do gateway.
É um bom ajuste.
Observe nosso código - ele não mede especialmente dados curtos únicos, mas estupidamente coleta ticks por 30 segundos. Isso elimina quaisquer flutuações e erros.
No vídeo acima, o MQL5 recebeu 1.278 ticks em 30 segundos, enquanto o QLUA recebeu apenas 254 ticks. Isso é uma chatice cruel para o algotrading do QLUA.
Mas eles vieram em um pacote no pacote de rede. Quero medir a velocidade do gateway.
Isso não importa.
Apenas os ticks vieram um após o outro, e o terminal MT5 conseguiu fornecê-los a você de forma agradável e sem freios.
Você não me entendeu bem. Não me importo com a frenagem do QLUA - tudo está claro com ele (e não há perguntas no artigo). Quero obter as características de desempenho do próprio MT5. E apenas o modo MaxFrequency, como implementei, não se encaixa. Porque o MT5 tem uma peculiaridade com a criação de eventos Tick/Calculate/BookEvent. Execute o Expert Advisor em sua casa - você verá isso rapidamente.
O princípio"cada tick é uma transação enviada independentemente" significa que, ideologicamente, tudo foi construído corretamente. E como pode estar errado se construímos 5 plataformas do zero e passamos por todas as armadilhas mais de uma vez.
Você obteve um desempenho muito alto. O fato de você ter começado a inventar a frequência é um absurdo óbvio. Temos dados quando temos dados, quando temos dados, quando temos dados. Portanto, falar sobre "estabilidade/instabilidade da frequência" não faz sentido lógico. Você não está testando a estabilidade do oscilador de quartzo, está tentando estabilizar o processo aleatório de preços que aparecem no vidro.
É apenas o Quick que originalmente construiu todos os processos no controle da frequência do instantâneo. Com um resultado natural.
Isso não importa.
Apenas os ticks vieram um após o outro, e o terminal MT5 conseguiu fornecê-los a você de forma agradável e sem freios.
O princípio "cada tick é uma transação enviada independentemente" significa que, ideologicamente, tudo foi construído corretamente. E como pode estar errado se construímos 5 plataformas do zero e passamos por todas as armadilhas mais de uma vez.
Você obteve um desempenho muito alto. O fato de você ter começado a inventar a frequência é um absurdo óbvio. Temos dados quando temos dados, quando temos dados, quando temos dados. Portanto, falar sobre "estabilidade/instabilidade de frequência" não faz sentido lógico. Você não está testando a estabilidade de um oscilador de quartzo, está tentando estabilizar o processo aleatório de preços que aparecem no vidro.
Posso explicar facilmente o princípio da frequência. A pilha é formada pela própria bolsa em uma velocidade instável, porque depende das ações dos participantes do mercado.
Eu queria medir a frequência máxima de atualizações de pilha - quantas pilhas o MT5 pode gerar por unidade de tempo. Descobriu-se que as apostas chegam ao MT5 em pacotes. É possível que as apostas da bolsa nem sequer sejam perdidas, mas TODAS elas chegam. E o evento BookEvent é criado não para um pacote, mas para todas as apostas no pacote (da mais antiga à mais recente). É impossível obter o tempo de formação da pilha na MQL5. O tempo de chegada do pacote é o mesmo. Portanto, acontece que minha implementação da medição da característica de desempenho correspondente do MT5 não mostra o que eu quero ver.
O fato de o BookEvent ser formado em pacotes é algo que apoio com todas as minhas forças. É o máximo de informações e o mínimo de incômodo para o Expert Advisor. O único problema com a medição de desempenho é o que descrevi.
Posso explicar facilmente o princípio da frequência. A pilha é formada pela própria bolsa em uma taxa variável, pois depende das ações dos participantes do mercado.
Eu queria medir a frequência máxima de atualizações de pilha - quantas pilhas o MT5 pode gerar por unidade de tempo. Descobriu-se que as apostas chegam ao MT5 em pacotes. É possível que as apostas da bolsa nem sequer sejam perdidas, mas TODAS elas chegam. E o evento BookEvent é criado não para um pacote, mas para todas as apostas no pacote (da mais antiga à mais recente). É impossível obter o tempo de formação da pilha na MQL5. O tempo de chegada do pacote é o mesmo. Portanto, acontece que minha implementação da medição da característica de desempenho correspondente do MT5 não mostra o que eu quero ver.
O fato de o BookEvent ser formado em pacotes é algo que apoio com todas as minhas forças. É o máximo de informações e o mínimo de incômodo para o Expert Advisor. Mas há apenas um problema com a medição de desempenho que descrevi.
Repito mais uma vez: não faz sentido medir a frequência dessa forma e tirar essas conclusões.
Não tente medir a frequência de um processo aleatório de aparecimento de preços na pilha com base na diferença de tempo entre dois ticks. Obviamente, você obterá uma dispersão selvagem de números de 1 a XXXXX.
Você fez a pergunta errada, calculou incorretamente e tirou conclusões erradas. Ao mesmo tempo, você colocou uma sombra no vime com a afirmação "O MT5 não mostra o que você quer ver, você não pode medi-lo".
Não há nenhum problema de "medição de desempenho", porque você mediu a coisa errada e da maneira errada. Você apresentou a característica errada e o cálculo fundamentalmente errado.
ps: mas nos testes medimos corretamente a frequência de chegada de citações coletando citações por 30 segundos e dividindo pelo tempo gasto.
Vou repetir mais uma vez - não faz sentido medir a frequência dessa forma e tirar essas conclusões.
Não tente medir a frequência de um processo aleatório de aparecimento de preço no vidro com base na diferença de tempo entre dois ticks. Obviamente, você obterá uma dispersão selvagem de números de 1 a XXXXX.
Você fez a pergunta errada, calculou incorretamente e tirou conclusões erradas. Ao mesmo tempo, você lançou uma sombra sobre o vime com a afirmação "O MT5 não mostra o que você quer ver, você não pode medi-lo".
ps: mas medimos a frequência de chegada de cotações corretamente nos testes, coletando cotações por 30 segundos e dividindo pelo tempo gasto.
Eu meço a frequência MÁXIMA, não a atual! Eu descrevi detalhadamente o motivo de tais medições, os resultados e forneci a fonte. Por alguma razão, você acha que estou lançando uma sombra sobre o MT5.
Qualquer veterano do fórum que ler esta discussão entenderá o que eu quis dizer. E não verá nenhuma sombra em relação ao MT5. Minha implementação acabou se mostrando errada. Minha, não sua! Você está se defendendo quando eu nem sequer dei um motivo.
É a minha implementação que não permite que você meça o que deseja. A MQL5 não tem essa possibilidade e isso é normal. Assim como é normal que eu queira suco, mas a MQL5 não oferece essa oportunidade.
Eu só compartilhei o resultado que, se alguém quiser medir o tempo entre as chamadas vizinhas dos eventos correspondentes e interpretá-lo como desempenho. É necessário entender claramente o que de fato será mostrado.
Você está fundamentalmente errado.
Qual é a frequência máxima, quando você realmente vai medir o delta de um processo aleatório, em que dois eventos têm delta 0?
Se a entrega de ticks for implementada corretamente (e nós a implementamos corretamente), você obviamente obterá a "frequência" máxima = (tempo de processamento da chamada MQL5 com o código do programa) / (erro do cronômetro).
Teoricamente, se você cumprir a precisão do cronômetro e obtiver 0 microssegundos, a frequência será infinita. Bem, e o erro crítico da divisão por zero (você não tem controle da divisão por zero no seu código).
Você está fundamentalmente errado.
Qual é a frequência máxima, quando você realmente vai medir o delta de um processo aleatório, em que dois eventos têm delta 0?
Se a entrega de ticks for implementada corretamente (e nós a implementamos corretamente), você definitivamente obterá a "frequência" máxima = (tempo de processamento da chamada MQL5 com o código do programa) / (erro do cronômetro).
Sim, é assim que eu obtenho. Acontece que eu estava medindo um processo aleatório e queria medir o processo de entrega de pacotes de rede. Mas não funcionou.
Teoricamente, se você conseguir atingir a precisão do cronômetro e obter 0 microssegundos, a frequência será infinita. Bem, e um erro crítico de divisão por zero(você não tem controle de divisão por zero no seu código).