Ottimizzazione nel tester di strategia - pagina 16

Nuovo commento
 
Renat:

Nelle ultime build, ci siamo sbarazzati completamente degli overhead di sistema sui task, riducendoli da quasi 2000 ms a zero.

Ecco i risultati dell'esecuzione di un compito di calcolo, che è stato suggerito da joo:

Impostazioni (le date sono impostate di proposito in modo che la storia del grafico non venga utilizzata):

Parametri da eseguire:

Agenti utilizzati (4 agenti locali):

Risultati dell'ottimizzazione:

L'ottimizzazione ha richiesto solo 25 secondi e sono stati fatti 18.432 passaggi:

Tornando al vecchio compito di ottimizzazione del tester di strategie di trading.

I miglioramenti al piano generale per la costruzione 425 hanno portato a:

  • riduzione dell'overhead del sistema in preparazione dei passaggi
  • l'aggiunta di una modalità esplicita "calcoli matematici" alla selezione del tipo di simulazione che ha semplificato il setup

Sempre con lo stesso hardware (4 agenti locali) e cache pulita nella build 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

Rispetto alproblema originale sollevato(l'overhead era di 2 sec per passaggio), abbiamo risolto con successo il problema. Lo stesso compito ha iniziato a contare in 7 secondi invece di 25 secondi.

La base della lotta contro i sovraccarichi del sistema era quella di raggruppare i compiti. Ora ogni agente ha la sua velocità di esecuzione misurata, e un batch di 1-64 compiti ci è stato dato per il calcolo. Di conseguenza, il tempo necessario per preparare i test e ottenere i risultati è proporzionalmente ridotto. Gli agenti veloci ottengono più compiti e batch più grandi di quelli lenti. Questo è particolarmente vantaggioso per compiti di calcolo veloci, dove il tempo di calcolo utile è paragonabile al tempo di preparazione del test e di inoltro dei risultati.

Il lavoro di ottimizzazione della manutenzione degli agenti non è ancora completato. Per il lavoro efficiente degli agenti remoti nella rete Cloud MQL5, la riduzione dei costi di comunicazione è la questione principale.

 

Aiuta a capire!

I seguenti blocchi di codice funzionano bene nel terminale su un conto demo, ma quando vengono testati danno un messaggio dierrore 4109.

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

La stessa situazione si verifica con

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

Aiuta a capire!

I seguenti blocchi di codice funzionano bene nel terminale su un conto demo, ma quando vengono testati danno un messaggio dierrore 4109.

La stessa situazione si verifica con

I grafici e gli oggetti grafici non sono modellati durante i test perché riduce drasticamente la velocità di test.
 
Renat:
I grafici e gli oggetti grafici non vengono modellati durante i test, poiché questo riduce catastroficamente la velocità dei test.
Capisco, grazie. C'è un modo per uscire da questa situazione?
 
Renat:
I grafici e gli oggetti grafici non vengono modellati durante i test, poiché questo riduce catastroficamente la velocità dei test.
Spero davvero che questo tipo di simulazione senza grafica sia solo in modalità senza "visualizzazione".
 
sergeev:
Spero davvero che questo tipo di modellazione senza grafica sia solo in una modalità senza "visualizzazione".
Completamente solidale, la grafica è a volte molto necessaria...
 
Renat:

Tornando al vecchio compito di ottimizzare il tester delle strategie di trading.

I miglioramenti al piano generale per la build 425 hanno portato a:

  • riduzione dell'overhead del sistema in preparazione dei passaggi
  • aggiunta della modalità esplicita "calcoli matematici" nella selezione del tipo di simulazione, che ha semplificato il setup

Un altro risultato sullo stesso hardware (4 agenti locali) e cache pulita in 425 build:

Rispetto alproblema originale sollevato(l'overhead era di 2 sec per passaggio), abbiamo risolto con successo il problema. Lo stesso compito ha iniziato a contare in 7 secondi invece di 25 secondi.

La base della lotta contro i sovraccarichi del sistema era quella di raggruppare i compiti. Ora ogni agente ha la sua velocità di esecuzione misurata, e un batch di 1-64 compiti ci è stato dato per il calcolo. Di conseguenza, il tempo necessario per preparare i test e ottenere i risultati è proporzionalmente ridotto. Gli agenti veloci ottengono più compiti e batch più grandi di quelli lenti. L'effetto è particolarmente grande per compiti di calcolo veloci, dove il tempo dei calcoli utili è paragonabile al tempo di preparazione del test e di invio dei risultati.

Il lavoro per ottimizzare la manutenzione degli agenti non è ancora finito. Per il lavoro efficiente degli agenti remoti nella rete Cloud MQL5, la riduzione del costo di fornire la comunicazione è il problema principale.

Un cambiamento molto serio per il meglio - grazie.

E il limite di 64 parametri? È l'unico fattore, almeno per me, che limita l'uso completo dell'ottimizzatore. Voglio già dimenticare tutti i problemi e scrivere per il mondo "reale", in modo che il tester possa essere ottimizzato senza alcun cambiamento nel codice.

 
Ci occuperemo dei parametri dopo aver eseguito il visualizzatore di test.
 
joo:

Un cambiamento molto serio per migliorare - grazie.

E il limite dei 64 parametri? È l'unico fattore, almeno per me, che limita l'uso su larga scala dell'ottimizzatore. E come voglio dimenticare tutto quel casino e scrivere subito per il "mondo reale" in modo da poterlo ottimizzare nel tester senza alcun cambiamento nel codice.

Io ti sostengo.
Renat:
Ci occuperemo dei parametri dopo l'avvio del visualizzatore di test.
Grazie, aspetteremo.
 
Renat:

Tornando al vecchio problema dell'ottimizzazione del tester delle strategie di trading.

Prossimi risultati sullo stesso hardware (4 agenti locali) e cache pulita in 425 build:

Rispetto alproblema originale sollevato(l'overhead era di 2 secondi per passaggio), abbiamo risolto con successo il problema. Lo stesso problema è ora di 7 secondi invece di 25 secondi.

Nella prossima build che verrà rilasciata abbiamo fatto molto lavoro per ottimizzare il calcolo della massa dei problemi matematici. Le spese generali del sistema sono state ridotte a zero.

Ora lo stesso problema con lo stesso hardware (Intel Q9400, 4 core locali) per ~18 000 calcoli richiede 1 secondo (l'ultima volta era 7 secondi, mentre prima ci volevano 25 secondi):

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


Per confronto posso mostrare quanto tempo sullo stesso hardware lo stesso compito matematico spende per calcolare 4 milioni di passaggi (riducendo il passo a 0,005 il numero totale di calcoli è diventato 4 milioni, il che permette di eseguire un calcolo 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


In 46 secondi avviene l'intero errore di calcolo di 4 milioni di compiti, la finestra dei risultati dell'ottimizzazione mostra tutte le 4 milioni di righe con i risultati, l'intera tabella è istantaneamente ordinata su qualsiasi campo, il grafico di ottimizzazione sta rendendo alacremente tutti i 4 milioni di valori, il grafico 3D sta disegnando una superficie 3D dagli stessi risultati e la sta facendo girare in diverse angolazioni:

1...910111213141516171819
Nuovo commento