Discussão do artigo "Acelerar cálculos com a rede MQL5 em nuvem"

 

Novo artigo Acelerar cálculos com a rede MQL5 em nuvem foi publicado:

Quantos núcleos você tem no seu computador em casa? Quantos computadores você pode utilizar para otimizar a estratégia de negócio? Mostraremos aqui como usar a Rede de nuvem do MQL5 para acelerar os cálculos recebendo energia computacional através do mundo com apenas um clique no mouse. A frase "tempo é dinheiro" se torna ainda mais atual a cada ano que passa, e não podemos nos dar ao luxo de esperar por cálculos importantes por dezenas de horas ou até mesmo dias.

Acelerar cálculos com a rede MQL5 em nuvem

Autor: MetaQuotes Software Corp.

 

E quanto à genética? Lá, "100 vezes" é inatingível. Bem, se for de 20 a 30 vezes, ou até menos.

 
notused:

E quanto à genética? Lá, "100 vezes" é inatingível. Bem, se for de 20 a 30 vezes, ou até menos.


https://www.mql5.com/ru/forum/4927/page114 

stringo 2012.02.02 15:50


No cálculo do algoritmo genético, toda a próxima geração (de 64 a 256 trabalhos de cálculo) é fornecida à nuvem

Em uma pesquisa completa, uma pilha de 512 trabalhos é fornecida a cada servidor de nuvem. Então, quando um determinado número de trabalhos é concluído, o dobro do número de trabalhos é adicionado (ou seja, se um servidor de nuvem relata 5 trabalhos concluídos, ele imediatamente adiciona 10 trabalhos).

Portanto, a aceleração no GA não é de 20-30, mas de pelo menos 64 vezes, no máximo 256 vezes.

 
Urain:
portanto, a aceleração do AG não é de 20-30, mas de pelo menos 64 vezes, no máximo 256 vezes.
O AG não pode ser mais rápido do que a enumeração de um número semelhante de parâmetros. O gargalo do GA é a espera pelo agente mais lento. E isso (em média) ocorre de 10240 / 256 a 10240 / 64 vezes (de 40 a 160 vezes, com base em dados de stringo). E é o agente mais lento que determina a velocidade. Além disso, no artigo, Rosh tinha 4 agentes locais próprios -> o limite de aceleração para o GA pode ser 256 / 4 = 64 vezes (isso é para falar sobre valores comparáveis), mas na vida é muito menor.
 
notused:
O GA não pode ser mais rápido do que enumerar um número semelhante de parâmetros. O gargalo do GA é esperar pelo agente mais lento. E isso (em média) ocorre de 10240 / 256 a 10240 / 64 vezes (de 40 a 160 vezes, com base em dados de stringo). E é o agente mais lento que determina a velocidade. Além disso, no artigo, Rosh tinha 4 agentes locais próprios -> o limite de aumento de velocidade para o GA pode ser 256 / 4 = 64 vezes (isso é para falar de valores comparáveis), mas na vida real é muito menor.

Como muitos notaram, os servidores de nuvem detectam automaticamente os agentes lentos e redistribuem os passes "lentos" para outros agentes (tanto na enumeração completa quanto na genética).

Além disso, os agentes com PR>100 são aceitos na genética, o que reduz seriamente as consequências do uso de agentes lentos.

 
Farei o mesmo que Rosh, mas definirei mais limites de parâmetros, para que haja genética. Assim que tudo estiver concluído, informarei o resultado.
 

Portanto, condições de teste - 4 Intel Core i5-2500 a 3,3 GHz, 4 GB de RAM, Windows XP de 64 bits, terminal x64 bild 581 (PR = 160-180). Durante o teste, estava executando um navegador e assistindo a um filme. Foram usadas as mesmas condições do artigo (Moving Avarege Expert Advisor, H1, em OHLC a 1m + genética). Configurações:Configurações

Teste em kernels locais:

Núcleos locais

Test on Cloud (Teste na nuvem):

Nuvem

Sem hesitação, vemos que a nuvem foi 8,7 vezes mais rápida. Isso é tudo. Mas, na verdade, a rede é ainda mais lenta porque o cache de computação foi usado.

Portanto, os núcleos locais realizaram 8704 - 3666 = 5038 passagens em 30 min. 2 seg. = 1802 segundos -> 0,3577 segundos por passagem, em média.

