
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
Quale parte del mio codice ti interessa esattamente? Ho un sacco di dipendenze da diversi file.
Il problema che ho ora è solo scrivere e leggere il buffer in 1 tick del tester, e per il controllo è sufficiente:
Esecuzione di uno script:
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) Dispositivo #0 = Cypress
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) OpenCL: Dispositivo GPU 'Cypress' selezionato
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) build log =
2013.10.30 18:55:40 OpenCL_buffer_test (EURUSD,H1) Dimensione del buffer in byte =240
Esecuzione di expert in tester dal 2013.01.09 al 2013.10.10 su M5 con "OHLC su M1":
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 Dispositivo #0 = Cypress
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 OpenCL: Dispositivo GPU 'Cypress' selezionato
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 build log =
2013.10.30 19:01:44 Core 1 2013.01.09 00:00:00 Dimensione del buffer in byte =240
2013.10.30 19:04:55 Core 1 EURUSD,M5: 1108637 ticks (55953 barre) generati entro 192443 ms (totale barre nella storia 131439, tempo totale 192521 ms)
2013.10.30 19:04:55 Core 1 294 Mb di memoria utilizzata
Si noti che c'è solo 1 dispositivo nel tester.
Se
//CLBufferRead(hbuffer[1], price);
poi
Se è necessario eseguire calcoli sui dati OHLC, allora è imperativo fare una scrittura parsimoniosa, cioè creare un buffer più grande in anticipo e sovrascrivere questi nuovi dati solo quando arrivano nuovi dati, dicendo al kernel il nuovo inizio e la dimensione del buffer.
Anche se riusciamo a ottimizzare il trasferimento OHLC (useremo CLSetKernelArg per trasferire l'ultima barra), andremo comunque in crash durante la lettura del buffer dei risultati:
Ebbene, chi vi impedisce di farlo? Vai a scrivere qualcosa di reale che non sia una favola. Ma cercate di trovare un esempio in modo che l'accelerazione avvenga. Questa è la parte più difficile.
Se stai parlando dei miei articoli... Beh, stavo scrivendo una guida. E la moltiplicazione delle matrici è un'operazione abbastanza utile.
P.S. A proposito, se la vostra CPU è Intel, l'emulazione dei core x86 su di essa è molto più veloce che su una CPU concorrente. Questo se si ricalcola per core.
HD5850: fondamentalmente una scheda abbastanza decente, ma le schede moderne sono migliori - non solo a causa di più mosche, ma anche per le ottimizzazioni OpenCL. Per esempio, il tempo di accesso alla memoria globale è significativamente ridotto.
P.P.S. OpenCL non è una panacea; è uno strumento valido che può accelerare significativamente in alcuni rari casi. E in altri casi non così convenienti, l'accelerazione non è così impressionante - se c'è.
Eh... Gli articoli sulla velocizzazione usando OpenCL su GPU si sono rivelati una favola, dato che non si occupano realmente di compiti reali :(
Non è così. La favola è che "qualsiasi algoritmo può essere accelerato in OpenCL". Non qualsiasi algoritmo.
Il primo thread su OpenCL descrive anche abbastanza bene i criteri che un algoritmo deve possedere per avere un potenziale di accelerazione ocl.
Buona fortuna.
L'affermazione non riguarda la velocità di calcolo - c'è un aumento di velocità di 2 volte (0,02 ms contro 0,05 ms)
L'affermazione è che non ci sono informazioni negli articoli:
Probabilmente sono il primo a voler accelerare il test a spese della GPU, avendo letto le promesse...
Rileggi il mio post.
Il criterio principale: l'esecuzione del codice MQL in "stile OpenCL" dovrebbe superare il tempo = Numero di_Buffer * 0,35300 ms in 1 tick.
Per scoprire la velocità dell'algoritmo in MQL con una precisione di microsecondi (1000 microsecondi = 1 millisecondo), si dovrà eseguire nel tester diverse volte e Total_Time / Number_of_Ticks (il mio post superiore).
Se non fosse per il ritardo del buffer, il mio codice passerebbe il test in ~30 secondi - che è ~2 volte più veloce del MQL "stile OpenCL" (55 secondi) e ~11 volte più veloce del codice normale (320 secondi).
Quali altri criteri ci sono?
A giudicare dalla vostra esperienza con OpenCL, avrete già capito che non tutti gli algoritmi sono direttamente accelerati. Uno dei problemi principali qui è minimizzare gli accessi alla memoria globale.
A proposito, ora devo risolvere un problema simile con l'accesso casuale alla memoria globale del dispositivo (troppo privato questo accesso casuale, ed è un cazzo di overhead). Lo risolverò non appena avrò rimesso in sesto il mio cervello.
Il tester non seleziona la CPU per OpenCL - questo non è riportato da nessuna parte!
Scrivete al Service Desk e giustificate la necessità di tale caratteristica.
Se il tester non viene utilizzato, è già fatto (questa è la mia applicazione). E non ho ancora controllato il tester.
È già stato scritto che non tutti gli algoritmi sono direttamente accelerati. Devi usare il tuo cervello qui, e uno dei problemi principali è quello di ridurre al minimo gli accessi alla memoria globale.
Bene, ora devo risolvere un problema simile con l'accesso casuale alla memoria globale (questo accesso casuale è troppo frequente). Lo risolverò non appena avrò il cervello in funzione.
È il momento di usare il cervello perché 0,35300 ms si riferisce esattamente a clEnqueue[Read/Write]Buffer() e non agli accessi globali alla memoria all'interno del kernel.
Il secondo può essere risolto ottimizzando il kernel stesso, mentre il primo è un limite di ferro.