Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 16

 
komposter: Come calcolare il criterio per le ultime X offerte della sequenza, avendo un tale file?


Abbiamo un frammento del file nella nostra memoria, lo esaminiamo e formiamo un campione della lunghezza necessaria per il calcolo del criterio, selezionando solo le offerte che appartengono alla stessa sequenza. Poi calcoliamo il criterio su questo campione. A proposito, ci sono possibilità di usare la ricorsione quando si seleziona, per idea.

O non ho capito la domanda?

P.S. Naturalmente, dobbiamo andare all'indietro nel file quando formiamo il campione.

 
Candid:

Abbiamo un frammento del file nella nostra memoria, lo attraversiamo e formiamo un campione della lunghezza necessaria per il calcolo del criterio, selezionando solo accordi, appartenenti alla stessa sequenza. Poi calcoliamo il criterio su questo campione. A proposito, ci sono possibilità di usare la ricorsione quando si seleziona, per idea.

O ho frainteso la domanda?

P.S. Naturalmente, dobbiamo andare all'indietro nel file quando formiamo il campione.

il problema dell'inserimento di nuovi dati - risolvilo in qualche modo.

Perché passare e selezionare molte volte i calzini bianchi, se è più facile andare a buttare quelli bianchi in un cesto e quelli neri in un altro, e poi chiedere chi c'è e quanti sono.

 
komposter:

Viene letto un chunk. La dimensione del chunk è determinata dal numero di transazioni fino alla Seek Date che erano in una particolare sequenza.

A proposito, se il punto di partenza di ogni sequenza è noto, le date desiderate possono essere cercate con la ricerca binaria, poiché gli scambi sono ordinati per tempo.
 
ALXIMIKS:

il problema dell'inserimento di nuovi dati - risolvilo in qualche modo.

perché passare attraverso molte volte e scegliere calzini bianchi quando è più facile andare a gettare il bianco in un cesto nero in un altro e poi chiedere chi c'è e in quale quantità.

Troppi dati sono anche un male :)

Il problema è che non sono i bianchi e i neri ad essere selezionati qui, ma quelli che sono localmente più bianchi. Quindi calcolare il grado globale di oscurità non salva. A proposito, ho iniziato in questo thread solo con un suggerimento di calcolo continuo del criterio.

P.S. A proposito, nessuno impedisce di elaborare alcuni file insieme - semplicemente la cache per ciascuno dovrà fare meno. Ma sembra avere riserva sulla dimensione della cache.

Cioè, i nuovi dati possono semplicemente essere accumulati in un altro file.

P.P.S. A proposito, affettare il file in diversi file più piccoli faciliterà il problema dell'ordinamento.

 
komposter:

1. Se il Criterion fosse statico... E se i suoi parametri cambiano?

2. Sì, allora ci sarà uno scambio. Ma il ricalcolo sarà necessario solo per i dati più recenti, non c'è bisogno di scuotere l'intera storia.

3. Questo è uno strumento...

4. Esattamente.

1. Da quello che ho detto sopra"Lasciate che il criterio sia il profitto medio degli ultimi 20 trade della sequenza. "Questo dovrebbe essere inteso come un criterio, spostando l'aspettativa di profitto. Quali altri ci sono?

Nel database, genera una tabella con l'identificatore della sequenza e le medie mobili corrispondenti. Le sequenze che non soddisfano le condizioni devono essere eliminate immediatamente. Questo dovrebbe essere fatto da una procedura in modalità concorrente a livello di DBMS, su richiesta del robot, con lo stato del processo visualizzato nel robot.

Diciamo, FilterAvgProfit (pProfitValue, pTrades, pDeviation),

dove pProfitValue è l'obiettivo di profitto, pTrades è il numero di operazioni per la media mobile di profitto, pDeviation è la deviazione consentita da pProfitValue.

Il risultato - tabella riempita con ID di sequenza e valori medi di profitto.

Allo stesso modo, potete scrivere stored procedure per ogni criterio.

2. Se una parte dei dati viene scartata (usate "dati freschi" piuttosto che 1milione) si avrà un guadagno di prestazioni.

3. Non era molto chiaro dalla dichiarazione. Ora ok.

