Optimização no Testador de Estratégia - página 16

Novo comentário
 
Renat:

Nas últimas construções, livrámo-nos completamente das despesas gerais do sistema em tarefas, reduzindo-as de quase 2000 ms para zero.

Aqui estão os resultados da execução de uma tarefa de cálculo, que foi sugerida pela joo:

Definições (as datas são fixadas de propósito para que o histórico do gráfico não seja utilizado):

Parâmetros a executar:

Agentes utilizados (4 agentes locais):

Resultados da optimização:

A optimização demorou apenas 25 segundos e foram feitos 18.432 passes:

Voltando à velha tarefa de optimização do testador de estratégias comerciais.

As melhorias no plano geral para a construção 425 resultaram em melhorias:

  • redução das despesas gerais do sistema na preparação dos passes
  • adição de um modo explícito de "cálculos matemáticos" à selecção do tipo de simulação que simplificou a configuração

Novamente com o mesmo hardware (4 agentes locais) e caches limpos na construção 425: 

Tester	optimization passed in 0 minutes 07 seconds
Tester	genetic optimization finished on pass 19456 (of 100000020000001)
Tester	result cache was used 10124 times
Tester	genetics is over

Em comparação coma questão original levantada(a sobrecarga era de 2 segundos por passagem), resolvemos com sucesso o problema. A mesma tarefa começou a contar em 7 segundos em vez de 25 segundos.

A base da luta contra as despesas gerais do sistema era a realização de tarefas em lote. Agora cada agente tem a sua velocidade de execução medida, e foi-nos dado um lote de 1-64 tarefas para cálculo. Como resultado, o tempo necessário para preparar testes e obter resultados é proporcionalmente reduzido. Os agentes rápidos recebem mais tarefas e lotes maiores do que os lentos. Isto é especialmente benéfico para tarefas de cálculo rápido, onde o tempo útil de cálculo é comparável ao tempo de preparação do teste e de encaminhamento dos resultados.

O trabalho para optimizar a manutenção dos agentes ainda não está concluído. Para o trabalho eficiente dos agentes remotos na MQL5 Cloud Network, a redução dos custos de comunicação é a principal questão.

 

Ajude a compreender!

Os seguintes blocos de código funcionam bem no terminal numa conta de demonstração, mas quando testados, dão uma mensagem deerro 4109.

if(!ChartGetDouble(0,CHART_PRICE_MAX,0,price_max))
 {
  printf(__FUNCTION__,": Не получены данные по максимальной цене. Ошибка: %g.",GetLastError());
 }

A mesma situação acontece com

if(!ChartGetDouble(0,CHART_PRICE_MIN,0,price_min))
 {
  printf(__FUNCTION__,": Не получены данные по минимальной цене. Ошибка: %g.",GetLastError());
 }
 
slyusar:

Ajude a compreender!

Os seguintes blocos de código funcionam bem no terminal numa conta de demonstração, mas quando testados, dão uma mensagem deerro 4109.

A mesma situação acontece com

Os gráficos e objectos gráficos não são modelados durante os testes porque reduz drasticamente a velocidade de teste.
 
Renat:
Os gráficos e objectos gráficos não são modelados durante os testes, uma vez que isto reduz catastroficamente a velocidade dos testes.
Estou a ver, obrigado. Há alguma forma de sair desta situação?
 
Renat:
Os gráficos e objectos gráficos não são modelados durante os testes, uma vez que isto reduz catastroficamente a velocidade dos testes.
Espero realmente que este tipo de simulação sem gráficos só esteja em modo sem "visualização".
 
sergeev:
Espero realmente que este tipo de modelação sem gráficos seja apenas num modo sem "visualização".
Totalmente apoiantes, os gráficos são por vezes muito necessários...
 
Renat:

Voltando à velha tarefa de optimizar o testador de estratégias comerciais.

As melhorias no plano global para a construção do 425 resultaram em melhorias:

  • redução das despesas gerais do sistema na preparação dos passes
  • adição do modo explícito "cálculos matemáticos" na selecção do tipo de simulação, o que simplificou a configuração

