Errori, bug, domande - pagina 2284
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
I tick non sono memorizzati nella RAM. Vengono scaricati a seconda delle necessità, in modo frammentario, come ho capito.
Se per zecche vere e proprie, allora sì.
In un solo passaggio, è possibile visualizzare le statistiche su quanta memoria viene spesa per la memorizzazione dei tick. Durante l'ottimizzazione, non vengono memorizzati più di 320 meg alla volta. Il resto è memorizzato su disco.
Ora stiamo considerando una soluzione per mantenere tutti i tick nella memoria condivisa, in modo che tutti gli agenti locali possano leggere da questa memoria. Allora non ci saranno accessi al disco e l'ottimizzazione sarà più veloce.
Se per zecche vere e proprie, sì.
Potete vedere le statistiche su quanta memoria viene spesa per memorizzare i tick in un singolo passaggio. Quando è ottimizzato, non più di 320 meg sono immagazzinati in memoria alla volta. Tutto il resto è su disco.
Ora stiamo considerando una soluzione per mantenere tutti i tick in una memoria condivisa in modo che tutti gli agenti locali possano leggere da questa memoria. Allora non ci saranno accessi al disco e l'ottimizzazione sarà più veloce.
Sì, questo è un archivio. Se ho capito bene, ora i tick e le barre dei minuti sono memorizzati senza imballaggio sul disco e nella memoria, cioè per la barra(struttura MqlRates) sono 60 byte, e per il tick(struttura MqlTick) sono 52 byte.
È orribile! Bisogna fare qualcosa molto tempo fa.
Capisco che il problema principale degli array compressi è organizzare un accesso veloce ad ogni elemento dell'array.
Ma anche se teniamo spacchettato solo ogni 256° elemento dell'array, e memorizziamo negli altri elementi solo incrementi a quelli spacchettati, possiamo vedere che la dimensione dell'array sarà ridotta di 4-5 volte e il tempo di accesso ad ogni elemento non aumenterà molto (forse 1-2 nanosecondi), ma si risparmierà un tempo enorme sul salvataggio e la lettura dell'array da disco e su disco.
Perché l'SSD viene costantemente indirizzato (la luce sfarfalla ad un ritmo elevato) durante l'ottimizzazione?
Ecco perché non uso i tick, uso una struttura di dati logaritmica (ne ho già parlato), che in un dato momento consiste in un paio di migliaia di tick, poi un paio di migliaia di barre di minuti, 2000 M2, 2000 M5 , M10, M30, H1, H3, H6, H12, D1, W1... tutte le barre MN1.
Questa struttura di dati storici completi si forma in qualsiasi momento di tempo inferiore al millisecondo e occupa solo 1,5 MB in RAM (in realtà nemmeno in RAM, ma nella cache del processore). E tutti gli algoritmi, messi a terra per questa struttura, semplicemente volano.
Dopo tutto, la nostra vista è costruita sulla stessa scala logaritmica: più lontano guardiamo, meno notiamo i piccoli dettagli.
Quando in un futuro non troppo lontano, i computer avranno un solo dispositivo di memoria fisica (disco rigido, RAM, cache del processore), cioè la cache del processore con 13 zeri, allora farò anch'io il passaggio ai tick :))
...
Anche se forse sono io fuori strada, dato che con una tale struttura di dati durante l'ottimizzazione anche la lampadina sfarfalla. Dopo tutto, le zecche saranno ancora caricate :((
Se per zecche vere e proprie, sì.
Potete vedere le statistiche su quanta memoria viene spesa per memorizzare i tick in un singolo passaggio. Quando è ottimizzato, non più di 320 meg sono immagazzinati in memoria alla volta. Tutto il resto è su disco.
Ora stiamo considerando una soluzione per mantenere tutti i tick nella memoria condivisa, in modo che tutti gli agenti locali possano leggere da questa memoria. Allora non ci sarà nessun accesso al disco, e l'ottimizzazione sarà più veloce.
Per prima cosa, iniziamo con il registro di ottimizzazione
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'Durante quelle 7,5 ore, l'SSD è stato affrontato con enorme frequenza. Se le zecche sono state lette ad ogni passaggio, questo significa una media di 26 volte al secondo per 7,5 ore. Da qui un ammiccamento così selvaggio - più di 700 mila letture.
Registro delle corse singole
Come si vede, vengono utilizzati ~130K ticks e 60K barre (la modalità "Tutta la storia" è selezionata nel Tester). Cioè una quantità molto piccola di storia.
La storia del simbolo personalizzato nel Terminale contiene la seguente quantità di dati storici
Cioè nella storia del simbolo è molto poco più che usato dal Tester.
ZS È un peccato guardare l'SSD... Quanto più veloce potrebbe essere l'Optimise? Strano che il sistema operativo non metta in cache questi dati, dato che sono meno di 7MB di tick in forma non compressa.
Ma anche se immagazziniamo solo ogni 256° elemento di un array spacchettato e memorizziamo solo gli incrementi agli elementi spacchettati, la dimensione di un array si ridurrà di 4-5 volte mentre il tempo di accesso ad ogni elemento non aumenterà molto (forse di 1-2 nanosecondi), ma si risparmierà un tempo enorme sul salvataggio e la lettura di un array dal disco e sul disco.
Renate non è abbastanza per te ) Quante volte è stato suggerito di ottimizzare l'archiviazione della storia. Soprattutto perché non c'è bisogno di spendere nulla per la compressione (che è la parte più dispendiosa in termini di risorse), perché i dati inizialmente arrivano dal server compressi, e solo la cache, che viene usata costantemente, viene mantenuta non compressa... Ma è qui che arriva sempre la predica: se non puoi comprare un hard disk più grande o più veloce, non c'è niente da fare su un MT. E i VPS lenti sono sempre menzionati per qualche motivo.
Renate non è abbastanza per te ) Quante volte è stato suggerito di ottimizzare l'archiviazione della storia. Soprattutto perché non c'è bisogno di spendere nulla per la compressione (che è la parte più dispendiosa in termini di risorse), perché i dati vengono originariamente dal server compressi, e solo la cache, che è costantemente utilizzata, è mantenuta in forma non compressa... Ma è qui che arriva sempre la predica: se non puoi comprare un hard disk più grande o più veloce, non c'è niente da fare su un MT. E i VPS lenti sono sempre menzionati per qualche motivo.
Ancora una volta, il problema principale con gli array impacchettati è organizzare l'accesso rapido a qualsiasi elemento dell'array, piuttosto che leggerli in modo sequenziale. Ecco perché qui è necessario un diverso formato di compressione (o piuttosto anche di memorizzazione), sì tale da non dover essere scompattato e impacchettato. Naturalmente, una compressione di ~10 volte come per zip, png, ecc. non funzionerà, ma penso che una compressione di 5 volte sia possibile.
Beh, in realtà, se ci pensiamo, in MqlRates 8*4=32 byte sono allocati per memorizzare le informazioni sulle barre da un minuto (mentre solo le barre da un minuto sono memorizzate), anche se nel 99% dei casi questi valori differiscono di meno di un byte di informazioni, cioè 8+1+1+1=11 byte sono quasi sufficienti, anche se non legati alle barre precedenti. E il tempo nel 99% dei casi differisce dal valore precedente esattamente di 60 (cioè nel 99% dei casi basta 1 bit di informazione - 60 o non 60). E 8 byte sono allocati anche per questo.
Ancora una volta, il problema principale con gli array impacchettati è organizzare l'accesso rapido a qualsiasi elemento dell'array, piuttosto che leggerli in modo sequenziale. Ecco perché qui è necessario un diverso formato di compressione (o piuttosto anche di memorizzazione), sì tale da non dover essere scompattato e impacchettato. Naturalmente, zip, png, ecc. non possono essere compressi ~10 volte, ma penso che 5 volte sia possibile.
Se stiamo parlando di memorizzazione su disco, l'accesso a un elemento specifico non ha senso, perché l'operazione di file in sé è costosa. Quindi un grosso pezzo viene letto in una volta sola. Per esempio i file della cronologia dei bar sono suddivisi per anno, i tick per mese. E se intendete mantenere la storia in memoria in una forma impacchettata, spacchettando costantemente ogni elemento al volo, allora temo che non sarà adatto a nessuno.
Ho appena inventato un formato di memorizzazione che memorizza blocchi di 256 elementi MqlRates e prende 2900 byte in media (la dimensione del blocco sarà fluttuante), cioè 2900/256= ~12 byte saranno allocati per struttura MqlRates, che è 5 volte meno, come pensavo.
L'accesso ad ogni elemento della struttura MqlRates confezionata è abbastanza veloce (2-3 somme, 2-3 controlli, 2-3 spostamenti, cioè difficilmente più di 1 nanosecondo)
Se stiamo parlando di memorizzare su disco, l'accesso a un elemento particolare non ha senso, perché l'operazione stessa del file è costosa. Quindi un grosso pezzo viene letto in una volta sola. Per esempio, i file della cronologia delle barre sono divisi per anni, i tick sono divisi per mesi. E se intendete mantenere la storia in memoria in una forma impacchettata, spacchettando costantemente ogni elemento al volo, allora temo che non sarà adatto a nessuno.
Sarà memorizzato su disco in un formato "compresso" e anche letto in memoria nello stesso formato. Non ci sarà nessuna conversione in un formato completo, ma ci sarà solo un calcolo al momento della lettura di un elemento specifico della struttura MqlRates. E sarà molto più veloce, tenendo conto del fatto che ci sarà cinque volte meno lavoro con il disco.
L'accesso ad ogni elemento di una struttura MqlRates confezionata è abbastanza veloce
...
Sarà memorizzato sul disco in un formato "compresso" e letto nella memoria nello stesso formato. Non ci sarebbe alcuna conversione in un formato completo, ma solo i calcoli risultanti al momento della lettura di un particolare elemento della struttura MqlRates.
Sì, ma il concetto di "veloce" nel tuo caso è molto relativo. Una cosa è che l'utente ha richiesto un array di barre, ha semplicemente copiato una sezione di memoria, o richiesto qualche serie temporale specifica, è anche una semplice copia di dati con passo costante, pari alla dimensione della struttura. E un'altra cosa sono i calcoli e le conversioni supplementari su ogni numero.
Anche se, personalmente, preferirei avere una cronologia compressa, per non sprecare memoria, perché comunque sto organizzando i miei array per memorizzarla. Quindi sono disposto a tollerare un piccolo ritardo. Ma la maggior parte degli altri utenti ti farebbe a pezzi per questo)
p.s. Idealmente, però, sarebbe bello avere un'opzione simile nel terminale per scegliere come la storia viene memorizzata. Per esempio, se il sistema ha poca RAM, ma un processore veloce, questo sarebbe molto utile.