Errori, bug, domande - pagina 2284

 
Nikolai Semko:

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.

 
Slava:

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.

 
fxsaber:
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 :((

 
Slava:

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

Core 1  FILTER_EURUSD.rann_RannForex,M1: 132843 ticks, 60283 bars generated. Environment synchronized in 0:00:00.140. Test passed in 0:00:00.827 (including ticks preprocessing 0:00:00.109).
Core 1  FILTER_EURUSD.rann_RannForex,M1: total time from login to stop testing 0:00:00.967 (including 0:00:00.140 for history data synchronization)
Core 1  322 Mb memory used including 36 Mb of history data, 64 Mb of tick data

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

Saved ticks = 133331
Generated Rates = 60609

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.

 
Nikolai Semko:

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.

 
Alexey Navoykov:

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.

 
Nikolai Semko:

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)

 
Alexey Navoykov:

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.

 
Nikolai Semko:

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.