4. Capisco che se stiamo guardando una selezione di strategie, questa operazione non dovrebbe essere eseguita troppo spesso (diciamo, su ogni barra o immediatamente prima di aprire un ordine). Questo approccio è ragionevole se la strategia corrente mostra N trade perdenti di fila - allora possiamo sceglierne un'altra e ci vorrà del tempo per "prendere una decisione", non c'è niente da evitare. Oppure, eseguire tale selezione una volta alla settimana (nei fine settimana, quando il mercato è chiuso), e, o confermare la strategia attualmente selezionata, o passare a un altro. È possibile fare una lista di strategie ottimali raccomandate per un trader, in determinate condizioni. Poi, all'apertura del mercato e a mente lucida (il lunedì), il trader confermerà la scelta (o prima, prima dell'apertura del mercato... l'avviso via e-mail, ecc.)

Da qualche parte così.

 

Память выделяется однократно для массива структур последовательностей.

La struttura della sequenza comprende: N., matrice di strutture di tutti gli accordi 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.

Si alloca la memoria per un array di strutture e si ottiene:

schieramentono,

array di matrici di strutture di tutti gli accordi della sequenza [X],

un array di valori di criterio,

un array di File Pointer Positions.

Perché avete bisogno dellamatrice dei valori del criterio e dellamatrice delle posizioni dell'indice del file? (Avete pensato di conservare un Criterion e l'ultimo commercio?)

Ho capito bene:

Primo passaggio - ricerca sull'intervallo da 0 a SeekDate

poi trovare il criterio migliore eFindDate = ora di chiusura del commercio + 1

ricerca ora sull'intervallo tra"l'ora di chiusura degli scambi" e laSeekingDate ?

e bisogna avere X scambi in quell'intervallo per calcolare il criterio per ogni sequenza?

 
komposter:

Condividere i risultati della mia ricerca.

File binario di cache di 7529 MB letto:

  • Dal disco rigido: in 212,3 sec (35,46 MB/sec)
  • Dal disco RAM: in 88.1 sec (85.46 MB/sec)
È difficile chiamare la differenza cosmica, anche se ho il disco rigido più comune (anche se la memoria non è veloce).

Conclusione: circa 2,5x di accelerazione su un grande file letto da un disco RAM.

Strani risultati.

Ecco dal nostro sistema di server funzionante sotto carico:

  • con SSD: 200 Mb al secondo, NTFS
  • con RAM: 2000-2500 Mb al sec, FAT32, Softperfect RAM Disk 3.4.5

Senza dischi RAM, ci vuole molto più tempo per costruire i progetti.

 
Renat:

Strani risultati.

Questo è dal nostro sistema di server di produzione sotto carico:

  • con SSD: 200 Mb al secondo, NTFS
  • con RAM: 2000-2500 Mb al secondo, FAT32, Softperfect RAM Disk 3.4.5

Senza dischi RAM, ci vuole molto più tempo per costruire i progetti.

Questo è quello che stavo dicendo - bisogna leggere i file grandi in grossi pezzi, altrimenti quelli piccoli possono richiedere fino a 10 volte più tempo.
 
papaklass:

Secondo me, la soluzione del problema sta nella codifica dei dati grezzi.

Se non puoi cavartela leggendo i dati grezzi più volte, devi convertirli in un formato accettabile per letture multiple.

Una possibile opzione è quella di convertire ogni record in un numero a 16 bit. Ad ogni campo del record originale dovrebbe essere assegnato un numero specifico di bit nel numero. Per esempio:

La cifra più significativa del numero:

- "0" significa un risultato negativo della transazione;

- "1" denota un risultato positivo di una transazione.

la cifra più bassa del numero:

- "0" denota un trade BUY;

- "1" significa un affare SELL.

e così via.

Così, invece di leggere ripetutamente il file sorgente con molti campi, il lavoro si riduce a leggere ripetutamente un singolo campo numerico, il che dovrebbe dare un significativo aumento di velocità.

In generale, il file di origine può essere generato immediatamente in un formato codificato, anche se le informazioni in esso contenute appariranno in una forma non visiva.

Ma non in "16-bit" ma in 64-bit, Andrew ha un processore x64, quindi l'unità minima di volume quando si accede alla memoria è di 64 bit. Anche se si legge un byte dalla memoria, il processore leggerà comunque 8 byte (due parole doppie).

 
komposter:

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 mille!

Ecco, un'altra cosa ))