OpenCl e i relativi strumenti. Recensioni e impressioni. - pagina 6
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
Ho il sospetto che sia quello che Mischek stava gridando un mese fa.
Vedo l'applicazione di OpenCL in test pesanti o in calcoli parallelizzati molto intensi al volo.
Finora non ne ho bisogno (tutti i calcoli pesanti sono nel mio init() dell'induttore), ma vale la pena menzionarlo.
Alexey, ho lo stesso problema: cerco di trascinare qualcosa in init, e poi in tempo reale :)
Il mio cervello è acceso su un linguaggio procedurale. OOP è auspicabile, ma non nativo.
Per i fanatici che non vanno su mql5.com: OpenCL: prove interne di implementazione in MQL5
Grazie, personalmente non l'ho visto. Solo che non è così semplice.
Inoltre, Rinat sta confondendo le persone: OpenCL 1.0 può funzionare bene con il doppio float, è una "opzione pubblica" supportata da tutti i produttori - MA NON PER TUTTI I VECCHI MAPPE.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Doppia precisione opzionale e mezza virgola mobile
OpenCL 1.0 aggiunge il supporto per la doppia precisione e l'half floating-point come estensioni opzionali. Il tipo di dati doppio deve confermare il formato di memorizzazione IEEE-754 a doppia precisione.
Un'applicazione che vuole usare il doppio dovrà includere la direttiva #pragma OPENCL EXTENSION cl_khr_fp64: enable prima che qualsiasi tipo di dati a doppia precisione sia dichiarato nel codice del kernel. Questo estenderà la lista dei tipi di dati vettoriali e scalari incorporati per includere i seguenti:.....".
Può funzionare nello Strategy Tester ma non funzionerà nell'Expert Advisor OpenCL 1.0 non perché, come dice Rinat, "non c'è un doppio float lì" ma, come ho già detto, a causa della mancanza di threading sicuro in OpenCL 1.0 e il casino con i thread in MT4-5.
OpenCL (e CUDA) è confuso in generale. Che cosa vuoi? Dopo tutto, gli ingegneri del ferro e della radio si sono proposti di cambiare il concetto di programmazione. Hanno una mentalità di ferro.
Ci sarà anche un problema con la cosiddetta "PLATFORM SELECTION": il programma, cioè MT o DLL o Expert Advisor, DEVE, solo DEVE scegliere la piattaforma (AMD, Nvidia, Intel), che può essere diversa che eseguirà il connettore OpenCL, e poi selezionare manualmente DEVICE se il vostro computer sta eseguendo Multi-GPU. La selezione automatica della piattaforma in OpenCL non c'è ancora. Rinat parla di "auto-selezione del più potente" ma non so come sia. Nell'esempio mostrato, non c'è selezione di piattaforma e di dispositivo (GPU, CPU).
Inoltre, non c'è ancora una parallelizzazione automatica dei compiti OpenCL su diverse GPU o su GPU+CPU nello standard. Mettiamola così: in alcune versioni dei suoi driver/SDK AMD introduceva tale autoprovisioning ma ha avuto alcuni problemi e per il momento AMD ha disattivato questa funzione.
In conclusione: sviluppare e abilitare programmi OpenCL c/o MT4-5 richiede un certo sforzo manuale e quindi non funzionerà automaticamente o "ricompilando con opzione". Il che, a sua volta, comporta un sacco di stallo nel funzionamento nel mondo reale. Sarà un lavoro sottile e, ciò che è importante, mi permetto di ripetere, purtroppo è una PROGRAMMAZIONE ORIENTATA ai giudei, che è sbagliata. Il debugging di programmi paralleli per CUDA o OpenCL si è rivelato molto più difficile di quanto i rivoluzionari del ferro abbiano ipotizzato. Nvidia ha persino cancellato la loro conferenza CUDA dell'autunno 2011 - a causa di problemi con i driver e un sacco di lamentele sullo stallo del debug. Quindi, hanno aggiunto altre 1000 nuove funzionalità all'ultimo Toolkit - e cosa fare se i programmi più semplici non funzionano nemmeno o funzionano con interruzioni? Dopo tutto, non hanno nemmeno menzionato la metà del meccanismo interno di OpenCL o CUDA nei loro strumenti descrittivi.
La velocità della GPU (in GigaFLOPS) di una scheda video sospesa a causa della compatibilità del driver o del software è zero.
Grazie, non l'ho visto personalmente. Solo che non è così semplice.
....Non è questo il punto. Si può scrivere in stile procedurale su un cinque.
joo: E sono scoraggiato da questo fatto, akhtung! - MQL4 che chiama la dll funziona più velocemente di MQL5 che chiama la stessa dll...
Questo è ciò che è così allarmante.
Avrebbero potuto sviluppare un supporto nativo per OMP in MQL5. Sarebbe facile ed economico per il codificatore, e non c'è bisogno di scrivere alcuna DLL.
Ma questo sciame di api in un linguaggio di programmazione di ferro incompleto... non mi ispira ancora molto. Beh, sì, un'accelerazione centuplicata in alcuni casi è grande, ma in termini di cultura della programmazione è un passo indietro.
C'è molta confusione in OpenCL (e CUDA) in generale. Che cosa vuoi? Dopo tutto, gli ingegneri del ferro e della radio si sono proposti di cambiare il concetto di programmazione. Hanno una mentalità di ferro.
Ci sarà anche un problema con la cosiddetta "PLATFORM SELECTION": il programma, cioè MT o DLL o Expert Advisor, DEVE, solo DEVE scegliere la piattaforma (AMD, Nvidia, Intel), che può essere diversa che eseguirà il connettore OpenCL, e poi selezionare manualmente DEVICE se il vostro computer sta eseguendo Multi-GPU. La selezione automatica della piattaforma in OpenCL non c'è ancora. Rinat parla di "auto-selezione del più potente" ma non so come sia. Nell'esempio mostrato, non c'è selezione di piattaforma e di dispositivo (GPU, CPU).
Inoltre, non esiste ancora un modo standard per parallelizzare automaticamente i compiti OpenCL su diverse GPU o su GPU+CPU. Mettiamola così: in alcune versioni dei suoi driver/SDK, AMD implementava tale autoparallelizzazione ma ci sono stati problemi e AMD l'ha finora disattivata.
In conclusione: sviluppare e abilitare programmi OpenCL c/o MT4-5 richiede un certo sforzo manuale e quindi non funzionerà automaticamente o "ricompilando con opzione". Il che a sua volta è irto di molti stalli nel funzionamento reale. Sarà un lavoro sottile e, ciò che è importante, mi permetto di ripetere, purtroppo è una PROGRAMMAZIONE ORIENTATA ai giudei, che è sbagliata. Il debugging di programmi paralleli per CUDA o OpenCL si è rivelato molto più difficile di quanto i rivoluzionari del ferro abbiano ipotizzato. Nvidia ha persino cancellato la loro conferenza CUDA dell'autunno 2011 - a causa di problemi con i driver e un sacco di lamentele sullo stallo del debug. Così, hanno aggiunto altre 1000 nuove funzionalità all'ultimo Toolkit - e cosa fare con questo, se i programmi più semplici non funzionano nemmeno o funzionano con interruzioni? Dopo tutto, non hanno nemmeno menzionato la metà del meccanismo interno di OpenCL o CUDA nei loro strumenti descrittivi.
La velocità della GPU (in GigaFLOPS) di una scheda video sospesa a causa della compatibilità del driver o del software è uguale a zero.
Non è questo il punto. Si può scrivere in stile procedurale anche su 5.
Ma questo è allarmante.
Avrebbero potuto sviluppare un supporto nativo per OMP in MQL5. È semplice e sereno, non c'è bisogno di scrivere nessun dll.
Ma questo sciame di api in un linguaggio di programmazione hardware incompleto... ...non sembra molto eccitante. Sì, un'accelerazione centuplicata in alcuni casi è grande, ma in termini di cultura della programmazione è un passo indietro.
Ho anche incontrato fatti in cui mql4 funziona più velocemente di MQL5. Nella maggior parte dei casi si manifesta in operazioni matematiche ottimizzate dal programmatore.
Ma penso che questo non sia il problema principale - usando OpenCL MQ hanno preso una strada che corre parallela al percorso di programmazione principale - forse finora questo richiede un passo indietro, ma nel futuro sviluppo della tecnologia dei computer vedremo sistemi scalabili integrati dove dipenderà già dal codice se l'elaborazione sequenziale o parallela viene utilizzata.
Quindi la strada è abbastanza giusta. Anche se al giorno d'oggi non ci sono così tanti algoritmi che richiedono l' implementazione dell'approccio parallelo, ma è piuttosto perché il pensiero matematico non aveva attrezzature per l'implementazione di calcoli paralleli e quindi non c'era bisogno di creare tali algoritmi.
Alexey, pensa solo a un fatto, tutte le scoperte matematiche sono state fatte 200-300 anni fa, gli ultimi 100 anni il pensiero matematico stava solo lucidando ciò che è. È stata solo la scoperta dei NS a creare la domanda di calcoli paralleli. I prossimi 100 anni vedranno algoritmi sostanzialmente paralleli. E tu, tra gli altri, puoi inventarne uno.
Ho anche visto fatti in cui mql4 è più veloce di MQL5. Questo si vede più spesso nelle operazioni matriciali ottimizzate dal programmatore.
Ma penso che questo non sia il problema principale - entrando in OpenCL MQ ha preso una strada che corre parallela alla strada principale della programmazione; forse finora questo richiede un passo indietro, ma nel futuro sviluppo della tecnologia informatica vedremo sistemi scalabili integrati dove dipenderà già dal codice se si usa l'elaborazione sequenziale o parallela.
Quindi la strada è abbastanza giusta. Anche se al giorno d'oggi non ci sono così tanti algoritmi che richiedono l' implementazione dell'approccio parallelo, è piuttosto perché il pensiero matematico non aveva attrezzature per l'implementazione di calcoli paralleli e quindi non c'era bisogno di creare tali algoritmi.
Alexey, pensa solo a un fatto, tutte le scoperte matematiche sono state fatte 200-300 anni fa, gli ultimi 100 anni il pensiero matematico era solo la lucidatura di ciò che è. È stata solo la scoperta dei NS a formare la domanda di calcoli paralleli. I prossimi 100 anni vedranno algoritmi sostanzialmente paralleli. E tu, tra gli altri, puoi inventarne uno.
No, non siete del tutto senza speranza dopo tutto. :)
Ciao.
MQ sono bravi, non hanno avuto paura di affrontare un dolore (per loro) come l'introduzione del supporto per i calcoli GPU. Il dolore, prima di tutto, è legato al fatto che l'introduzione di tecnologie fondamentalmente nuove (qualsiasi) riduce all'inizio l'affidabilità e la tolleranza ai guasti della piattaforma nel suo insieme. Ma capiscono perfettamente che il futuro appartiene al calcolo parallelo e prima o poi dovranno fare qualcosa in questa direzione (il primo passo è già stato fatto - il cloud).
PS Ciao Nikolai. Perché sei scomparso? - Scrivimi una riga.
Questo non è un fatto in quanto non lo è. Lo sviluppo qualitativo della matematica non è mai stato interrotto.
E i calcoli paralleli non sono necessari solo per NS, ci sono compiti più banali - per esempio, la codifica video o il rendering.
Ma il vettore generale del movimento MQ è certamente incoraggiante.