Errori, bug, domande - pagina 2285
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
Sì, ma la nozione di "veloce" nel vostro caso è molto relativa. Una cosa è che un utente richieda una matrice di barre - è solo copiato un'area di memoria, o richiesto una specifica serie temporale, allora è 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. Anche se idealmente, sarebbe bello avere una tale opzione nel terminale, per scegliere il modo di memorizzare la storia nella memoria. Per esempio, se il sistema ha poca RAM, ma un processore veloce, sarebbe molto utile.
Beh, guarda. Ho appena misurato le velocità di scrittura e lettura sul mio SDD. Si è scoperto che il tempo di scrittura e lettura di 8 byte (1 tipo di valore doppio o datetime o lungo) ~ 48 ns. E secondo i miei calcoli il tempo di lettura di 8 byte di informazioni dall'array imballato è di 1-2 ns. Così, mentre perdiamo 1-2 ns sull'accesso a un elemento della struct, guadagniamo 48*0,8 = 38 ns per la scrittura e la lettura dal disco. Inoltre abbiamo un risparmio di RAM e di spazio su disco di 5 volte, e non parlo nemmeno dell'HDD.
Beh, guarda. Ho appena misurato la velocità di lettura e scrittura del mio SDD. Si è scoperto che il tempo di scrittura e lettura di 8 byte (1 tipo di valore doppio o datetime o lungo) ~ 48 ns. E secondo i miei calcoli il tempo di lettura di 8 byte di informazioni dall'array impacchettato è di 1-2 ns. Così, mentre perdiamo 1-2 ns sull'accesso a un elemento della struct, guadagniamo 48*0,8 = 38 ns per la scrittura e la lettura dal disco. Inoltre abbiamo un risparmio di memoria e spazio su disco di 5 volte, e non parlo nemmeno di HDD.
Non lo discuto. Quando si tratta specificamente di scaricare i dati dal disco, hai certamente ragione. 4 anni fa abbiamo avuto una discussione con Renat su questo argomento, al tempo in cui l'SSD era ancora piuttosto raro e la stragrande maggioranza degli utenti era seduta su HDD lenti.Così io (con il mio SSD) ho cercato di convincerlo che il funzionamento dell'HDD è l'anello più lento del sistema e che dovremmo cercare di ridurre al minimo il flusso di dati da esso, ma non viceversa, ma lui aveva argomenti del tipo: non c'è bisogno di sovraccaricare la CPU con lavoro extra, e voi tutti siete stupidi, non capite niente, ecc. In generale, tutto come al solito )
Vero, SSD significativamente accelerato in questi giorni.
Risulta che il tempo di scrittura e lettura è di 8 byte
Forum sul trading, sistemi di trading automatico e test di strategie di trading
Bug, bug, domande
fxsaber, 2018.09.10 21:28
In primo luogo, il registro dell'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 consultato con una frequenza enorme. 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ù di quello che usa il 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.
Quale cartella di Terminal via mklink a RAM-disk, in modo che i dati non vengano letti/scritti da SSD, ma dalla memoria? Sono disposto a fornire i dati, che tipo di accelerazione questo darebbe nell'ottimizzazione.
Sì, questo è un archivio. Se ho capito bene, ora i tick e le barre dei minuti sono memorizzati senza imballaggio, cioè per una barra(struttura MqlRates) sono 60 byte, e per un tick(struttura MqlTick) sono 52 byte.
È orribile! Qualcosa deve essere fatto molto tempo fa.
Capisco che il problema principale degli array compressi è l'organizzazione dell'accesso rapido ad ogni elemento dell'array.
Ma anche se immagazziniamo solo ogni 256° elemento di un array spacchettato e immagazziniamo negli altri elementi solo incrementi a quelli spacchettati, possiamo vedere che la dimensione dell'array sarà 4-5 volte più piccola e il tempo di accesso ad ogni elemento non aumenterà troppo (forse 1-2 nanosecondi), ma si risparmierà un tempo enorme sul salvataggio e la lettura dell'array da disco e su disco.
"Tutto è già stato rubato prima di te" (cz)
All'inizio della giornata è una spunta completa. Poi bid e/o ask e/o flipper full, tutto il resto in incrementi se disponibile. Una media di 10 byte per tick.
Dato che l'accesso ai tick è strettamente sequenziale, non c'è nessun problema ad organizzare l'accesso rapido ad ogni elemento dell'array
Una grande richiesta di pubblicare la fonte del record "Tester\cache\*.opt". Potete vedere dal contenuto che il formato è molto semplice.
Lavorare con i risultati dell'Ottimizzazione è molto necessario. Grazie!
Per qualche motivo la performance del tester cala all'aumentare del numero di scambi. Non c'è alcun riferimento alla storia del trading da parte dell'Expert Advisor.
Questo non sembra essere il caso.
Nel Tester, l'intervallo corrispondente alla modalità "Tutto lo storico" è memorizzato. Aggiungo la storia al simbolo personalizzato, ricarico il terminale e l'intervallo corrispondente a "Tutta la storia" rimane invariato.
Non posso cambiare la modalità predefinita, ma se seleziono l'intera cronologia, la imposto manualmente. Si prega di correggere.
Manca una croce nel posto segnato - cancellando la riga corrispondente della voce della cache.
Faccio molte ottimizzazioni. Alcuni sono obsoleti da molto tempo. E non c'è nessun meccanismo per cancellare queste opzioni. A volte si ottiene una lista enorme e si inizia a cercare tra le varianti inutili.
Pertanto, si prega di considerare la rimozione dei dati non necessari con una croce nel posto segnato nell'immagine.
Errore durante l'esecuzione
Risultato: vero:falso:7:4
Com'è possibile che stringhe di lunghezza diversa siano improvvisamente uguali? Mentre il confronto con StringCompare dà il risultato opposto ==
Grazie per il post, abbiamo cambiato il comportamento del confronto delle stringhe carattere per carattere.
In precedenza le stringhe venivano confrontate come stringhe Z (fino al carattere nullo), ora vengono confrontate come stringhe PASCAL (tenendo conto della lunghezza).
I codici esistenti con stringhe "normali" (senza carattere Z all'interno) non saranno interessati da questo cambiamento.