Erros, bugs, perguntas - página 2963
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
O Indicador1 e o Indicador2 devem então ser sincronizados de alguma forma para que ambos os números possam ser escritos na mesma linha comum.
Esta é uma solução muito complexa.
Porque precisariam eles de ser sincronizados? user32.dll fará isso por eles.
O principal é numerá-los correctamente, para que cada número tenha um número único e este número seja um índice da matriz de dados.
Isto pode, como último recurso, ser feito manualmente. Ou pode fazê-lo automaticamente. A propósito, publiquei recentemente algo semelhante em KB(Indicator Cases).
O que há para não gostar nos recursos? Penso que é óptimo dentro dos limites de um terminal. A variante que sugiro, utilizando o user32.dll (implementei esta variante há cerca de 10 anos atrás, quando era jovem e estava a fazer arbitragem), o tempo de acesso e a análise de dados são de cerca de 50 microssegundos (penso que pode ser acelerada em 1,5-2 vezes). É mais lento com os recursos?
Porque precisariam eles de sincronizar? user32.dll fará isso por eles.
Tente escrevê-lo. Talvez não compreenda totalmente a tarefa.
Porque não gosta de recursos? Penso que é óptimo dentro dos limites de um único terminal. A variante que sugeri utilizando a user32.dll (implementei esta variante há cerca de 10 anos, quando estava a fazer arbitragem quando era jovem) tem um tempo de acesso e análise de cerca de 50 microssegundos (penso que pode ser acelerada 1,5-2 vezes). É mais lento com os recursos?
São necessários 100 microssegundos para ler numa máquina doméstica em condições ideais. Um consultor especializado num único tick pode causar uma centena de leituras. É lento.
Em condições ideais, a GlobalVariableGet será executada em 10 microssegundos. Mas isso não é um indicador, pois em condições de combate novas para mim é um travão horrível.
Isto é HistoryTicks - apanhar todas as carraças para EAs. Portanto, EventChartCustom não é adequado, tem a sua própria fila de espera. O mesmo se passa com o tampão.
Tenho-o a trabalhar no EventChartCustom. 99,8% das carraças são recebidas dentro de 0,15 ms.
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
EventChartCustom => indicador é demasiado lento
Andrey Khatimlianskii, 2019.12.12 09:27
Aqui estão as estatísticas para 9 horas de trabalho com 5 símbolos:
O consultor especializado estava no GBPUSD, pelo que a nativa OnTick trabalhou para ele.
Não houve erros de "indicador é demasiado lento".
Em contraste, a percentagem de carraças falhadas e a latência média é muito mais elevada no VPS da MQ (mais tarde publicarei as estatísticas).
E há muitos erros de "indicador é demasiado lento".
Não compreendo a natureza do transbordo de filas, porque o Conselheiro Especialista processa imediatamente os eventos acumulados (ele apenas regressa).
Alguém mais o processa?
Tenho-o a trabalhar noEventChartCustom. 99,8% das carraças são recebidas dentro de 0,15 ms.
Envio carraças do indicador através disto: sparam contém MqlTick, lparam - número de carraça.
O Conselheiro Especialista em OnChartEvent captura estes carrapatos. E precisa de compreender se o tick actual é o mais real ou não? Isto é, há uma fila de carraças ou está vazia?
Para isso, lê o número (a tarefa é ler este número) do último tick enviado pelo indicador. Se a carraça tiver o mesmo número - a fila está vazia, e é possível começar a trabalhar com carraças.
E durante o funcionamento da OnTick, após o OrderSend é necessário verificar se o indicador enviou mais carraças. Para isso, precisamos novamente de ler o número do indicador. E pode haver mais de uma centena de tais verificações durante um OnTick. É por isso que precisamos de ler rapidamente.
Dentro de 1 terminal, o winapi mais rápido será a alocação de memória (global dentro de um processo) e funções interbloqueadas como https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange.
Estes são não-bloqueantes, atómicos e essencialmente executados em algumas instruçõessm.
Dentro de 1 terminal, o winapi mais rápido será a alocação de memória (global dentro de um processo) e funções interbloqueadas como https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange.
Estes são não-bloqueantes, atómicos e essencialmente executados em algumas instruçõessm.
Não sem um exemplo.
Para tal, lê o número (a tarefa é ler este número) do último tick enviado pelo indicador. Se o carrapato recebido tiver o mesmo número - a fila está vazia, e pode começar a trabalhar com um pacote de carrapatos.
E durante o funcionamento da OnTick, após OrderSend é necessário verificar se o indicador enviou mais carraças. Para isso, precisamos novamente de ler o número do indicador. E pode haver mais de uma centena de tais verificações durante um OnTick. Por conseguinte, precisamos de o ler rapidamente.
Inicialização.
1. Na primeira linha (muito provavelmente, a linha de escrita), atribuir memória de qualquer forma para a variável do tamanho requerido.
2. Nos fios necessários (fios de leitura), enviar o endereço desta memória.
Trabalho básico.
3. O fio de escrita inicia InterlockedExchange ou InterlockedExchange64 dependendo do tamanho da variável para escrever para ele.
4. A leitura do fio puxa, por exemplo, InterlockedCompareExchange para ler.
Conclusão.
5. Libertar memória alocada, de preferência no mesmo fio que a alocou.
Se necessário, pode ser repetido para a criação de vários balcões. Do lado negativo, necessitará da ligação WinAPI. Das características do endereço de memória atribuído deve ser alinhado, mas por defeito normalmente é.
O trabalho será dentro de 1 processo, a memória é partilhada para os fios de 1 processo. Se necessário, existem outras funções interligadas como InterlockedDecrement, InterlockedAdd, etc.
As funções são não-bloqueio, não esperar por nada, autómatos, são executadas em algumas instruçõessm.
P.S. Tanto quanto me lembro, as operações regulares de leitura e escrita via móvel em assembler são de qualquer forma atómicas. E se o compilador não fizer confusão (não deveria em teoria), podemos tentar ler e escrever para a variável na memória atribuída e será atómica.
Se se adequar à tarefa, é improvável que seja mais rápido dentro de 1 processo. Para interprocessamento o mais rápido será semelhante, mas com memória partilhada, neste caso não se pode passar sem WinAPI.
Este esquema não parece funcionar. Mostrar um exemplo elementar, por favor.
Por que não ser exequível? Tal como eu vejo as coisas. O princípio "getter setter".
Obter o valor de uma variável oculta através de uma função.
Se passar a estrutura MqlTick, defina a sua estrutura com os campos definidos como MqlTick, e adicione o seu campo contador à estrutura.
E devolver esta estrutura da função de exportação.
Um exemplo elementar para o indicador. Não prestar atenção ao exemplo no guião.
No Expert Advisor, ligue para GetTickStruct e obtenha toda a estrutura com o seu contador.
No Expert Advisor que chama GetTickStruct, obtém toda a estrutura, com o seu contador.
Por favor escreva uma transferência de número elementar de indicador para EA.
Uma transferência de número elementar de indicador para EA, escreva por favor.
Substituir a estrutura por uma variável ))