OpenCL: test di implementazione interna in MQL5 - pagina 4
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
Se ho capito bene, 1 GPU è un agente molto potente? Gli agenti della CPU possono essere disabilitati in questo caso (a causa della loro bassa velocità rispetto al video)? E ancora: è possibile avere due ATI senza crossfire?
AMD sconsiglia vivamente di usare Crossfire per OpenCL - poiché con Crossfire ci sono effettivamente due GPU ma il driver deve dividere UN lavoro grafico tra di loro. Al contrario, per OpenCL 1.1, non c'è ancora modo per il driver della scheda video stesso di dividere un singolo lavoro OpenCL tra le due GPU (vedi sopra).
Lo stesso per nvidia SLI.
Come influirà l'inclusione di OpenCL sul costo del calcolo nel cloud?
Il costo di un agente con GPU sarà superiore al costo di un agente senza GPU, poiché il tempo stimato del primo agente sarà significativamente più breve?
Dato che solo un agente sulla macchina locale riceverà una GPU, risulta che il costo dei diversi agenti sulla stessa macchina locale sarà diverso (e precalcolato)?
Come influirà l'inclusione di OpenCL sul costo del calcolo nel cloud?
Il costo di un agente con GPU sarà più alto del costo di un agente senza GPU perché il tempo di calcolo del primo agente sarà significativamente più breve?
Dato che solo un agente sulla macchina locale riceverà la GPU, risulta che il costo dei diversi agenti sulla stessa macchina locale sarà diverso (e precalcolato)?
Per impostazione predefinita, il terminale/agente sceglie il dispositivo GPU più potente in base alle sue caratteristiche all'avvio. Finora, non c'è nessuna idea di selezionare i dispositivi da MQL5 - questo complicherà solo il codice e porterà a ulteriori errori.
Invece, c'è un'idea più bella sotto forma di assegnazione automatica di ogni GPU fisica ad agenti separati, che permetterà di usarli al loro pieno potenziale.
Diciamo che abbiamo un EX5 (usando OpenCL) che si ottimizza 20 volte più velocemente su agenti con GPU che senza GPU.
Eseguiamo l'ottimizzazione sul cloud. È evidente che è più vantaggioso (in termini di tempo impiegato) eseguire l'ottimizzazione prima di tutto su quegli agenti che hanno una GPU fisica. Dando loro il grosso delle opzioni di enumerazione. È equivalente al loro PR che è 20 volte più alto. MA, il loro PR senza usare la GPU è lo stesso. Cioè un nuovo calcolo PR, PR_gpu, deve essere inserito.
"Quando si esegue un compito, il lavoro fatto dall'agente di prova viene contato come il prodotto del suo PR per il Tempo impiegato. "
Segue da questa formula che se non c'è PR_gpu, il costo di tutte le ottimizzazioni sul cloud con GPU sarà più economico che senza.
Purtroppo, l'introduzione di un calcolo alternativo di PR - singolo passaggio di prova del file EX5 ottimizzato contiene un numero enorme di insidie, a causa delle quali è impossibile utilizzarlo universalmente.
Segue da questa formula che se non c'è PR_gpu, il costo dell'intera ottimizzazione sul cloud con GPU sarà più economico che senza.
Sfortunatamente, l'introduzione di un calcolo PR alternativo - un singolo passaggio di prova di un file EX5 ottimizzato contiene un numero enorme di insidie che lo rendono impossibile da usare universalmente.
senza entrare nei dettagli, che non conosco, se il PR attuale non sarà rivisto, non ha senso girare nel cloud con la GPU
Inoltre, se si introduce un nuovo concetto, e lo si ama) Per esempio, se state introducendoun nuovo concetto, cosa che vi piace fare, è meglio definirlo subito o intuire che in questo caso si tratta del lato utente.
Attualmente PR = Const Koef / tempo impiegato per completare il compito di benchmark.
Il costo dell'ottimizzazione è uguale al numero di compiti di benchmark che potrebbero essere calcolati nel tempo che è durato l'ottimizzazione. Cioè, il costo del calcolo non dipende da come il cloud alloca i compiti tra gli agenti. Ma la durata finale dell'ottimizzazione dipende dall'allocazione corretta, che è la metrica più importante.
È chiaro che la nuvola assegna i compiti agli agenti in proporzione al PR precompilato per ridurre il tempo di calcolo (ma non il costo - CONST).
I compiti OpenCL saranno ovviamente assegnati prima agli agenti con la GPU giusta.
il costo del calcolo non dipende da come il cloud alloca i compiti tra gli agenti.
Sfortunatamente, l'introduzione di un calcolo PR alternativo - una singola prova di un file EX5 ottimizzato - contiene un enorme numero di insidie che lo rendono impossibile da usare universalmente.
Poiché il costo per l'ottimizzatore è sempre costante, ma la sua durata dipende fortemente da un adeguato (per il compito dato) calcolo PR, forse dovremmo introdurre l'ottimizzatore per inserire il suo codice EX5 PR_calculate sulla sua coscienza. Dove l'ottimizzatore, in base alle caratteristiche del suo algoritmo, imposterà il PR distributivo più adatto al suo compito.
Per esempio, se il compito è puramente computazionale, l'enfasi in PR_calculate sarà sulla matematica.
Se il compito gestisce enormi quantità di dati, l'enfasi sarà sulla velocità di gestione della memoria.
Se la GPU viene usata un po' - visualizzatelo nel vostro PR_calculate.
Se la GPU è usata ovunque in EX5 - scrivete un PR_calculate appropriato (con un uso appropriato della GPU).
In questo schema, coloro che affittano la potenza alla nuvola non perdono nulla, e coloro che usano la potenza della nuvola hanno la possibilità di accelerare i loro calcoli in modo significativo.
Se PR_calculate non è specificato, viene utilizzato il compito di riferimento universale già accettato.
P.S. PR_calculate è usato solo per allocare i compiti nel cloud. Per il calcolo dei costi, si usa ancora lo stesso vecchio PR.
P.P.S. Ci sono, naturalmente, delle insidie - PR_calculate deve essere eseguito in anticipo su tutti gli agenti liberi. PR_calculate può essere scritto in errore - in loop. Quindi, per il tempo necessario a calcolare PR_calculate, bisogna anche far pagare secondo lo schema classico di PR. Ecc.
Poiché il costo per l'ottimizzatore è sempre costante, ma la sua durata dipende fortemente dal calcolo adeguato (per il compito dato) di PR, forse vale la pena di introdurre alla coscienza dell'ottimizzatore l'input al suo codice EX5 PR_calculate. Dove l'ottimizzatore, in base alle caratteristiche del suo algoritmo, imposterà il PR distributivo più adatto al suo compito.