MetaTrader 5 Strategy Tester e MQL5 Cloud Network - página 2

 
Interesting:

É aqui que fica mais detalhado. Tanto quanto sei, existe um núcleo por corrida, mas é possível escolher qual + é possível executar vários terminais.

Para execução única (não em modo de optimização, mas em execução única) pode escolher um dos agentes locais ou um dos agentes remotos (trabalhando em modo servidor).

Para uma única execução, não se pode seleccionar um agente da MQL5 Cloud Network, porque não faz qualquer sentido prático ou económico.

Grosso modo, não faz sentido inicializar um poderoso sistema distribuído de Rede MQL5 com levantamento de cache e preparação de dados para um único teste. O objectivo da MQL5 Cloud Network é realizar cálculos de optimização massiva.

 
Renat:

Para uma única execução (não em modo de optimização, apenas uma única passagem), pode seleccionar um dos agentes locais ou um dos agentes remotos (trabalhando em modo servidor).

Para uma única execução, não se pode seleccionar um agente da MQL5 Cloud Network, porque não faz sentido prático ou económico.

Grosso modo, não faz sentido inicializar um poderoso sistema distribuído de Rede MQL5 com levantamento de cache e preparação de dados para um único teste. O objectivo da MQL5 Cloud Network é realizar cálculos de optimização massiva.

A propósito, pensei nisso - podemos fazer algum tipo de "cálculo" preliminar, por exemplo, analisar a velocidade de transferência de cache (tempo de subida) como um menos e mais valias de mais núcleos e compará-la apenas com o tempo de teste local para dar alguns "conselhos" - não faz sentido executar tais cálculos em cálculos remotos. Na realidade, não é nada óbvio no início.
 
Renat:

Para uma única execução (não em modo de optimização, apenas uma única passagem), é possível seleccionar um dos agentes locais ou um dos agentes remotos (trabalhando em modo servidor).

Para uma única execução, não se pode seleccionar um agente da MQL5 Cloud Network, porque não faz sentido prático e económico.

Grosso modo, não faz sentido inicializar um poderoso sistema distribuído de Rede MQL5 com levantamento de cache e preparação de dados para um único teste. O objectivo da MQL5 Cloud Network é realizar cálculos de optimização massiva.

Por isso acertei, um agente local/remoto + vários terminais
 
Academic:
A propósito, esse pensamento - pode ser em termos de "melhoria" para fazer esse tipo de "cálculo" preliminar, digamos, tendo analisado a velocidade de transferência (tempo de subida) de caches como sendo menos e os prós de mais núcleos e para comparar o tempo recebido apenas com o tempo de teste local para dar alguns "conselhos" - como se não fizesse sentido correr em caches remotos. Na realidade, não é nada óbvio no início.

Naturalmente, o gestor de testes tentará utilizar mais agentes locais, depois agentes remotos, e depois agentes distribuídos para reduzir o custo do cálculo.

Além disso, estamos a introduzir um mecanismo de processamento por lotes, que pode reduzir o impacto dos atrasos da rede quando se trabalha com agentes remotos para quase zero.

Ou seja, o terminal distribuirá tarefas em blocos de 32-64 execuções para cada agente, o que reduzirá o impacto dos atrasos da rede pelo mesmo número de vezes.

Exemplo: enviei um lote de 32 tarefas em 2KB com parâmetros a calcular, e recebi um pacote de resposta de 1KB com resultados de um agente 5 minutos mais tarde. O resultado final é 3kb de tráfego de rede com cerca de 1 segundo de perda de transmissão em vez de 32 segundos sem empacotamento.

 

Obrigado pelas respostas, mas muita coisa ainda não está clara.

Для одиночного прогона (не в режиме оптимизации, а именно одиночный проход) можно выбрать одного из локальных агентов или одного из удаленных (работающих в серверном режиме).

O que é que isso significa? "remoto, a funcionar em modo servidor"? Não compreendo - se eu instalar um agente num segundo computador usando o componente Metatester, é isto? E os remotos que não estão em modo servidor - como é que os adiciono?

Para uma única execução, não se pode seleccionar o agente da MQL5 Cloud Network, porque não faz sentido prático ou económico.

É aqui que precisamos de um supercomputador, ou melhor, de um cluster de supercomputadores a trabalhar como um único núcleo - como um único agente, e é necessária uma rede - ninguém tem um computador deste tipo em casa. Ou pelo menos a capacidade de se ligar a uma máquina potente (é possível, como eu entendo, se eu instalar o agente num computador potente, e utilizá-lo a partir de um portátil durante uma única execução). Exactamente para uma única corrida. De facto, acontece o contrário - não há sentido prático em utilizar a MQL5 Cloud Network para cálculos de optimização massiva, se mesmo a execução inicial é difícil. A enumeração de variantes é o segundo caso, mas a única série não é menos importante, e ainda mais importante para algumas pessoas.

Assim compreendo correctamente, um agente local/remoto + múltiplos terminais

Este não é de todo claro como decifrá-lo...

 

Renat:

Exemplo: enviou um pacote de tarefa de 32 execuções de 2kb com parâmetros para calcular e recebeu 5 minutos depois um pacote de resposta de 1kb com resultados do agente. O resultado é 3kb de tráfego de rede com cerca de 1 segundo de perda de transmissão em vez de 32 segundos sem pacote.

