Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 15
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
Finalmente ho capito cosa è necessario, speriamo che questa versione sia definitiva.
Come detto Tutto è abbastanza semplice da scomporre e parallelizzare, i passi principali:
1. a. Sarebbe molto utile sapere dove sono l'inizio e la fine di ogni sequenza (per questo ho suggerito la volta scorsa di scrivere le loro dimensioni in un file separato)
б. Potete analizzarli voi stessi, ma in questo caso dovrete tornare indietro quando leggerete la prossima parte di file dal disco per leggere la precedente sequenza tagliata
Poi considererò la variante 1.a. Probabilmente non è ottimale, ma mi piace di più.
2. Conoscendo le dimensioni delle sequenze e la dimensione della memoria per una parte del file (500 mb), possiamo calcolare la dimensione della parte del file che dobbiamo scaricare.
3. In parallelo, calcoliamo i coefficienti per le sequenze, poiché conosciamo l'inizio e la fine di ogni sequenza.
4. L'inizio e la fine di ogni sequenza possono essere memorizzati nella coda multithreaded (riempita durante il calcolo del passo 2)
5. Risultato del calcolo - struttura (array da struttura dove tempo e coefficiente + numero di sequenza))
6. Quando la metà della dimensione iniziale della memoria allocata (250 mb) è elaborata, il processo di riscrittura è iniziato con la formazione della seconda coda con l'inizio e la fine
7. Arrivati alla fine della prima riga si legge dalla seconda; arrivati alla fine della seconda riga si legge dalla prima.
8. È possibile calcolare simultaneamente i coefficienti e leggere dal file.
9. Ma ogni risultato del calcolo dei coefficienti deve essere memorizzato, ed è meglio unirli subito nella risposta:
dobbiamo scrivere funzioni di fusione: due sequenze di coefficienti in un sotto risultato, due sotto risultati in un sotto risultato leggermente completo
10. Il processo di fusione può anche essere fatto in parallelo.
11. Quando è il risultato? Quando le dimensioni delle sequenze lette dal file add-on sono finite, allora due pile diventeranno vuote, quindi il calcolo dei coefficienti sarà finito,
poi dobbiamo aspettare che il processo di fusione dei sotto-risultati finisca (può anche essere fatto tramite una coda thread-safe)
e infine unire i sotto-risultati dei diversi thread - risultato.
Ecco una variante con il carico massimo di tutti i possibili, forse qualcosa di meglio - sarò contento.
Ho bisogno di funzioni:
formare una sequenza di coefficienti da una sequenza di input
fusione di due sequenze di coefficienti in un unico sotto risultato (possibile perdita di precisione qui)
fusione di due sotto-risultati in un sotto-risultato leggermente completo (c'è una possibile perdita di precisione)
Penso che sia possibile inventare un meccanismo intelligente di caricamento parziale, ma bisogna inventarlo.
Per esempio, alla prima lettura, trova per ogni passaggio l'ultimo trade chiuso prima della Start Date, torna indietro e leggi X trade precedenti, ricorda il punto del file dove finisce quel trade.
Dopo di che, trovate il primo affare nei risultati, e poi lavorate solo con dati freschi: leggete il file dal punto desiderato alla nuova data attuale, e ogni volta spostate gli affari nell'array (ottenete un array di dimensioni fisse - X elementi).
Questo risolverà il problema delle letture multiple (non ne abbiamo bisogno) e della memoria (solo se possiamo piazzare X milioni di transazioni).
Sì, è quello che farà l'algoritmo.
Se riusciamo ad allocare memoria per X milioni di scambi(la dimensione della struttura è nota in anticipo), allora saremo in grado di leggere il file una volta.
Se no, allora dobbiamo aggiungere al puntatore Stored la lettura degli ultimi X deals ad ogni ritorno. Allora il file sarà letto più volte ma ancora economicamente.
La struttura della sequenza sarà fissa: Nos, Trades[X], Criterio, posizione FilePointer. Non c'è nulla di inutile.
Ho ancora bisogno di codificare =)
Qual è il risultato più desiderabile:
dll o ancora mql per calcolare?
Sì, in questa forma il compito è parallelo - ogni volta chela SeekDate cambia,puoi eseguire una ricerca simultanea del miglior criterio su diverse parti del set di sequenze. Per esempio, li dividiamo in 20 parti e diamo il compito a 20 Expert Advisors. E dovrebbero leggere il file, trovare l'accordo, e mandare indietro solo la sequenza migliore (№№, Criterio e posizione del file).
Grazie a tutti voi!
Qual è il risultato più desiderabile:
dll o ancora mql per calcolare?
Non sono con mql da mezzo anno, potrei essere un po' tonto, chiaritevi se mi sbaglio:
Открываем файл, начинаем читать, последовательно заполняя массив сделок первого прохода
avete intenzione di fare una lettura separata dal disco per ogni passaggio? 10^6 volte letto dal disco?
Non ci può essere un intoppo nel leggere individualmente invece di leggere un intero pezzo in una volta? O qui è tutto implementato al massimo livello con un solido buffering per risparmiare?
Se raggiungiamo un trade il cui orario di apertura è >= SeekDate (non viene aggiunto all'array):
Non vedo dove la memoria viene liberata, continua ad accumularsi.
Perché tenere l'intera matrice per un Criterio? Potete semplicemente confrontarli quando calcolate un nuovo criterio e mantenere quello appropriato.
Se volete trovare 10 criteri migliori, è meglio fare un array di 10 criteri, poi riempirlo di valori, ordinarli e inserire i criteri successivi usando la ricerca binaria.
Avete intenzione di eseguire una lettura separata dal disco per ogni passaggio? Leggere 10^6 volte dal disco?
Dovremo comunque leggere l'intero file. Non possiamo farlo tutto in una volta (dall'inizio alla fine), quindi dovremo leggere a pezzi (ma alla fine avremo comunque tutto il file).
Non può esserci un intoppo nel leggere un pezzo alla volta invece di leggere tutto il pezzo in una volta? O qui è tutto implementato al massimo livello con un solido buffering per risparmiare?
Viene letto un chunk. La dimensione del chunk è determinata dal numero di transazioni prima della Seeking Date, che erano in una particolare sequenza.
Non vedo dove la memoria viene liberata, continua ad accumularsi.
La memoria è allocata una volta per un array di strutture di sequenza.
La struttura della sequenza comprende: No., Array di strutture di tutte le transazioni della sequenza [X], Valore del criterio, Posizione del puntatore del file.
Il passo successivo è solo il riempimento degli elementi della struttura (compresi gli array di accordi). Le offerte nell'array sono spostate, quindi ci sono sempre solo X offerte di ogni sequenza in memoria.
Se volete trovare 10 criteri migliori, è meglio creare un array di 10 criteri, riempirlo di valori, ordinarlo e poi inserire il criterio successivo usando la ricerca binaria.
Anche per il parallelismo.
Ma l'eliminazione di un doppio da una struttura che contiene un array di strutture di deal non fa la differenza nel quadro del compito.
Condividere i risultati della mia ricerca.
File binario di cache di 7529 MB letto:
Conclusione: l'accelerazione sulla lettura di un grande file utilizzando il disco RAM è di circa 2,5 volte.
Se il file fosse ordinato per tempo di accordi non all'interno delle sequenze, ma globalmente (per tutte le sequenze), allora il seguente algoritmo sarebbe possibile:
- Calcolare il criterio per un trade, considerarlo un candidato
- Calcoliamo i criteri per gli affari che iniziano all'interno di questo affare, se otteniamo il migliore, cambiamo il candidato, se non lo otteniamo, consideriamo il candidato selezionato e iniziamo un nuovo ciclo dalla data della sua chiusura.
Possiamo anche ordinare per tempo di chiusura - in questo caso partiamo dalla fine
È chiaro che per il calcolo di un criterio, il file deve contenere il numero di sequenza per ogni scambio.
Anche il riordinamento di un tale file non è probabilmente una cosa divertente, possiamo provare a scriverlo "correttamente" in una volta sola. Questo non significa generare intere sequenze una per una, ma generare una transazione per ogni sequenza e usare una cache con intelligenza quando si scrive. Per alcuni algoritmi di generazione, naturalmente, questo può essere inaccettabile.
Se il file fosse ordinato per tempo di accordi non all'interno delle sequenze, ma globalmente (per tutte le sequenze), allora un tale algoritmo sarebbe possibile:
- Calcolare il criterio per l'affare, considerarlo un candidato
Supponiamo che io registri un tale file (convertendo solo quello attuale, anche se ci vogliono 15 ore di tempo al computer).
Ma poi - sul primo punto - c'è un intoppo. Come posso calcolare il Criterio sugli ultimi X trade della sequenza, avendo un tale file?
Di nuovo, il criterio non può essere calcolato una volta sola, i suoi parametri possono cambiare.