MT5 e velocidade em ação - página 61
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
Sinto que este muro do MQ não conseguirá passar sem o apoio dos membros do fórum. O código é curto, os profissionais devem ser capazes de descobri-lo rapidamente. Lá não há falhas. É claramente demonstrado que os preços através de posições são obtidos muito mais rapidamente do que através do Market Watch. Como a MQ não consegue ver o óbvio - eu não entendo.
1. Seu teste realmente conta uma micro porcentagem das iterações devido à condição
Em essência, você só conta anomalias onde o processador está sobrecarregado com tarefas e deixa de executar uma determinada tarefa na prateleira distante, pois mais de 99% das iterações são executadas em menos de 1 microssegundo.
E mesmo se você definir a condição >0, ainda não há objetividade.
2. A medição do tempo de operações tão rápidas deve ser feita apenas como um tempo de ciclo completo, não como uma única iteração.
3. mas como o ciclo em seu exemplo é limitado a 10 segundos (Por quê! Para carrapatos, acho que 0,1 segundo é o suficiente. Porque pode muito bem acontecer que 3 ticks cheguem em um segundo, e todos os três ticks sejam executados por 10 segundos cada um, e em paralelo), portanto, não é necessário nenhum timing. É mais fácil calcular quantas iterações serão executadas em um determinado tempo. Quanto mais, maior será a produtividade.
Eu modifiquei seu código "um pouco". Acho que minha variante reflete melhor a realidade.
O cálculo é feito um de cada vez, a fim de não misturar as duas variantes. Os carrapatos numerados pares são paraSYMBOL_BID, ímpares - para GetBid().
Acrescentei somas e seus resultados apenas por precaução, como uma tentativa de enganar o compilador contra a otimização.
O resultado de saída é cumulativo.
Meu resultado:
Como você pode ver, a diferença de desempenho é três vezes a favor da versão padrão.
Como você pode ver, a diferença de desempenho é três vezes a favor da versão original.A versão original do fxsaber mostra a vantagem do GetBid, ou trata-se de um PC mais potente/menos carregado?
A versão original da fxsaber mostra a vantagem da GetBid, ou é mais potente/menos carregada?
Sua variante também mostrou a vantagem da GetBid com carga total da CPU. Mas ao mesmo tempo, minha variante mostra três vezes a vantagem da função regular com a mesma carga.
Isto porque minha variante leva em conta o tempo médio de todas as iterações de obter o preço de licitação e é apenas uma pequena fração com pendências anômalas.
Quem sabe por que razão o processador fica atolado com a função normal (quando o atraso é superior a 100 µ) em um "minuto" difícil. Mas ainda assim o tempo médio é três vezes menor para a função regular
Assim, por exemplo, se (Intervalo###A > 100) este for o caso:
enquanto que se (Intervalo##A > 0) já for bem diferente, mostrando uma distribuição aleatória de atrasos anormais entre a versão regular e a versão alternativa de obter o preço de licitação
ao mesmo tempo em que meu teste na mesma carga de CPU mostra:
Portanto, acho que a versão do teste da fxsaber está longe de ser objetiva.
Eu não carreguei a CPU com agentes, mas com este roteiro. Foi mais eficiente.
após uma pequena modificação do teste fxsaber para demonstrar claramente qual porcentagem das iterações é contabilizada nos cálculos:
ou seja, aproximadamente 0,01%.
Você pode apostar.
Se o tempo médio de execução do SymbolInfoDouble(_Symbol, SYMBOL_BID) é de cerca de 50 nanossegundos, somente aqueles com tempo de execução superior a 100 000 nanossegundos são levados em conta.
após uma leve modificação do teste fxsaber para demonstrar claramente qual porcentagem das iterações é contabilizada nos cálculos:
ou seja, aproximadamente 0,01%.
Você pode apostar.
Se o tempo médio de execução do SymbolInfoDouble(_Symbol, SYMBOL_BID) for de cerca de 50 nanossegundos, somente aquelas iterações superiores a 100 000 nanossegundos são contadas.
Poderíamos simplesmente ter feito a condição não mais que 100 µs, mas mais que 3 µs. O resultado foi aparentemente o mesmo. A idéia era que um estudo segmentar e em diferentes condições de execução pode haver uma diferença em diferentes segmentos e em diferentes seções. As prioridades de execução são muitas vezes feitas dependendo de qualquer coisa. Com uma carga leve algumas prioridades, com carga alta outras, com carga crítica, aquelas que não deixam o computador pendurar e travar, e o desempenho passa para segundo plano.
Geralmente, o comércio com uma carga de mais de 70% do hardware não é correto. É um desempenho quase crítico. A carga de ferro em EAs de combate não deve exceder 60%.
e você já tem corretores HFT?)
tente testar SymbolInfoTick quando há apenas um símbolo na visão geral do mercado e quando há dezenas de símbolos, mas peça uma ferramenta - como em seu exemplo
há uma alta probabilidade de que o servidor esteja enviando tráfego comprimido e que o SymbolInfoTick esteja passando por essa desaceleração intermitente ao descompactar os dados
ou seja, quando há muitos símbolos, haverá mergulhos ainda mais freqüentes ou mais profundos em tempo de teste
Em construções recentes, o recebimento de carrapatos não tem efeito nem mesmo teoricamente. Praticamente, SymbolInfoTick já funciona com cache, mas alguns cidadãos continuam procurando um gato preto.
Não está nem 80% no teste. Existem 6 agentes funcionando em 4 núcleos, ou seja, 100% garantidos.
A única questão é como o agendador de tarefas de seu sistema está lidando com a situação. Ao mesmo tempo, os autores afirmam que a culpa é da implementação do terminal.
Ou seja, uma situação é criada artificialmente quando um computador é sobrecarregado, quando literalmente tudo nele fica mais lento, e então são feitas algumas reivindicações na forma de "Oh, olha, por que o terminal às vezes está atrasado".
Vamos fechar os olhos para o fato de que mesmo em tais condições é "cerca de 0,01%" - para o inferno com os detalhes! Basta dizer que "ninguém se preocupa com a temperatura média hospitalar", "os atrasos causam problemas no comércio" e "queremos o HFT".
Além disso, é claro que queremos HFT em 20 especialistas em uma antiga mesa de escritório ou em uma máquina virtual morta.
PS PositionSelectByTicket() em sua implementação certamente tem acesso a um recurso compartilhado com sincronização de acesso. E se você não selecionar a posição em cada chamada, você está lendo o preço antigo. Foi mais fácil "instantâneo" via SymbolInfoDouble.