Domanda per gli sviluppatori - usare tutti i core di calcolo durante l'ottimizzazione - pagina 8
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Approccio interessante.
Ci potrebbero essere diverse soluzioni a questo problema, a seconda delle specifiche.
Se tutti i parametri, quelli che già esistono e quelli che possono apparire, hanno un posto strettamente definito nell'insieme dei parametri (cromosoma o altro equivalente), allora non c'è nessun problema.
Se un posto preciso di ogni parametro non può essere definito in anticipo, allora è necessario dividere i parametri in tipi che possono essere combinati strettamente solo tra loro (allora non importa dove si trova un parametro) - è necessaria la modifica di AO.
Ci sono altri modi per risolvere il problema, ma in ogni caso avrete bisogno di un AO personalizzato, una sovrastruttura sopra quella standard.
confermato il sovraccarico di memoria .... Anche se è strano, nessuno ha cancellato lo swap, ancora una volta, penso che gli sviluppatori debbano tenerne conto
Dovresti farci sapere come viene risolto il problema. Siamo preoccupati per te, vero?
Di quanta memoria minima avete bisogno per ogni agente (avete ridotto il numero di agenti attivati fino a quando tutti sono caricati in modo uniforme?)
Aumentato il pagefile? La memoria fisica sarà costantemente scambiata, potrebbe rallentare molto, è necessario trovare un numero di core dove il tempo totale di ottimizzazione è minimo.
Dovresti farci sapere come viene risolto il problema. Siamo preoccupati per te, vero?
Di quanta memoria minima avete bisogno per ogni agente (avete ridotto il numero di agenti attivati fino a quando tutti sono caricati in modo uniforme?)
Aumentato il pagefile? La memoria fisica sarà costantemente scambiata, ci potrebbero essere gravi rallentamenti, abbiamo bisogno di trovare un numero di core dove il tempo totale di ottimizzazione è minimo.
Tutto dipende dall'uso del tick, dalla profondità della storia, dal numero di strumenti. Basta guardare il task manager, si vedrà tutto lì, la quantità di tutta la RAM meno 1-2 GB per il sistema operativo diviso per la quantità utilizzata da un agente. È diverso per ognuno.
Un vero miglioramento può essere fatto dagli sviluppatori se un'area della RAM viene utilizzata per le quotazioni e possibilmente per gli indicatori.Tutto dipende dall'uso della zecca, dalla profondità della storia, dal numero di strumenti. Basta guardare il task manager, si può vedere la dimensione totale della RAM meno 1-2 GB per il sistema operativo diviso per la dimensione utilizzata da un agente. È diverso per ognuno.
Gli sviluppatori possono davvero migliorare la situazione, se un'area della RAM viene utilizzata per le quotazioni e, forse, per gli indicatori.Me lo stai spiegando? Stavo spiegando il problema a un uomo, e ora mi interessa il risultato. Non c'è feedback.
E abbiamo già discusso molte volte l'uso inefficiente della memoria da parte del terminale, e MQ più volte ha promesso di cambiare la situazione con la storia dei tick e i file temporanei duplicati per ogni agente, e la loro lunga creazione prima di ogni ottimizzazione dei tick. Personalmente ho dovuto disattivare quasi la metà degli agenti e delle ottimizzazioni dei tick per un certo numero di anni. Ho 8GB e 8 agenti. Ma per ora usiamo quello che abbiamo, e possiamo aumentare la dimensione della memoria o disabilitare gli agenti.
Me lo stai spiegando? Ho spiegato il problema all'uomo e ora mi chiedo quale sarà il risultato. Non c'è feedback.
E l'uso inefficiente della memoria da parte del terminale abbiamo già discusso molte volte, e MQ più volte ha promesso di cambiare la situazione con la duplicazione della storia dei tick e dei file temporanei per ogni agente, e la loro lunga creazione prima di ogni ottimizzazione dei tick. Personalmente ho dovuto disattivare quasi la metà degli agenti e delle ottimizzazioni di tick per diversi anni. Ho 8GB e 8 agenti. Ma per ora usiamo quello che abbiamo, e possiamo aumentare la dimensione della memoria o disabilitare gli agenti.
>Dovete solo farci sapere come si risolve il problema. Siamo preoccupati per te.
>Ho spiegato il problema all'uomo e ora sono interessato al risultato. Nessun feedback.
Mi dispiace, stavo lavorando, non avevo tempo.
Ho ottimizzato l'EA. Ho rimosso alcune parti "poco importanti" per far funzionare l'ottimizzatore (in particolare, tutto ciò che riguarda OpenCL e SQLite). Ora non ho overflow di memoria. MA ... non è una soluzione, naturalmente.
Su un altro computer ho dovuto disabilitare alcuni dei core solo per evitare il congelamento... Così, per esempio, il sistema su un 3950X (16 core/32 thread) e 32 GB, quando si usano tutti i thread - si è appena bloccato e tutto il resto. Inoltre, si blocca sugli agenti e si blocca finché non si uccide manualmente il processo attraverso il task manager .... Ho disattivato alcuni core, il calcolo è andato avanti. Penso che gli sviluppatori dovrebbero fare qualcosa per rendere esplicito il problema. Se l'ottimizzatore ha bisogno di più di dieci giga di memoria per il calcolo, dovrebbe essere chiaramente scritto in qualcosa come un avviso. Vi ricorderò ancora una volta dello swap però. Ho Xmeters installato ... Così posso vedere il carico di memoria visivamente proprio sulla barra delle applicazioni.
Penso che ci sia qualche altro glitch legato specificamente alla CPU amdc e non c'era prima - anche se l'EA era lo stesso. I sintomi sono i seguenti - solo 5 core .... e l'errore di calcolo si blocca... E non è esattamente la memoria, cioè lo stesso Expert Advisor forza 16 thread senza problemi, e il problema è il floating, ogni tanto non lo è. Se eseguo il test non nell'ottimizzatore, funziona bene. L'ho notato più di una volta. Quindi devo controllare.
Per quanto riguarda i freni degli agenti di rete, non riesco ancora ad arrivarci. Il concetto "un nucleo - un lavoro" è al di là della comprensione degli sviluppatori. Come prima, 10 core riceveranno 30 lavori ciascuno e altri 30 agenti di rete saranno inattivi. Ci vuole molto tempo per distribuire i compiti pensando a qualcosa. Quindi, tutto sommato, c'è molto ritardo.
E sì, dimenticavo: grazie mille a tutti per la vostra partecipazione, aiuto e consigli.aRenat Fatkhullin
Tuttavia, voglio sollevare l'argomento ancora una volta e fare una domanda specificaa Renat Fatkhullin
1. Sto ottimizzando una fattoria locale che consiste in diversi server con prestazioni molto diverse e ho visto alcuni ritardi davvero terribili durante l'ottimizzazione causati da CPU con prestazioni diverse. Supponiamo che ci siano server con CPU Xeon E5-2620 v2 (2,1 GHz), Xeon E5-2620 0 (2,00 GHz), i7-3820 (3,6 GHz), Xeon E3-1245 (3,7 GHz), Ryzen 7 2700, Ryzen 9 3900X, Ryzen 9 3950X. L'algoritmo attuale funziona così: forma uno stack di lavori, lo divide equamente per ogni core disponibile. A causa delle CPU Xeon E5-2620 0 (2.00GHz) e Xeon E5-2620 v2 (2.1GHz) a bassa velocità, la fattoria era inattiva e contava i compiti, ma queste due CPU non ne contavano nemmeno la metà. Così l'intera fattoria rimane inattiva. Succede e continuerà a succedere perché le CPU hanno velocità diverse e finché i lavori sono distribuiti in pacchetti. L'esperienza mostra che la latenza della rete non ha alcuna importanza ed è trascurabile. È già possibile rielaborare l'algoritmo di distribuzione dei lavori: non distribuire più lavori ad ogni core disponibile, ma"dare ad ogni core liberato un lavoro dallo stack della generazione corrente"?
2. È possibile aggiungere il salvataggio dei risultati dei test nel file xml ogni 10 minuti .... ed eseguire dall'ultimo salvataggio?
Ci siamo impegnati in una riscrittura completa del tester e dell'ottimizzatore.
Noi revisioneremo drasticamente e sistemeremo i problemi accumulati.
Ci siamo impegnati in una riscrittura completa del tester e dell'ottimizzatore.
Noi revisioneremo drasticamente e sistemeremo i problemi accumulati.
Ci sarà:
1. Reazione più veloce all'abbandono dell'agente, dove, per esempio, se non c'è ritiro dell'agente, la consegna dei pacchetti viene interrotta per minuti e i pacchetti vengono ridistribuiti.
2. Sarà possibile caricare in un'istanza i dati di tutti gli agenti su una macchina remota?
3. sarà il problema del trasferimento di grandi quantità di dati, quando la connessione con un agente è interrotta, non avendo scaricato tutti i dati (file) necessari per l'ottimizzazione?
C'è un'altra cosa che mi dà fastidio ....
diciamo che l 'ottimizzazione è in corso e in quel momento il metatrader dell'agente è aggiornato .... l'agente ha un lavoro (o meglio un gruppo di lavori), sarà perso o ricalcolato?