Outro resultado sobre o mesmo hardware (4 agentes locais) e caches limpos em 425 construídos:

Em comparação coma questão original levantada(a sobrecarga era de 2 segundos por passagem), resolvemos com sucesso o problema. A mesma tarefa começou a contar em 7 segundos em vez de 25 segundos.

A base da luta contra as despesas gerais do sistema era a realização de tarefas em lote. Agora cada agente tem a sua velocidade de execução medida, e foi-nos dado um lote de 1-64 tarefas para cálculo. Como resultado, o tempo necessário para preparar testes e obter resultados é proporcionalmente reduzido. Os agentes rápidos recebem mais tarefas e lotes maiores do que os lentos. Isto é especialmente eficaz para tarefas de cálculo rápido, em que o tempo de cálculos úteis é comparável ao tempo de preparação de testes e de envio de resultados.

O trabalho para optimizar a manutenção dos agentes ainda não está concluído. Para o trabalho eficiente dos agentes remotos na MQL5 Cloud Network, a redução do custo de fornecer comunicação é a questão principal.

Uma mudança muito séria para melhor - obrigado.

E quanto ao limite de 64 parâmetros? É o único factor, pelo menos para mim, que impede a utilização plena do optimizador. Já quero esquecer qualquer alarido e escrever para o mundo "real", para que o testador possa ser optimizado sem quaisquer alterações no código.

 
Lidaremos com os parâmetros depois de executar o visualizador de testes.
 
joo:

Uma mudança muito séria para melhorar - obrigado.

E quanto ao limite de 64 parâmetros? Esse é o único factor, pelo menos para mim, que restringe a utilização em larga escala do optimizador. E como quero esquecer toda essa confusão e escrever para código "real" de uma só vez para poder optimizá-lo no testador sem quaisquer alterações no código.

Eu apoio-vos.
Renat:
Trataremos dos parâmetros após o início do visualizador de testes.
Obrigado!
 
Renat:

Voltando ao velho problema de optimizar o testador de estratégias comerciais.

Os resultados seguintes sobre o mesmo hardware (4 agentes locais) e caches limpos em 425 construídos:

Em comparação coma questão original levantada(a sobrecarga era de 2 segundos por passagem), resolvemos com sucesso o problema. O mesmo problema é agora de 7 segundos em vez de 25 segundos.

Na próxima construção a ser lançada, temos feito muito trabalho para optimizar o cálculo de massa de problemas matemáticos. As despesas gerais do sistema foram reduzidas a zero.

Agora a mesma tarefa no mesmo hardware (Intel Q9400, 4 núcleos locais) para ~18 000 cálculos demora 1 segundo (a última vez foi de 7 segundos, enquanto que antes demorou 25 segundos):

2011.04.04 20:12:34    Tester    optimization passed in 0 minutes 01 seconds
2011.04.04 20:12:34    Tester    genetic optimization finished on pass 18432 (of 1000000002000000001)
2011.04.04 20:12:34    Tester    result cache was used 9718 times
2011.04.04 20:12:34    Tester    genetics is over


Para comparação posso mostrar quanto tempo no mesmo hardware a mesma tarefa matemática gasta para calcular 4 milhões de passagens (reduzindo a etapa para 0,005 o número total de cálculos passou a ser de 4 milhões, o que permite executar o cálculo completo):



2011.04.04 20:10:34    Tester    optimization passed in 0 minutes 46 seconds
2011.04.04 20:10:34    Tester    optimization finished, total passes 4004001


Em 46 segundos ocorre o erro de cálculo total de 4 milhões de tarefas, a janela de resultados da optimização mostra todos os 4 milhões de linhas com resultados, toda a tabela é instantaneamente ordenada em quaisquer campos, o gráfico de optimização está a renderizar com rapidez todos os 4 milhões de valores, o gráfico 3D está a desenhar uma superfície 3D a partir dos mesmos resultados e a rodá-la em ângulos diferentes:

1...910111213141516171819
Novo comentário