OpenCl e i relativi strumenti. Recensioni e impressioni. - pagina 28
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
Tra un paio d'anni vi ricorderemo questo thread.
Personalmente per me questo ramo è stato molto utile - anche quando il topicstarter ha cominciato a spaventare il mio spirito immaturo orrore della ridotta precisione dei calcoli.
La modalità di ottimizzazione su MT5 è molto lenta quando l'algoritmo genetico è abilitato. Ho creato un Expert Advisor su MT4 e l'ho testato e ottimizzato. Il tempo di ottimizzazione non supera i 5 minuti su dual core (naturalmente MT4 ha solo un core coinvolto, ma altri compiti non interferiscono, perché possono essere eseguiti sul secondo core). Ho riscritto lo stesso Expert Advisor per MT5. L'ho testato per l'ottimizzazione. Il tempo di ottimizzazione è più di un'ora, quasi 2 ore per essere esatti. Qual è la differenza?
Non c'è differenza ora.
Bene, MetaTrader 5 sembra essere in vantaggio anche quando il test viene effettuato in base ai prezzi di apertura: Confronto della velocità di test in MetaTrader 4 e MetaTrader 5
Come promesso, abbiamo semplificato la modalità di test di apertura della barra e l'abbiamo resa più veloce.
Beh, sono passati due anni.
La versione CUDA dell'EA funziona. Sotto MT4. Per ora, è solo in modalità di test. Finora non riesco a ottenere l'accelerazione dei calcoli promessa da nVidia.
Ci sono due problemi qui:
1. nVidia stessa, che esagera la velocità di riprogettazione dei programmi, o NON prepara affatto la sua documentazione, o cambia radicalmente alcuni aspetti essenziali della programmazione.
2. La parallelizzazione degli algoritmi sotto GPU richiede molto più tempo del previsto. Quando ho iniziato il porting di un programma da DLL a CUDA-DLL, basandomi sui miei oltre 20 anni di esperienza nel linguaggio Caelian, ho pensato che le promesse di nVidia dovrebbero essere divise per 3, e il tempo di porting dell'algoritmo che hanno citato dovrebbe essere moltiplicato per, diciamo, 3.
Ma si è scoperto che la regola generale è: tutte le promesse di nVidia devono essere divise per DIECI e il tempo stimato del porting di C su CUDA deve essere moltiplicato per 10.
Nota: se avete capito i principi del funzionamento degli acceleratori GPU, potete fare il porting dell'algoritmo da C a CUDA in TRE SETTIMANE. E potete farlo direttamente - solo per controllare la costruzione. Cioè, il vostro programma sarà eseguito da SOLO UNO delle centinaia o MIGLIAIA di piccoli processori nella scheda video. Questo funziona circa 70 (settanta) volte più lentamente che sulla CPU. Sì, lento, ma funziona.
Poi puoi, con uno sforzo considerevole, iniziare a mettere in parallelo il tuo programma. Questo funziona già 4-5 volte più lento, o solo 2-3 volte più veloce che sul processore centrale.
E modificare il vostro ALGORITMO globalmente, in modo che venga eseguito in PASSIONE, ripeto in PASSIONE, invece che in modo sequenziale come vi insegnano in tutte le università del mondo, è un compito difficile.
Chiariamo - è difficile ma non insolito parallelizzare un normale algoritmo sequenziale con il principio del Multithreading. È una cosa. Allo stesso modo, si ottiene un'accelerazione di 5-10 volte sulla GPU. Ma per convertire l'algoritmo sequenziale in un algoritmo a grappolo (non ho una parola migliore nel mio vocabolario), per caricare centinaia e migliaia di processori GPU e ottenere l'accelerazione di 100 volte come promesso da nVidia - questo può essere un problema.
Ma è anche risolvibile. È solo una questione di tempo.
Ma c'è anche la Crimea, Benderites e così via .....
3. MetaTrader-4 non ha problemi quando si scrive una DLL per CUDA.
Il problema è che gli sviluppatori del software nVidia (2500 persone) sono radicalmente in disaccordo con il modello di multithreading usato in MetaTrader-4-5. Nvidia ha cambiato radicalmente questo modello quando è passata da CUDA 3.2 a 4.0+. Inoltre, se iniziate a chiedere loro perché era così (come Metatrader-4 e centinaia di altri programmi multi-threaded) e ora è così, tutto quello che sentirete in risposta è "avete fondamentalmente frainteso il nostro kAnstment".
L'ho già sentito da qualche parte.... recentemente.....
4. È molto più facile tradurre un nuovo algoritmo da C a CUDA che da C a OpenCL generico direttamente, quindi raccomando questo modo. Tanto più che proprio oggi nVidia dovrebbe presentare ufficialmente CUDA-6 in cui, teoricamente, sulle nuove GPU serie Maxwell e sotto alcuni sistemi operativi sarà possibile ridurre significativamente la quantità di programmazione - a causa dell'unificazione della memoria e l'abbandono delle operazioni di inoltro tra CPU e GPU.
Ebbene?
Quindi?
Nessuno è interessato?
Non una sola domanda o un solo post in un anno.
Ma è interessante per Nvidia: ha letto le mie lamentele su questo e altri forum, ha riunito il loro consiglio artistico, lo ha sfregato in ogni modo possibile - e ha deciso che anche i trader sono persone, e che anche il terminale di trading è un programma, e ha introdotto nell'ultima versione di CUDA una chiave speciale per il compilatore - per creare un programma altamente multithreaded in CUDA.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
una stringa come
nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread
Sfortunatamente, anche lo Xeon Phi non è decollato. Ed è ancora più vicino alla programmazione convenzionale.
Chiunque abbia bisogno di potenza nei calcoli universali può ora ottenerla facilmente, senza sforzare molto i sistemi multiprocessori di uso generale. Il numero di core nei processori Intel sta crescendo abbastanza velocemente.
Per esempio, i nostri server hanno 40 core ciascuno, ho anche un computer funzionante con 20 core e memoria DDR4. Un server con 40 core di Xeon 3Ghz batte inequivocabilmente uno Xeon Phi a bassa frequenza con 56 o più core senza dover riscrivere una sola riga di codice.
Chiunque abbia bisogno di potenza nei calcoli di uso generale può ora ottenerla facilmente senza molto sforzo sui sistemi multiprocessori di uso generale. Il numero di core nei processori Intel sta crescendo abbastanza rapidamente.
Per esempio, i nostri server hanno 40 core ciascuno, ho anche un computer funzionante con 20 core e memoria DDR4. Un server basato su Xeon con 40 core a 3Ghz batte inequivocabilmente uno Xeon Phi a bassa frequenza con 56 o più core, senza richiedere la riscrittura di una sola riga di codice.
Sei leggermente in errore (2 volte. Entrambi.). Fondamentalmente, lo pensavo anch'io, soprattutto quando mi sono avvicinato alla programmazione su GPU.
(1). La "potenza in calcoli universali" su un host-CPU può essere facilmente ottenuta SOLO per gli algoritmi più semplici. Questo è il punto critico per la maggior parte dei programmatori OpenMP e GPU. Ci sono centinaia di milioni di schede video CUDA vendute, ma solo circa 300 programmi per esso. Per la finanza - solo circa 7-8 (senza contare le collezioni di biblioteche inutili).
Controlla la lista completa sul sito web di nVidia:
http://www.nvidia.com/object/gpu-applications.html?cFncE
(Il nostro primo EA accelerato da CUDA disponibile in commercio per il terminale di trading MT4 *non* c'è ancora).
Questa lista non è cambiata per diversi anni.
Perché? Bene, perché il complesso algoritmo adattivo, che può essere facilmente messo insieme da pezzi su un host-CPU, si scopre che non basta programmarlo, occorre BREAK. E non è una cosa così facile da fare a causa di :
a). peculiarità e limitazioni del modello GPU CUDA-OpenCL (kernel di dimensioni diverse dovrebbero essere eseguiti in sequenza).
b). qualsiasi trasferimento di dati attraverso il bus PCI tra la GPU e il processore host ucciderà l'intero guadagno di velocità. E in algoritmi adattativi complessi, non si può fare a meno di loro.
(2). "non richiedendo una sola linea di codice da riscrivere" è anche solo per algoritmi semplici. La situazione è peggiorata dal fatto che OpenMP - come reale alternativa alla GPU - funziona in modo misterioso, cioè a volte funziona e a volte produce spazzatura. È un'illusione che semplicemente aggiungendo una linea pragma in un posto, l'algoritmo si parallelizzerà immediatamente in quel modo. È tutt'altro. In un algoritmo complesso si verificano tali correlazioni inaspettate tra i dati e i thread paralleli che non possiamo fare a meno di costruire un grafico.
La GPU è una questione completamente diversa. C'è più lavoro da fare lì all'inizio, ma il programma funziona SEMPRE correttamente, in termini di tempi. Inoltre, un programma riscritto per CUDA (anche senza scrivere i kernel) viene tradotto in OpenMP ATTIVAMENTE da una riga di pragma e QUESTO funziona. Non ha alcun senso tradurlo in OpenMP solo dopo questo - sarebbe molto più prospettico e affidabile aggiungere kernel per CUDA-OpenCL. Sorprendentemente, i kernel per le GPU CUDA risultano essere brevi, chiari e affidabili.
Bene e in termini di velocità assoluta e affidabilità - la CPU host non ha alcuna possibilità contro la GPU.
=I mercati finanziari e il forex in particolare sono una versione MOLTO compressa di enormi processi in tutto il mondo.
=Per questa ragione, un aglitmo per la previsione dei prezzi non può essere semplice. Quindi deve essere adattivo e figurativamente parlando statistico al momento.
=Così senza simulazione e feedback adattivo in un algoritmo così buono non c'è nessun posto dove andare.
=Quindi, se l'host-CPU può ancora essere utile per piazzare ordini (cioè la sua velocità è ancora abbastanza alta), è quasi impossibile lavorare senza GPU per scopi di test e ottimizzazione.
Lei ha affermato due volte che avevo torto e poi, con la scusa della prova, ha dato una prova completamente estranea.
Ho ragione su quanto segue (che è stato dichiarato immediatamente):
Non ho affatto menzionato OpenMP. Dal mio punto di vista, OpenMP è un "proiettile d'argento per gli smidollati". Se state lottando per le prestazioni reali, sbarazzatevi delle sciocchezze di OpenMP e scrivete a mano il codice multi-threaded inizialmente corretto/nativo, profilatelo e spingetelo al massimo.
Tu stesso hai dimostrato che non c'è abbastanza software di GPU Computing. La maggior parte dei programmi GPU sono solo i casi più semplici, compresi i cracker di password e i minatori sciocchi (i giochi non sono discussi).
La mia opinione è che le CPU e l'infrastruttura sottostante si stanno evolvendo abbastanza velocemente da superare le GPU in termini di prestazioni reali nelle applicazioni del mondo reale. 3-4 anni fa avreste potuto credere nel potenziale delle GPU, ma ora è diventato chiaro.
Lei ha affermato che ho sbagliato due volte e poi, con la scusa della prova, ha dato una prova completamente estranea.
Ho ragione su quanto segue (che è stato dichiarato immediatamente):
Non ho affatto menzionato OpenMP. Dal mio punto di vista, OpenMP è un "proiettile d'argento per gli smidollati". Se state lottando per le prestazioni reali, abbandonate le sciocchezze di OpenMP e scrivete a mano il codice multi-threaded inizialmente corretto/nativo, profilatelo e spingetelo al massimo.
Tu stesso hai dimostrato che non c'è abbastanza software di GPU Computing. La maggior parte dei programmi GPU sono solo i casi più semplici, compresi i cracker di password e i minatori sciocchi (i giochi non devono essere discussi).
La mia opinione è che le CPU e l'infrastruttura sottostante si stanno evolvendo abbastanza velocemente da superare le GPU in termini di prestazioni reali nelle applicazioni del mondo reale. 3-4 anni fa avreste potuto credere nel potenziale delle GPU, ma ora è diventato chiaro.
1. estrapolando il tasso di crescita dei core dall'host-CPU, è improbabile che nei prossimi anni il loro numero raggiunga i 3000 core come OGGI ha una buona scheda video. E ogni core della scheda video funziona a circa 1GHz. Quindi sarebbe impossibile per un processore host competere con la GPU. Ma questo supponendo che ci sia un buon programma che possa non solo e non tanto lavorare quei 3000 core, ma che si occupi anche di tutte le insidie dell'architettura hardware delle GPU di oggi. E la velocità video della memoria GDDR5 sulla scheda video media oggi è di circa 150 GByte/sec. Tutti i tipi di memoria DDR4 (25 GB/sec) hanno ancora molta strada da fare.
Come può un processore host competere con 40-60 core, anche a 4GHz e 25Gb/s di memoria?
2. Tutti i tipi di esotici come Phi non hanno il supporto necessario e la versatilità di una scheda video. Pertanto, si sono estinti.
3. sulla necessità di una programmazione diretta in multithreading - sì, sono d'accordo con te, ma è un compito arduo . Scrivere un complesso NUOVO algoritmo adattivo in una sola volta in una versione multi-threaded è molto difficile. E bisogna lavorare per evoluzione, per così dire. E inoltre, non c'è bisogno che vi dica quanto male Windows gestisce il multi-threading quando è davvero pieno (ci sono tutti i tipi di ritardi). Ecco perché anche il sistema operativo ha inventato le cosiddette fibre - fili semplificati.
Conclusione: non c'è niente di più economico, promettente e affidabile della GPU.