Il punto di vista Intel su CUDA

[mjordan]

Sarà anche un commento di parte, il suo. Il fatto è che non ha sbagliato una virgola nel ragionamento. Produrre software è difficile. Se per fare ogni cazzata bisogna imparare sempre 10 cose nuove, abbiamo finito. Ad un certo punto bisogna focalizzarsi sulla risoluzione dei problemi e non sempre e solo sugli strumenti che si usano.

[khelidan1980]

Originariamente inviato da Marclenders

Alla intel sono solo Nvidiosi

sicuro guarda....

[MiKeLezZ]

Se il buongiorno si vede dal mattino, a vedere i chipset con grafica integrata Intel dubito che AMD e NVIDIA abbiano di che preoccuparsi con Larrabbe.

Ma in particolare, se NVIDIA decide di aprire CUDA, e anche AMD entra nel consorzio, IMHO Intel non avrà chance per penetrare il mercato e dovrà fare come fece con i 64-bit di AMD: adattarsi a loro.

I prossimi anni saranno sicuramente interessanti. Chissà quando per una GCPU

[bollicina31]

bhò vedremo, anche perchè secondo mè anche Intel avrà bisogno di qualcosa di nuovo per scrivere i suoi "programmi"

[RedDrake]

Io programmo in diversi linguaggi,
quando si scrive un programma multithread
il numero di threads è un parametro!
quindi che i threads siano 2 o 200 non c'è alcuna differenza!!!
(se ho n cores istanzio n threads, ci penserà i sistema
operativo a smistare i threads sui cores liberi)
i controlli di cocorrenza ed i segnali fra i threads si
devono effettuare allo stesso modo.
Sul modello di programmazione vettoriale
invece la storia mi pare molto diversa,
lì i cores non vengono sfruttati istanziando threads
ma istanziando vettori o matrici che operano in modo intrinseco
sfruttando tutti i cores.
Vorrei provare, dopo l'estate, firestream di Ati
(se ci riesco faccio acquistare una scheda all'università)

[Mercuri0]

Originariamente inviato da RedDrake

Vorrei provare, dopo l'estate, firestream di Ati
(se ci riesco faccio acquistare una scheda all'università)

Per spippolare basta una 3870, l'SDK si può scaricare liberamente mi sa

[rockroll]

Ha detto RedDrake (#24):

il numero di threads è un parametro!
quindi che i threads siano 2 o 200 non c'è alcuna differenza!!!
(se ho n cores istanzio n threads, ci penserà i sistema
operativo a smistare i threads sui cores liberi)
i controlli di cocorrenza ed i segnali fra i threads si
devono effettuare allo stesso modo.
Sul modello di programmazione vettoriale
invece la storia mi pare molto diversa,
lì i cores non vengono sfruttati istanziando threads
ma istanziando vettori o matrici che operano in modo intrinseco
sfruttando tutti i cores.

Per amor di verità, e per far capire qualcosa di più, vediamo cosa si sarebbe dovuto dire:

Il # threads è un valore massimo corrispondente alle GPU disponibili su quell'HW, che quindi il Pgm dovrebbe testare per impostarlo.
Se sono un buon programmatore cerco tutti i parallelismi possibili e mi faccio un mazzo tanto, nell'eventualità di trovarmi in presenza di moltissime GPU e di volerle sfruttare al massimo; se so già a priori che le GPU sono poche e magari non sono un gran programmatore ovvero non sono molto dotato, non vado ad elucubrare stravolgimenti estremi del pgm originale per cercare di ottenere parallelismi particolari dove invece il processo sequenziale filava liscio come l'olio. Ma sopratuto, in stretta funziona della logica del problema trattato, può darsi benissimo che, per quanti sforzi faccia, riesca ad idividuare un numero esiguo di istanze parallelizzabili (se non nesuna), e magari per una percentuale di sovrapponibilità minima rispetto al totale dell'elaborazione.
I controlli di concorrenza ed i segnali (semafori di consenso) tra i vari threads contemporaneizzabili sono tecnicamente sempre dello stesso tipo, ma di quantità funzione del numero di istanze (sezioni contemporanee) individuate in quel punto: per ogni istanza ad inizio devo testare le condizioni di start, ed alla fine devo impostare le condizioni che le istanze successive dovranno testare per avere il consenso allo start. E' evidente che più istanze sto trattando e più c'e roba da testare ed impostare, e se sbaglio sono casini neri.
Il sistema operativo non ci può pensare autonomamente a parallelizzare le varie istanze, perchè non ne conosce la logica alla quale sono condizionate, può solo sotto mio "rilascio" di istanza attivare il relativo thread su una delle GPU ancora disponibili; e sta a me non superare il limite, conoscendo il valore max di # threads attivabili. Il linguaggio di programmazione mi può mettere a disposizione le istruzioni di rilascio delle istanze, e mi può semplificare la vita nel settaggio e nel test dei semafori di consenso, ma sarò io che dovrò spezzare il programmone originale in tante routines piò o meno grosse (istanze) vincolate tra loro dalle suddette funzioni semafori: si tratta cioè di un problema di schedulazione di n lavori concorrenti, con n <= #max.threads. Ed è solo nelle illusioni e nei sogni di Intel la possibilità di costruire una vera e propria intelligenza artificiale in grado di svolgere per me questo lavoro.
Quanto poi alle elaborazioni vettoriali, ovvero ai calcoli matriciali, questo è fattibilissimo e nemmeno troppo complesso da realizzare, sempre restando nell'ambito di matrici con numero n di elementi non superiore al famoso #max.threads. per ogni insieme di istanze parallele, ma la cosa si può applicare solo in presenza di n valori di input contemporanei il cui algoritmo di calcolo sia autonomo, ossia indipendente dal risultato degli altri calcoli contemporanei: agli n set di input viene applicato lo stesso algoritmo per ottenere gli n set di output. In questo caso il problema può essere opposto, ovvero sovrabbondanza di parallelismo disponibile, di gran lunga superiore al fasmoso #max.threads, per cui ci sarà il problema di eseguire calcoli matriciali successivi, fino ad esaurire il set di input; ma fortunatamente almeno in questo caso ci può pensare benissimo il S.O. a trattare il tutto a pacchetti, una matrice alla volta: il linguaggio di programmazione mi toglierà dall'incomodo di sezionare la matrice totale teorica in sottomatrici con #elementi <= #max.threads.

Non volevo fare il saputello, volevo solo dare un'idea sufficientemente comprensibile delle difficoltà che si incontrano a "lavorare bene" per trasfomare pgms nonothread in pgms multithread... e spero di esserci riuscito.

Bye - rockroll

[Mercuri0]

Originariamente inviato da DarKilleR

bhè forse è anche per questo motivo che nel GPGPU ATI è un pelo in vantaggio (non dico come publicità che CUDA ultimamente si legge anche nei muri dei cessi alle università)...
Però è un linguaggio OpenSource...e se non sbaglio si basa su X86 giusto?

Qualcuno può confermare quello che ho sentito?

La piattaforma di GPGPU di AMD è basata su una interfaccia di basso livello chiamata "CAL" (che non è l'equivalente di CUDA, che invece è un linguaggio di programmazione di alto livello). Non è x86.

AMD fornisce brook+ come linguaggio di programmazione. Brook+ è opensource e può generare codice per GPU e CPU, e con l'apposito back-end anche per CUDA (non so se adesso che c'è Folding@Home per nVidia, c'è anche il backend)

Ci sono anche altri middleware per il GPGPU, come RapidMind, che funziona su CUDA, CAL, x86 e Cell.

Originariamente inviato da OmbraShadow

Bah, onestamente nonmi piace molto sto ragionamento di Intel...è come se dicesse che il futuro dei pc sarà legato nei secoli dei secoli solo alla sua architettura x86.

Dove c'è x86, c'è lntel. Dove x86 non c'è, lntel non c'è.
(Itanium conta poco...)

lntel vuole mettere x86 dappertutto: nel calcolo ultraparallelo, nei telefonini (il prossimo Atom), nelle mutande firmate...

Per farlo conta sul fatto che l'architettura si possa estendere e che l'avanzato processo costruttivo di cui dispone sopperisca alle eventuali inefficienze rispetto alle architetture concorrenti.

[RedDrake]

Originariamente inviato da rockroll

Ha detto RedDrake (#24):

il numero di threads è un parametro!
quindi che i threads siano 2 o 200 non c'è alcuna differenza!!!
(se ho n cores istanzio n threads, ci penserà i sistema
operativo a smistare i threads sui cores liberi)
i controlli di cocorrenza ed i segnali fra i threads si
devono effettuare allo stesso modo.
Sul modello di programmazione vettoriale
invece la storia mi pare molto diversa,
lì i cores non vengono sfruttati istanziando threads
ma istanziando vettori o matrici che operano in modo intrinseco
sfruttando tutti i cores.

Per amor di verità, e per far capire qualcosa di più, vediamo cosa si sarebbe dovuto dire:

Il # threads è un valore massimo corrispondente alle GPU disponibili su quell'HW, che quindi il Pgm dovrebbe testare per impostarlo.
Se sono un buon programmatore cerco tutti i parallelismi possibili e mi faccio un mazzo tanto, nell'eventualità di trovarmi in presenza di moltissime GPU e di volerle sfruttare al massimo; se so già a priori che le GPU sono poche e magari non sono un gran programmatore ovvero non sono molto dotato, non vado ad elucubrare stravolgimenti estremi del pgm originale per cercare di ottenere parallelismi particolari dove invece il processo sequenziale filava liscio come l'olio. Ma sopratuto, in stretta funziona della logica del problema trattato, può darsi benissimo che, per quanti sforzi faccia, riesca ad idividuare un numero esiguo di istanze parallelizzabili (se non nesuna), e magari per una percentuale di sovrapponibilità minima rispetto al totale dell'elaborazione.
I controlli di concorrenza ed i segnali (semafori di consenso) tra i vari threads contemporaneizzabili sono tecnicamente sempre dello stesso tipo, ma di quantità funzione del numero di istanze (sezioni contemporanee) individuate in quel punto: per ogni istanza ad inizio devo testare le condizioni di start, ed alla fine devo impostare le condizioni che le istanze successive dovranno testare per avere il consenso allo start. E' evidente che più istanze sto trattando e più c'e roba da testare ed impostare, e se sbaglio sono casini neri.
Il sistema operativo non ci può pensare autonomamente a parallelizzare le varie istanze, perchè non ne conosce la logica alla quale sono condizionate, può solo sotto mio "rilascio" di istanza attivare il relativo thread su una delle GPU ancora disponibili; e sta a me non superare il limite, conoscendo il valore max di # threads attivabili. Il linguaggio di programmazione mi può mettere a disposizione le istruzioni di rilascio delle istanze, e mi può semplificare la vita nel settaggio e nel test dei semafori di consenso, ma sarò io che dovrò spezzare il programmone originale in tante routines piò o meno grosse (istanze) vincolate tra loro dalle suddette funzioni semafori: si tratta cioè di un problema di schedulazione di n lavori concorrenti, con n <= #max.threads. Ed è solo nelle illusioni e nei sogni di Intel la possibilità di costruire una vera e propria intelligenza artificiale in grado di svolgere per me questo lavoro.
Quanto poi alle elaborazioni vettoriali, ovvero ai calcoli matriciali, questo è fattibilissimo e nemmeno troppo complesso da realizzare, sempre restando nell'ambito di matrici con numero n di elementi non superiore al famoso #max.threads. per ogni insieme di istanze parallele, ma la cosa si può applicare solo in presenza di n valori di input contemporanei il cui algoritmo di calcolo sia autonomo, ossia indipendente dal risultato degli altri calcoli contemporanei: agli n set di input viene applicato lo stesso algoritmo per ottenere gli n set di output. In questo caso il problema può essere opposto, ovvero sovrabbondanza di parallelismo disponibile, di gran lunga superiore al fasmoso #max.threads, per cui ci sarà il problema di eseguire calcoli matriciali successivi, fino ad esaurire il set di input; ma fortunatamente almeno in questo caso ci può pensare benissimo il S.O. a trattare il tutto a pacchetti, una matrice alla volta: il linguaggio di programmazione mi toglierà dall'incomodo di sezionare la matrice totale teorica in sottomatrici con #elementi <= #max.threads.

Non volevo fare il saputello, volevo solo dare un'idea sufficientemente comprensibile delle difficoltà che si incontrano a "lavorare bene" per trasfomare pgms nonothread in pgms multithread... e spero di esserci riuscito.

Bye - rockroll

Ciao rockroll,
hai detto che
"Il # threads è un valore massimo corrispondente alle GPU disponibili su quell'HW, che quindi il Pgm dovrebbe testare per impostarlo. "
ma non sono d'accordo, per spiegare come funzionano i threads non serve tirare in ballo le GPU, basta limitarsi ad una CPU.
Ho parallelizzato un programma con i threads sotto linux,
per esempio su un core 2 se istanzio 128 threads guadagno
molto rispetto ad un singolo thread anche se i cores sono solo 2
(chiaro che non si guadagna rispetto a due threads).
Ovviamente il guadagno dipende dalla natura del problema,
questo tipo di parallelismo funziona molto bene se il problema può essere
diviso in sottounità indipendenti.
Comunque a programmare in c++ con i threads
mi sono divertito un casino!!!