A nuvem executou 8704 - 4455 = 4249 passagens em 3 min. 28 seg. = 208 segundos -> o tempo de espera para uma passagem da nuvem é em média 0,049 segundos.

No total, o Cloud acelerou o cálculo em um fator de 0,3577 / 0,049 = 7,3 vezes (!).

Minhas suposições iniciais de que o número provavelmente chegaria a 20 vezes acabaram sendo um pouco otimistas. E não podemos nem falar em centenas.

Sim, usei núcleos poderosos, ou seja, trapaceei um pouco. Mas o fato é que mesmo essas 4.249 passagens com genética a rede fez em 208 segundos e 1.140 passagens com pesquisa completa em 164 segundos (o tempo de espera para uma passagem é de 0,0117 segundos). No total, o teste genético de uma passagem na nuvem é, em média, mais lento do que a força bruta (usando o exemplo do EA em questão) em 0,049 / 0,0177 = 2,8 vezes.

 

Não estou criticando a rede - certamente a Cloud Network é a melhor coisa que foi feita desde que o software de negociação existe. E uma coisa muito necessária (embora não seja muito usada, mas isso virá com o tempo).

Gostaria de ser mais correto nos slogans publicitários. Ok, águas passadas

 

Se você fizer testes com o tempo de uma passagem menor que um segundo, deverá levar em conta a latência da rede, que geralmente é maior ou igual ao tempo de uma tarefa "rápida". Fizemos muitos esforços para nos livrarmos das despesas gerais do sistema com a latência da rede por meio de tarefas em lote. E fomos bem-sucedidos, embora esse problema não possa ser completamente eliminado.

Seu exemplo mostra totalmente que você competiu em uma luta de curto prazo com um tempo de trânsito conhecido por ser menor que o atraso da rede. Para realmente avaliar o poder do claud, você precisa se afastar de tarefas com tempos de execução inferiores a um segundo e se aproximar de tarefas mais caras.

Executei a genética com uma tarefa semelhante, mas com um tempo de trânsito superior a 10 segundos em um processador i7. Publicarei os resultados após a conclusão dentro de uma hora.

 

Durante 3 min. 28 segundos de uso da rede, foram cobrados 2 ou 3 centavos (3 centavos no terminal, 2 centavos no site e 3 centavos congelados). Que seja 3 ou, para simplificar, usar a rede para fins genéticos custa 1 centavo por um minuto. No total, uma hora custa 60 centavos, 24 horas = US$ 14,4. Isso parece muito caro para mim. Os preços deveriam ser reduzidos pelo menos três vezes para torná-los atraentes para os consumidores (muitas pessoas testam os EAs, mas nem todos podem/dispõem-se a pagar cerca de US$ 15 por dia pela nuvem e, se fosse US$ 5 ou menos, haveria mais pessoas dispostas).

Além disso, já descobri por mim mesmo como fazer uma pré-estimativa do custo de otimização de qualquer EA (em média, é claro). Algoritmo para genética (similarmente para força bruta):

1) Execute a genética Moving Avarage nos núcleos locais (+ você também pode conectar seus agentes remotos); no final, calcule o tempo de espera para uma passagem -> T1

2) Calcule T1 / 0,049 = T2 - quantas vezes a otimização é acelerada pela genética na nuvem.

3) Execute a otimização nos núcleos locais (+ você também pode conectar seus agentes remotos; isso deve ser configurado como na etapa 1) do EA necessário e aguarde, por exemplo, 100 passagens. Calcule o tempo de uma passagem (pelo log - encontre o primeiro e o último registros) -> T3

4) 10240 * T3 / T2 = T4 -> tempo estimado de teste na nuvem.

5) T4 / 60 = custo do teste em centavos.

(você também pode levar em conta seus núcleos, para isso usamos T2' = T2 + 1).

Tudo isso é uma estimativa baseada na otimização Moving Avarage. Talvez em um ou dois meses, núcleos mais potentes entrem em operação e os números mudem, assim como o custo.

Acho que minha linha de pensamento está clara

 
Renat:

Seu exemplo mostra completamente que você estava competindo em uma luta de curto prazo com um tempo de passagem conhecido por ser menor que o atraso da rede.

Sim, eu suspeitava disso, mas não levei em consideração. Vamos aguardar seus resultados.

E minha postagem anterior, par. 2 terá de ser corrigido após seus testes.