Isto é verdade se a história estiver preenchida e não houver despesas adicionais. Mas, em princípio, a redução do tráfego e a melhoria da eficiência da optimização estarão na sua cara.
 

Renat:

Grosso modo, não faz sentido inicializar um poderoso sistema distribuído MQL5 Network com elevação da cache e preparação de dados para um único teste. O objectivo da MQL5 Cloud Network é realizar cálculos de optimização massiva.

Concordo com isso. No entanto, é uma pena que não haja possibilidade de executar várias séries únicas (testes) em simultâneo, mesmo com vários núcleos numa única máquina. Para ser mais preciso, sequencialmente, é claro, mas sem esperar que as corridas anteriores sejam concluídas. Várias versões do terminal são muito caras em memória. Mas se o testador fosse um programa autónomo, com a capacidade de executar múltiplas instâncias, seria melhor. Idealmente - um testador multitarefa. Agora, temos de nos contorcer - escrever um ficheiro de configuração com listas de parâmetros e carregá-los a partir de um ficheiro, alimentando o optimizador com um contador de pseudo-variáveis. Não é conveniente. Para não mencionar o facto de que o conjunto completo de resultados de testes (transacções, em particular) nesta variante também tem de ser calculado, formatado e atirado para um ficheiro no deinit. Assim, o processamento em massa dos resultados da optimização é bastante complicado na versão actual do testador. Nem sequer é possível carregar os resultados dos testes de ontem de um ficheiro (que existe!) de volta para a página "resultados de optimização" para os resolver com um "testador de um clique" à mão. Pode pelo menos implementar tal possibilidade?

Outra questão dolorosa: compreendo que durante a optimização leva bastante tempo a preparar dados para agentes. É possível carregar agentes não com tarefas simples, mas com lotes (8-16-32)? Neste caso (imho) poderíamos obter um ganho tangível no tempo total de optimização. Tanto quanto sei, tal esquema é agora utilizado com sucesso no B4. Penso que vários conjuntos de parâmetros são executados em paralelo (posso estar enganado). Por isso, gostaria de ter algo semelhante no início. Caso contrário, o meu testador de um só núcleo fica muitas vezes atrás do de quatro núcleos (já escrevi uma vez sobre isso).

//Wow! demasiado tarde. Na altura em que escrevi, Renat já tinha escrito afirmativamente sobre o processamento em lote. Obrigado. Muito satisfeito. Vamos esperar.

 
-Alexey-:

Obrigado pelas respostas, mas ainda há muito por esclarecer.

O que significa: "remoto, a funcionar em modo servidor"? Só não compreendo - se instalar um agente num segundo computador usando o componente Metatester - é isto? E quanto ao modo remoto, sem servidor - como é que os adiciono?

É aqui que precisamos de um supercomputador, ou melhor, de um cluster de supercomputadores, trabalhando como um núcleo como um agente, e uma rede - ninguém tem um em casa. Ou pelo menos a capacidade de se ligar a uma máquina potente (é possível, como eu entendo, se eu instalar o agente num computador potente, e utilizá-lo a partir de um portátil durante uma única execução). Exactamente para uma única corrida. De facto, acontece o contrário - não há sentido prático em utilizar a MQL5 Cloud Network para cálculos de optimização massiva, se mesmo a execução inicial é difícil. Experimentar variantes é o segundo caso, mas uma única execução não é menos importante, e ainda mais importante para algumas pessoas.

Não está nada claro como decifrar isto...

1. Uma única execução utiliza apenas um núcleo, local (o seu PC) ou agente remoto (intranet).

2) Alguns núcleos podem ser desactivados.

3. é possível seleccionar um agente específico (um núcleo específico) sobre o qual se pode testar.

É teoricamente possível realizar vários "testes únicos" ao mesmo tempo (mas depois seriam necessários vários terminais).

PS

No seu caso com portátil deve desligar os kernels locais e fazer o teste num computador potente (que está na rede local ou quais os recursos que serão maximamente gratuitos para os testes).

 

MetaDriver:

É possível carregar agentes não através de tarefas simples, mas através de pacotes de tarefas (8-16-32)? Neste caso (imho) podemos obter um ganho tangível em tempo total de optimização. Tanto quanto sei, tal esquema é agora utilizado com sucesso em F4.


Assim, implementam o modo batch, Renat até deu um exemplo...
 

O que eu não entendo é....

  1. E quanto à história? Será o mesmo para todos? E se eu tiver descarregado um terminal de diferentes empresas de corretagem com muito pouco historial e, além disso, tiver buracos em locais diferentes?
  2. Se o número de instrumentos não for o mesmo, o exemplo no servidor é de 12 símbolos do campeonato. E para o teste (a moeda múltipla necessita de uma matriz monetária completa para que o indicador funcione correctamente), como neste caso ? ....
  3. E em terceiro lugar, já mencionámos o tempo, por isso introduzimos o tempo UTG - para sincronizar de alguma forma ... Como será consigo? Se, digamos, apenas determinadas horas de negociação forem testadas (por exemplo, de 10 a 12 em Moscovo) ... O tempo é diferente para todos ...
Razão: