"New Neural" è un progetto di motore di rete neurale Open Source per la piattaforma MetaTrader 5. - pagina 58

Nuovo commento
 
TheXpert:
???
Andrei TheXpert, se dici A, di' B. Qual è, secondo lei, il principale collo di bottiglia delle NS?
 
Urain:
Non importa.
 
TheXpert:
Non importa.

Voglio sviluppare, sentire opinioni diverse e trarre conclusioni.

Voglio sviluppare, voglio sentire opinioni e conclusioni diverse.

 

GPU Cuda è una cosa potente. Avevo del codice che girava per 2-3 ore su 16 Intel Tracks (CPU a 4 core). E su 300+ core CUDA ha percorso la stessa distanza in 10 minuti, il che è impressionante. Ma lo sviluppo del codice Kuda era molto complicato: bisognava dividere manualmente tutti i calcoli del codice in thread paralleli, ottimizzare la memoria (purtroppo i core Kuda hanno poca memoria). Era al di là del mio potere - un programmatore intelligente mi ha aiutato. Ho ancora paura del suo codice e continuo a fare tutte le modifiche nel mio codice originale (non parallelizzato). Ho sviluppato un'opinione: se l'algoritmo è stabile, può essere ottimizzato e trasferito su GPU con l'aiuto di un programmatore competente - i programmatori autodidatti come me non possono farlo. Se si inizia subito con il codice GPU per un algoritmo ben addestrato, ci vorrà molto tempo per bypassarlo. Comincio sempre con un codice semplice anche se non ottimale, che posso capire da solo, e solo dopo aver ottenuto i risultati attesi comincio a ottimizzarlo. Sono un casino, non un programmatore :)

 
gpwr:

GPU Cuda è una cosa potente. Avevo del codice che girava per 2-3 ore su 16 Intel Tracks (CPU a 4 core). E su 300+ core CUDA ha percorso la stessa distanza in 10 minuti, il che è impressionante. Ma lo sviluppo del codice Kuda era molto complicato: bisognava dividere manualmente tutti i calcoli del codice in thread paralleli, ottimizzare la memoria (purtroppo i core Kuda hanno poca memoria). Era al di là del mio potere - un programmatore intelligente mi ha aiutato. Ho ancora paura del suo codice e continuo a fare tutte le modifiche nel mio codice originale (non parallelizzato). Ho sviluppato un'opinione: se l'algoritmo è stabile, può essere ottimizzato e trasferito su GPU con l'aiuto di un programmatore competente - i programmatori autodidatti come me non possono farlo. Se si inizia subito con un codice GPU per un algoritmo ben addestrato, ci vorrà molto tempo per bypassarlo. Comincio sempre con un codice semplice anche se non ottimale, che posso capire da solo, e solo dopo aver ottenuto i risultati attesi comincio a ottimizzarlo. Sono un casino, non un programmatore :)

Pertanto vorremmo il consiglio di uno specialista nel campo del GPU Computing. yu-sha e JavaDev, ay!

Interessato alle seguenti domande:

1. Quali aspetti dovrebbero essere esaminati prima di tutto quando si rende un progetto (o i suoi moduli separati) calcolato su GPU che eviterebbe la fastidiosa riprogettazione in futuro?

2. Quali sono i limiti di memoria per i core della GPU? È possibile mettere in memoria l'intero codice di runtime (decine e centinaia di migliaia di barre)?

Finora tali, domande generali. Quelli più dettagliati, credo, arriveranno più tardi.

 
joo:

Vorremmo quindi un consiglio da un esperto di GPU Computing. yu-sha e JavaDev, ow!

Interessato alle seguenti domande:

1. A quali aspetti si dovrebbe prestare attenzione in primo luogo quando si crea un progetto (o i suoi singoli moduli) su GPU per evitare la fastidiosa riprogettazione in futuro?

2. Quali sono i limiti di memoria per i core della GPU? È possibile mettere in memoria l'intero codice di runtime (decine e centinaia di migliaia di barre)?

Finora tali, domande generali. Quelli più dettagliati, credo, arriveranno più tardi.

Perché pasticciare con un cuda in un progetto destinato a un uso generale? Alcuni utenti hanno un cuda, altri ne hanno uno diverso e altri ancora non hanno alcun cuda. Io, per esempio, non ho cuda sul mio portatile di lavoro. Lo stesso codice di rete sarà molto diverso a seconda del numero di core del cuda e della memoria. Meglio all'inizio scrivere questo motore di rete per il normale processore Intel perché tutti possano usarlo, e poi ottimizzarlo per Kuda se ha senso. A proposito, è meglio creare il motore in modo che funzioni nel cloud. Non ho familiarità con il cloud computing. C'è qualcosa lì dentro?
 
gpwr:
Perché preoccuparsi di un cuda in un progetto destinato a un uso generale? Alcuni utenti hanno un cuda, altri ne hanno uno diverso e altri ancora non hanno alcun cuda. Per esempio non ho cuda sul mio portatile al lavoro. Lo stesso codice di rete sarà molto diverso a seconda del numero di core del cuda e della memoria. Meglio all'inizio scrivere questo motore di rete per il normale processore Intel perché tutti possano usarlo, e poi ottimizzarlo per Kuda se ha senso. A proposito, è meglio creare il motore in modo che funzioni nel cloud. Non ho familiarità con il cloud computing. C'è qualcosa lì dentro?
Sono d'accordo, all'inizio devi fare un progetto senza CUDA. Ma ho un'osservazione per il post - non dovreste affilarlo solo per Intel, ma non dimenticarvi anche di AMD.
 
gpwr:
Perché preoccuparsi di un cuda in un progetto destinato a un uso generale? Alcuni utenti hanno un cuda, altri ne hanno uno diverso e altri ancora non hanno alcun cuda. Per esempio non ho cuda sul mio portatile al lavoro. Lo stesso codice di rete sarà molto diverso a seconda del numero di core del cuda e della memoria. Meglio all'inizio scrivere questo motore di rete per il normale processore Intel perché tutti possano usarlo, e poi ottimizzarlo per Kuda se ha senso. A proposito, è meglio creare il motore in modo che funzioni nel cloud. Non ho familiarità con il cloud computing. C'è da qualche parte?

MQ ha promesso il supporto per OpenCL in MQL5, non CUDA (solo schede grafiche di nVidia). OpenCL può essere eseguito su qualsiasi hardware che ha processori multi-core, questo include sia CPU che GPU (AMD e nVidia e intel). Quindi, un progetto che supporta i calcoli sia sulla CPU che sulla GPU funzionerà per tutti.

Poiché MQL5 supporterà OpenCL, significa che gli agenti cloud supporteranno il GPU computing.

 

Urain:

Non si può avere sempre ragione, è a questo che serve il progetto Open Source, a discutere, a dimostrare.

Ne ho bisogno?
 
joo:

Vorremmo quindi un consiglio da un esperto di GPU Computing. yu-sha e JavaDev, ow!

Interessato alle seguenti domande:

1. A quali aspetti si dovrebbe prestare attenzione in primo luogo quando si crea un progetto (o i suoi singoli moduli) su GPU per evitare la fastidiosa riprogettazione in futuro?

2. Quali sono i limiti di memoria per i core della GPU? È possibile, in linea di principio, mettere l'intero codice eseguibile su una storia separata eseguita in memoria (decine e centinaia di migliaia di barre)?

Finora domande così generali. Quelli più dettagliati, credo, saranno aggiunti più tardi.

I punti principali sono:

1) Le GPU sono necessarie solo per la formazione

2) Un aumento significativo delle prestazioni si ottiene con il calcolo parallelo dei valori dei neuroni in uno strato e, cosa più importante, con l'esecuzione simultanea di centinaia di reti.

Massima suddivisione del progetto in componenti autonomi - ecco cosa cercare

La memoria DDR sulla GPU è più che sufficiente per memorizzare la storia di centinaia di migliaia di barre

La memoria del nucleo è fortemente limitata (30-50Kbyte). La programmazione semplice risolve anche questo problema - ne vale la pena, poiché la memoria del chip funziona alla frequenza del nucleo e l'accesso ad essa costa 0 cicli di clock. Ci sono anche conflitti di banchi di memoria del kernel, ma si aggira anche quello.

C'è una cosa spiacevole nella caratteristica di Windows - i driver si resettano se una corsa dura >~ 5 secondi

Quindi, il massimo che possiamo ottenere è la formazione di 100-200 reti di ~100 neuroni per 100k barre di storia

Con questa configurazione (massima) otteniamo la velocità di ottimizzazione di ~ 20-30 esecuzioni al secondo su GTX 460 GPU

1...515253545556575859606162636465...100
Nuovo commento
Motivazione: