MT5 e velocidade em ação - página 63
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
Caros desenvolvedores, poderiam me informar como a MQL_MEMORY_USED é calculada?
Eu fiz um cálculo da memória que todas as variáveis EA ocupam.
É inferior a 10%. Se eu entendi corretamente, MQL_MEMORY_USED contém o cache de Histórico e o cache CopyTicks. Mas ainda é muito menos.
Ao mesmo tempo, o Expert Advisor paralelo consome várias vezes menos. Mas o princípio é o mesmo.
Em geral, o que está incluído neste valor?
Salvei um modelo com o Expert Advisor e o apliquei no mesmo gráfico, causando recarga. Já o vi assim.
O uso da memória mudou quase por uma ordem de grandeza. Até agora, é difícil explicar o que isso significa.
Muitos programas têm efeito cumulativo do uso de memória. Este é um pecado de navegadores e às vezes até de palavras. O Terminal também pode ser culpado por isso. Além disso, todos os registros são escritos por padrão e é fácil passar uma semana se você tiver muitas ações em um giga. Este é um mal que deve ser gerenciado. Mas não está claro como.
Talvez você saiba como programar um instrumento financeiro e não ficar pendurado por muito tempo ?
Através de um indicador
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
MT5 e Velocidade em Ação
Renat Fatkhullin, 2020.10.14 04:15
Para o tiquetaque em massa, coloque mais memória.
4gb (preço de 20 euros) não é bom em 2020 quando se trata de análise e pesquisa.
Para os produtos de mercado, esta abordagem não é boa em nenhum lugar. Temos que contornar a retenção de 10 segundos de dados desnecessários através de uma muleta desse tipo.
Fazer um produto de mercado trivial na forma de uma Market Screener não é na verdade uma tarefa viável para a MT5 devido ao consumo excessivo de memória.
Fazer um produto trivial de mercado na forma de uma Market Screener não é na verdade uma tarefa viável para o MT5 devido ao consumo excessivo de memória.
O terminal come tanta memória após o lançamento.
Após a execução do screener, começou a comer 2 gigs (TERMINAL_MEMORY_USED e não diminuiu com o tempo). Isto é com apenas um gráfico aberto para 5000 M1-bars.
Não salvou uma captura de tela. Mas decidiu dar um exemplo, que mostra um Terminal que come memória e não em si mesmo, onde é apenas estúpido.
O roteiro simplesmente faz cópias dos símbolos originais do Market Watch. Eu deveria adicionar todos os símbolos no MQ-Demo e executar este roteiro pela primeira vez no frio e depois novamente no quente.
E depois da corrida quente (quando os carrapatos já estão em SSD na forma de arquivos tkc) vou observar um enorme esgotamento de memória onde não é necessário em uma implementação adequada.
Entretanto, rodando o roteiro, descobri que ele está pendurado no MQ-Demo. Ele só pode ser descarregado através de terminação anormal, após o que o Terminal não libera mais de 1 GB de memória.
É fácil comparar esta captura de tela com a do início.
Desculpe, não tenho certeza se se trata de um bug ou de uma característica. Ainda não encontrei uma resposta por conta própria. Mas a pergunta está relacionada ao desempenho e suponho que é melhor fazê-la aqui.
Se adicionarmos, por exemplo, 22 buffers do tipo DRAW_SECTION a um indicador vazio, então na inicialização de tal indicador para um gráfico contendo 1000000 barras ou mais, o terminal se atrasa significativamente (causa uma carga significativa na CPU) e come quantidades significativas de memória, mesmo que o indicador não calcule nada.
Meu interesse foi despertado pelo fato de que se você usar amortecedores com outros tipos, tudo funciona sem problemas e tal desaceleração não é observada.
Por exemplo, executei o seguinte código em um único gráfico com 1000000 barras e ele consumiu cerca de 500 MBytes e desfasamentos, especialmente o próprio gráfico.
Mas se eu mudar o tipo de amortecedor para, digamos, DRAW_LINE, a carga no processador é reduzida drasticamente, os atrasos não são observados e a memória consome 5 vezes menos (cerca de 100 MBytes consumidos).
Testes semelhantes foram feitos em construções diferentes, até 2019 e a situação é a mesma.
Um cidadão individual retirouum duplicado de uma carga inestimável de código MQL de suas calças largas, o que mostrou que sob as mesmas condições a muleta funcionava mais rápido que a função normal.
Um teste muito simples:
20 Consultores especialistas em EURUSD, ou seja, todos os processos OnTick simultaneamente. A construção do terminal é 2664. O teste está sendo executado sem otimização, compilação e outras cargas adicionais a 100% CPU - você não vai executar um verdadeiro "hft" de negociação com este fundo, vai?
Diário de teste típico:
Um teste muito simples:
20 EAs no EURUSD, ou seja, todos os processos OnTick ao mesmo tempo. Terminal construído 2664. O teste está funcionando sem otimização, compilação e outra carga de trabalho adicional em 100% CPU - você não vai executar um verdadeiro "hft" de negociação com este fundo, vai?
Diário de teste típico:
Você cria condições de estufa ao fazer iterações de 100K durante 1,5 segundos no mesmo tick. Eu, por outro lado, esperei propositadamente por carrapatos que não geraram um OnTick.
Olhando através de meus registros comerciais, percebo a execução do SymbolInfoTick dentro de alguns milissegundos. E eu sei por 100% que a CPU estava ociosa naquela época.
É muito simples. Há, condicionalmente, 1 milhão de carrapatos por dia. Mesmo 0,01% dos carrapatos desaceleram 100 carrapatos por dia com defasagens. Você dirá que isso é um absurdo. Eu direi que é ruim. Se eu me deparar com um atraso quando preciso fazer um pedido, é uma perda monetária potencial.
Muito grato por este ramo não passar despercebido, e sobre esta característica em particular, muito trabalho tem sido feito para acelerar as coisas. Entretanto, foi um pouco surpreendente para mim que a horrível muleta pudesse superar a função normal em certas situações. E talvez, se você o resolvesse e eliminasse esse atraso, 100 atrasos potenciais por dia se transformariam em 10.
Eu digo que é muito melhor do que era no início do fio. Mas o fato é que há momentos em que isso não é bom. E eu posso ver que você não quer investigar isso. Eu respeito sua escolha.
Acima citamos a opção de obter os preços atuais. Me serviria completamente se não pegasse o atraso de milissegundos na máquina de ociosidade da UCP.
Também estou preocupado não só com a velocidade da SymbolInfoTick, mas também com a relevância dos preços que ela retorna. Vejo que você não levanta esta questão. Aparentemente, você decidiu olhar para ela mais tarde.
Você cria condições de estufa fazendo iterações de 100K dentro de 1,5 segundos no mesmo tick. Eu, por outro lado, esperei especificamente por carrapatos que não desovaram OnTick.
Ao rever meus registros comerciais, noto que o SymbolInfoTick está funcionando por alguns milissegundos. Eu sei 100% que a CPU estava ociosa naquele momento.É muito simples. Em um dia há, condicionalmente, 1 milhão de carrapatos. Mesmo uma defasagem de 0,01% é de 100 ticks por dia com defasagens. Você dirá que isso é um absurdo. Eu direi que é ruim. Se eu me deparar com um atraso quando preciso fazer um pedido, é uma perda monetária potencial.
Muito grato por este ramo não passar despercebido, e sobre esta característica em particular, muito trabalho tem sido feito para acelerar as coisas. Entretanto, foi um pouco surpreendente para mim que a horrível muleta pudesse superar a função normal em certas situações. E talvez, se você o resolvesse e eliminasse esse atraso, 100 atrasos potenciais por dia se transformariam em 10.
Eu digo que é muito melhor do que era no início do fio. Mas o fato é que há momentos em que isso não é bom. E eu posso ver que você não quer investigar isso. Eu respeito sua escolha.
Acima citamos a opção de obter os preços atuais. Me serviria completamente se não pegasse o atraso de milissegundos na máquina de ociosidade da UCP.
Também estou preocupado não só com a velocidade da SymbolInfoTick, mas também com a relevância dos preços que ela retorna. Vejo que você não levanta esta questão. Aparentemente, você decidiu olhar para ela mais tarde.
Estas não são condições quentes de forma alguma. Um loop para 100000 pedidos de preço sem Sono() e similares e em 20 fios simultaneamente é um teste de estresse óbvio. Nada como isso deveria estar sequer perto em condições reais.
Se você acha que não há mais carrapatos chegando em 1,5 segundos - ok, faça 10 milhões de consultas, isso não vai mudar nada, sua "muleta" funciona pior:Esta afirmação que você está fazendo é 100% falsa:
Assim como esta sua declaração anterior:
O acesso aos preços através do SymbolInfoTick é agora muito rápido e está completamente desacoplado do processamento de tick stream. Você está trabalhando com um cache de preços pronto, que é atualizado muito parcimoniosa e rapidamente.
Todos os "0,01% de desaceleração da taxa de tick-downs" só aparecem sob condições de teste de estresse, e isso é um ótimo resultado. Em condições normais, o acesso é garantido muito rápido.
Se você admitir que "muito trabalho foi feito para acelerar" SymbolInfoTick, então você deve acreditar que a "muleta" de obter preços via PositionSelectByTicket não pode ser uma solução melhor.
Por uma razão simples - a implementação do PositionSelectByTicket é completamente idêntica à implementação "lenta" original do SymbolInfoTick.
Como escrevi acima, esta implementação não é lenta no sentido literal da palavra, mas sob carga pesada de CPU, ela tem uma maior probabilidade de tempos de execução mais longos (o que é claramente visível em meu último teste).
Os horários aqui são altamente dependentes do programador de tarefas do sistema rodando sob carga, ou seja, pode haver diferenças de sistema operacional para sistema operacional e até mesmo de versão para versão.
E quanto mais pesada for a carga, mais se testa o desempenho do agendador de tarefas, não do terminal.
Esse é o fim do tópico de desempenho SymbolInfoTick.
Se seus especialistas criam carga no nível dos testes de estresse sintéticos, há apenas uma solução: "o hardware deve corresponder às tarefas".
Tenho uma pergunta sobre a relevância dos carrapatos dados pela SymbolInfoTick.
Situação:
1. Fazemos TimeCurretn(); temos tempo 18:00:00
2. Do SymbolInfoTick em um símbolo não etiquetado. Recebemos um tique com o horário 17:58:00.
3. dormir(1)
4. Adiciona um SymbolInfoTick para o símbolo não-esquerdo. Recebemos um tique com a hora 17:59:00.
Isto é, no quarto item temos um novo tick, que é um minuto diferente do TimeCurretn().
Você vê algum problema nesta situação?
Como entrar nesta situação com menos freqüência ?
Tenho uma pergunta sobre a relevância dos carrapatos dados pela SymbolInfoTick.
Situação:
1. Fazemos TimeCurretn(); temos tempo 18:00:00
2. Do SymbolInfoTick em um símbolo não etiquetado. Recebemos um tique com o horário 17:58:00.
3. dormir(1)
4. Adiciona um SymbolInfoTick para o símbolo não-esquerdo. Recebemos um tique com o horário 17:59:00.
Isto é, no quarto item temos um novo tick, que é um minuto diferente do TimeCurretn().
Você vê algum problema nesta situação?
Como entrar nesta situação com menos freqüência ?
SymbolInfoTick envia os dados recebidos do servidor do corretor. O que o servidor enviou é o que você recebe.
Se houver dúvidas sobre o tick stream que é transmitido por seu corretor, então você tem que entrar em contato com seu corretor.