Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 19
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
Quindi avresti bisogno di passare attraverso diversi milioni di offerte di altre sequenze! Questo è esattamente il mio punto.
Beh, sto parlando di controllare un singolo numero (numero di sequenza), un milione non è molto per un'operazione così elementare. Se contiamo il criterio ricorsivamente, è solo un passaggio del file, e dovremo farlo comunque. Un'altra cosa da considerare è che la mappa di dati della ricorsione conterrà lo stesso diversi milioni di elementi (moltiplicato per il numero di parametri per una sequenza).
Un'altra alternativa è quella di ricalcolare completamente e memorizzare i criteri prima dell'ordinamento. Di nuovo, la possibilità di usare la ricorsione è fondamentale.
È chiaro che ci saranno molte operazioni, ma è meno nella versione originale?
In C++ si può fare senza un parser se:
spingendo l'idea 10 volte - iniziate un altro file con i valori delle posizioni iniziali delle sequenze in un altro file, poi non avete nemmeno bisogno di memorizzare il numero di scambi nella struttura della sequenza.
Otterrete un indice ordinario, che è già stato menzionato prima.
Ho implementato l'algoritmo che ho descritto sopra.
Elaborare i miei dati con X = 20 (calcolo di criterio su 20 affari) ha richiesto circa112 minuti (non l'ho preso esattamente), la parte del leone è stata mangiata dallo spostamento dell'array (40% secondo il profiler).
Dopo i loop degli array e qualche altra ottimizzazione l'elaborazione è diventata più veloce:
La memoria era sufficiente solo per 65 transazioni (moltiplicate per un milione di sequenze). Questo, ovviamente, non è abbastanza - contavo di arrivare almeno a 100.
Il passo successivo è stato quello di scartare tutte le informazioni non necessarie sugli scambi. Lasciando solo i tempi di apertura e chiusura, e il profitto in pip, è riuscito a decollare con X = 185.
Poi - basta accelerare il lavoro con il file, FileReadXXX ora richiede il 30% del tempo (e il dispatcher dice che non c'è lavoro con il disco, ma la CPU è carica).
FileRead è esattamente il primo dopo FileSeek, cioè la lettura sequenziale funziona velocemente.
Vi farò sapere i nuovi risultati.
In C++ è fatto da fread in 64K-128K buffer, analizzandolo meglio con il proprio parser, perché gli sscanf-es sono molto lenti.
Proverò a lavorare con i file attraverso WinAPI, mi è stato consigliato dal service-desk:
Sto spingendo l'idea 10 volte - per iniziare un altro file con i valori delle posizioni iniziali delle sequenze in un altro file, poi nella struttura della sequenza non sarà nemmeno necessario memorizzare il numero di accordi.
Non capisco cosa farà l'indice.
Scrivere il numero di scambi non fa differenza, la lettura sequenziale funziona rapidamente, il problema è proprio la lettura del blocco dopo lo spostamento nel file.
Per favore, scrivi un algoritmo suggerito.
Il problema non è banale, ma non c'è ancora una sola riga di codice. Andrey, molte persone qui sono interessate - formulare il problema e offrire dati di prova. Organizziamo una programmazione sportiva.
Abbiamo bisogno di dati di test + pseudocodice, con principi generali di lavoro con i dati.
Il compito è formulato dall'inizio alla fine.
E i dati del test possono essere generati con uno script leggermente modificato, che ho postato prima.
Lo farò un po' più tardi.
perché passare attraverso le opzioni dalla base? sarebbe meglio generare trade sulla storia secondo i criteri? no? non sarebbe lo stesso di quello che è richiesto?
Se per i test, ovviamente sì, ma se per risolvere il problema, ovviamente no )
Candido:
Beh, stiamo parlando di controllare un singolo numero (numero di sequenza), un milione non è molto per un'operazione così elementare. Se consideriamo il criterio ricorsivo, è solo un passaggio di file, dovremo farlo comunque. Un'altra cosa da considerare è che la mappa di dati della ricorsione conterrà lo stesso diversi milioni di elementi (moltiplicato per il numero di parametri per una sequenza).
Un'altra alternativa è quella di ricalcolare completamente e memorizzare i criteriprima dell'ordinamento. Di nuovo, la possibilità di usare la ricorsione è fondamentale.
È chiaro che ci saranno molte operazioni, ma ce ne sono meno nella versione originale?
Nella variante iniziale, è possibile calcolare il criterio una volta quando si trova l'ultima transazione dalla storia passata.
Ed è necessario leggere un frammento del file tale da contenere un numero X di accordi di tutte le sequenze. Sarà molto più grande di X *numero di sequenze, perché ci sono diverse quantità di accordi e potrebbero non essere distribuiti uniformemente.
2 tutti:
Comunque, grazie per il supporto.
Se non ti dispiace, esegui lo script di test e condividi i risultati.
E i dati del test possono essere generati con lo script leggermente modificato che ho postato prima.
Allego lo script aggiornato, ora non si limita a registrare trade identici, ma genera sequenze casuali con le impostazioni specificate(durata - da e verso, profitto - da e verso).
Per ottenere un file paragonabile al mio, esegui lo script con le impostazioni predefinite:
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 140.000 svalutazioni in 57,1 sec
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 6632 Mb caricati in 44.0 sec(150.7 MB/sec)
Dopo di che, si può elaborare l'algoritmo su di esso.
Per i più pigri, archiviate il file su google drive.
komposter:
1. Nella variante originale si può calcolare il criterio una volta sola quando si trova l'ultimo affare dalla storia passata.
Nella vostra variante, avete bisogno di leggere un tale pezzo di file, che conterrebbe X offerte di tutte le sequenze. Sarà molto più grande di X *numero di sequenze, poiché il numero di accordi è diverso e potrebbero non essere distribuiti uniformemente.
1 Questo non è molto chiaro, se stiamo cercando il criterio massimo (minimo), alla fine dobbiamo ancora calcolare il criterio per tutti i candidati. Non importa nemmeno se si cerca l'estremismo locale o globale.
2. Chiaramente più è la questione della dimensione accettabile o meno in termini di memoria richiesta. Inoltre, una dimensione di blocco più grande in termini di velocità di lettura del disco è ancora meglio. Certamente non è ancora un problema per la RAM. È di fondamentale importanza che la lettura sia fatta in modo sequenziale e solo una volta.
La variante del calcolo dei criteri prima dell'ordinamento, tuttavia, richiede una doppia lettura. Ma ha i suoi vantaggi, soprattutto considerando la possibilità di dividere i dati in diversi file più piccoli e la loro successiva elaborazione congiunta.
Senza implementazione, tuttavia, tutti gli argomenti rimarrebbero astratti. Quindi a questo punto della discussione dovrò solo prendere congedo :)
Come fare cuciture di file con indicizzazione di quale bit è l'inizio e la fine di quale file.
Per esempio, fare 1000 metafile su 1000 file, e se i criteri sono noti, fare un ordinamento statistico per inserire file simili in un metafile.
Meglio sperimentare con FileOpen, come funziona più velocemente per aprire un file grande o uno piccolo, nel senso di aprire 1000 volte un file grande di dimensioni uguali a 1000 piccoli o 1000000 volte per aprire uno piccolo?
Potrebbe risultare che i file non dovrebbero essere uniti, ma divisi.
Come fare cuciture di file con indicizzazione di quale bit è l'inizio e la fine di quale file.
Per esempio, fare 1000 metafile su 1000 file, e se i criteri sono noti, fare un ordinamento statistico per inserire file simili in un metafile.
Meglio sperimentare con FileOpen, come funziona più velocemente per aprire un file grande o uno piccolo, nel senso di aprire 1000 volte un file grande di dimensioni uguali a 1000 piccoli o 1000000 volte per aprire uno piccolo?
Può risultare che i file non devono essere uniti, ma divisi.
Attualmente sto lavorando con un file grande, ma volevo passare a un milione di file piccoli.
In primo luogo, possono essere aggiunti, e in secondo luogo, si può accedere ad essi per nome (non c'è bisogno di memorizzare "inizio di ogni sequenza").
Ho chiesto nel service-desk circa un milione di aperture di file diversi (ho la cache implementata in questo modo). La risposta è chiara e diretta.
Proverò le api-funzioni sia per un grande file che per milioni di piccoli file, pubblicherò i risultati.
Tuttavia, senza implementazione tutti gli argomenti rimarranno astratti. Quindi a questo punto della discussione sarebbe opportuno che mi ritirassi :)
Avrei dovuto iniziare con quello ;)
Ma in ogni caso, grazie per la tua partecipazione, anche le idee senza codice sono preziose.
Con un milione di file rovinerete ntfs in modo tale da farvi piangere da questa insana invenzione di microsoft, che ha bloccato tutti nella sua implementazione follemente ritardata del file system per sempre.
Tutto ciò che ms ha fatto nei suoi filesystem è un peso mostruoso, un ritardo e una stupidità. Diamine, questi idioti non hanno fatto alcuno sforzo per ottimizzare e velocizzare, e l'api è semplicemente primitiva. Nel 2014 questo può essere affermato in modo inequivocabile. Bene e piangere.
Chiunque voglia migliorare l'efficienza della gestione di un mucchio di file in windows, la prima cosa che fa è andare in chunks - raggruppare e la propria struttura di dati all'interno di un singolo file.
Una volta che si inizia a memorizzare più di un migliaio (molto meno decine o centinaia di migliaia) di file disparati in windows, si è fregati.
Le operazioni sui file in MQL4/5 passano attraverso i nostri meccanismi di caching molto efficienti, che ci permettono di raggiungere velocità di lettura e scrittura molto elevate ed efficienti.
Potete trasmettere i dati in streaming byte per byte - tutti saranno raccolti rapidamente nel buffer interno e scritti su disco solo in grandi blocchi. Il numero di chiamate WinAPI è minimo, il che dà un funzionamento ad alta velocità. La lettura è simile - lavora in modo proattivo, leggendo in grandi blocchi, chiamando molto raramente WinAPI e restituendo molto rapidamente i dati dalla sua cache con un overhead minimo.
Approssimativamente, rispetto alla build 509, abbiamo aumentato la velocità delle operazioni sui file in MQL4/5 di un ordine di grandezza (se intendiamo la regolare operazione basata su chunk, piuttosto che "scrivere per blocchi di megabyte per massimizzare le misure di velocità").