Link alla notizia: http://www.hwupgrade.it/news/skvideo/il-punto-di-vista-intel-su-cuda_25845.html

Pat Gelsinger prevede un futuro senza troppi successi per CUDA e in generale per le elaborazioni GPGPU non puramente x86

Click sul link per visualizzare la notizia.

Dichiarazione del tutto scontata... ;)

Alla intel sono solo Nvidiosi

Alla lntel hanno ragione per metà: CUDA tra due anni nessuno sentirà più parlare, ma

Un approccio di questo tipo da parte di Intel, del resto, non deve sorprendere: le architetture Larrabee saranno basate su core in grado di elaborare codice x86 in modo nativo. E' quindi illogico pensare che Intel possa promuovere l'utilizzo di linguaggi di programmazione più o meno customizzati per utilizzare una GPU per elaborazioni di calcolo parallelo.

... ci vorranno comunque linguaggi di programmazione specifici per la programmazione degli stream processor. E' illogico pensare che si possa usare un'approccio multithreading tradizionale per robe con 64+ unità di calcolo "da GPU".

a parte gli scherzi penso che le GPGPU "Tradizionali" di Ati ed Nvidia saranno usate solo per quelle particolari applicazioni che riescono a beneficiare al massimo di questa tecnologia... vedi il calcolo scientifico

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?

;-)

Niente coda di paglia ma solo un avvertimento che il futuro si trova in x86.
Cuda non salvera' Nvidia se Intel porta al completamento il progetto larrabee.
I prossimi 2-3 anni saranno veramente interessanti, sopratutto sul versante grafico con l'arrivo a grandi passi del ray tracing in realtime per i videogames.

Niente coda di paglia ma solo un avvertimento che il futuro si trova in x86.
Il passato e il presente, certamente. Ma sul futuro non mi sbilancerei.
Il punto di forza di Intel consiste nell'enorme massa di applicazioni e strumenti legati al suo set di istruzioni CISC. Ma non esiste una simile massa di software massicciamente parallelo basato su x86: dovranno inventare qualche estensione tipo "SSE5" per sfruttare numeri consistenti di core (diciamo da 32 in su). E per farlo il codice dovrà essere di tipo vettoriale, non multithreaded. A questo punto, dovendo reimplementare da zero adottando nuove librerie e perfino nuovi linguaggi, che vantaggio avreste scegliendo un set di istruzioni parzialmente basato su estensioni di estensioni di estensioni di un'architettura CISC di trent'anni fa? Piuttosto punterei su qualcosa di nuovo e pensato fin dal principio per il calcolo vettoriale.
Non ho idea di quanto CUDA sia aperto o chiuso, ma si sente fortemente l'esigenza di uno standard aperto e dubito che possa essere l'ennesima mutazione di x86 ad imporsi.

intel lancia ufficialmente il guanto di sfida ad nVIDIA, fra tre/cinque anni vedremo se nVIDIA chiude baracca e se ne ritorna a casa o se intel prende una bella batosta in ambito grafico.
Comunque vada, IMHO queste sfide "intelettuali" porteranno benefici nel ns. settore.

Il passato e il presente, certamente. Ma sul futuro non mi sbilancerei.
Il punto di forza di Intel consiste nell'enorme massa di applicazioni e strumenti legati al suo set di istruzioni CISC. Ma non esiste una simile massa di software massicciamente parallelo basato su x86: dovranno inventare qualche estensione tipo "SSE5" per sfruttare numeri consistenti di core (diciamo da 32 in su). E per farlo il codice dovrà essere di tipo vettoriale, non multithreaded. A questo punto, dovendo reimplementare da zero adottando nuove librerie e perfino nuovi linguaggi, che vantaggio avreste scegliendo un set di istruzioni parzialmente basato su estensioni di estensioni di estensioni di un'architettura CISC di trent'anni fa? Piuttosto punterei su qualcosa di nuovo e pensato fin dal principio per il calcolo vettoriale.
Non ho idea di quanto CUDA sia aperto o chiuso, ma si sente fortemente l'esigenza di uno standard aperto e dubito che possa essere l'ennesima mutazione di x86 ad imporsi.

Ti dice niente il progetto Larrabee ? :stordita:
Mamma mia, molti dormono e non si accorgono ancora che il gigante incombe. Il risveglio sara' devastante per Nvidia, un po' meno per ATI che e' gia' inglobata in AMD.

Guarda cosa dicono nei blog della Intel : http://blogs.intel.com/research/2008/06/unwelcome_advice.php


Increasingly, we are discussing how to scale performance to core counts that we aren’t yet shipping (but in some cases we’ve hinted heavily that we’re heading in this direction). Dozens, hundreds, and even thousands of cores are not unusual design points around which the conversations meander. Over time, I find that developers migrate their thinking from the first kind of discussion to the second.


Quando parlano di migliaia di core stanno facendo riferimento a core x86.
E dove le trovi migliaia di core x86 ? Sull'equivalente delle schede grafiche moderne.

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.
E se un giorno qualcuno creasse una architettura totalmente nuova e innovativa? Che farebbe Intel? La bloccherebbe?

Tornando in tema, credo che la soluzione migliore per lo sviluppo del calcolo tramite GPU sia in standard aperti e non su soluzioni proprietarie come CUDA.
In questo modo tutti, Nvidia, Ati, e la stessa Intel potrebbero implementare questo standard nei loro prodotti garantendo anche un più rapido adattamento dei software a quello standard.

E' impensabile che le softwarehouse sviluppino magari più versioni dello stesso software solo per adattarsi alle diverse soluzioni per il calcolo tramite GPU.

Imho la soluzione ideale è nel progetto aperto delle OpenCL portato avanti dal Kronos Group

Concordo OpenCL secondo me farà vedere grandi cose.

a proposito e su win? OpenCL niente???

Il problema + grosso di Nvidia che tutto cio che fa è "closed" , pensa esclusivamente al propio tornaconto ed è x questo che Cuda tra un paio di anni sparirà!!! (vedasi SLI)

L'open source da stimoli maggiori, vuoi mettere un linguaggio accessibile da tutti, dove tutti possono dare il propio contributo magari migliorandolo con il tempo.

ATI secondo me la spunterà, oltre ad avere un Hardware migliore, sta puntando tanto sull' open source

La filosofia di utilizzo del calcolo vettoriale per le applicazioni home credo sia quella di ottimizzare solo una piccolissima parte del codice (come si fa a volte con l'Assembly).
Mentre tutta l'applicazione principale viene gestita da normale codice x86, il nucleo più critico (es: codifica di un filmato,compressione file ecc..) potrà beneficiare di una potenza di calcolo spaventosa.

Se fosse così, la compatibilità con x86 sarebbe solo un'aspetto marginale poichè solo una piccola parte del progetto deve venire sviluppata da programmatori con una certa esperienza in cuda e date le ridotte dimensioni ed al conempo la criticità (in termini di tempo) del codice, credo non bisogni scendere ad alcun compromesso.

Di diversa concezione i processori Cell. In questo caso non c'è verso di semplificare le cose non avendo nessun x86 a supporto e quindi anche il codice meno critico dovrà essere sviluppato direttamente per questo processore, con notevole spreco di tempo per i programmatori abituati a x86

in quel lasso di tempo credo che se la cuccheranno TUTTE le università del mondo, così da avere "supercomputer casalinghi" a buon prezzo.

vedasi http://fastra.ua.ac.be/en/index.html

vuoi mettere la comodità?

E se ciò accadrà non credo che la tendenza sarà sullo scomparire.. Piuttosto probabilmente la forte richiesta costringerà nvidia a rendere il tutto più open.

comunque non programmo, quindi non so i risvolti tecnici. Ma se posso esprimere un' opinione da profano direi che 'sta CUDA per ora spacca! Ati non so bene se abbia fatto una roba simile, quindi non mi pronincio.

Ti dice niente il progetto Larrabee ? :stordita:
Mamma mia, molti dormono e non si accorgono ancora che il gigante incombe. Il risveglio sara' devastante per Nvidia, un po' meno per ATI che e' gia' inglobata in AMD.

Guarda cosa dicono nei blog della Intel : http://blogs.intel.com/research/2008/06/unwelcome_advice.php



Quando parlano di migliaia di core stanno facendo riferimento a core x86.
E dove le trovi migliaia di core x86 ? Sull'equivalente delle schede grafiche moderne.

vabbè migliaia :D ... ora che arriviamo a componenti per pc con migliaia di core "x86" anche solo di un qualche nuovo tipo molto "mini", dovranno passare credo anni ed anni se le dimensioni dei core larrabee sono anche solo di ordine di grandezza paragonabile a quello che ora si associa a core x86 ...

... chiaro se questi "core x86" che ha in mente intel saranno talmente diversi da quello che comunemente si pensa da essere di dimensioni invece paragonabili per esempio a quelle degli sp delle attuali gpu, i tempi saranno più brevi ...

intanto sarebbe interessante vedere all'opera un qualche prodotto "larrabee" anche con solo qualche decina di core, ma tuttora gli annunci uffciali mancano :(

Diciamo che ora nVidia ha qualcosa di concreto, e a quanto sembra Cuda sta prendendo piede molto velocemente soprattutto nel campo scientifico.
Intel ha "solo" il progetto Larrabbe, che uscirà fra 2 anni circa.
Per ora, con la sua architettura x86, già nei processori attuali (Dual-Quad Core) raramente si vedono tutti i core sfruttati, segno che programmarli non è alquanto semplice. Se poi passerrà a 100+ core come le gpu attuali, allora la difficoltà di programmazione può solo che aumentare.
Per quanto riguarda Amd, la vedo come a metà strada tra nVidia e Intel: il vantaggio principale rispetto ad Intel è che può anche lei gia contare su qualcosa di concreto, cioè le GPU Ati; svantaggio rispetto a nVidia, è invece che non pubbliccizza molto le sue tecnologie.

Ti dice niente il progetto Larrabee ? :stordita:
Mamma mia, molti dormono e non si accorgono ancora che il gigante incombe. Il risveglio sara' devastante per Nvidia, un po' meno per ATI che e' gia' inglobata in AMD.

Guarda cosa dicono nei blog della Intel : http://blogs.intel.com/research/2008/06/unwelcome_advice.php

Quando parlano di migliaia di core stanno facendo riferimento a core x86.
E dove le trovi migliaia di core x86 ? Sull'equivalente delle schede grafiche moderne.

In primis, dal lato multicore x86, AMD e' in abbondante vantaggio, come fa notare qualcuno sul blog da te citato. In altre parole sono, almeno per ora, l'ultima ruota del carro e cio' fa perdere credibilità alle loro dichiarazioni.
Secondariamente, per ora Intel non ha niente da mostrare mentre nVidia ed ATI vendono gia' i loro prodotti (e scusa se e' poco).
Ed infine integrare anche solo centinaia (figuriamoci migliaia poi) di core x86 del tipo che attualmente conosciamo in un unico processore e' pura fantascienza e lo rimarra' probabilmente per eoni. Naturalmente riprogettandoli e semplificandoli di molto sarebbe possibile ma in questo caso tutto il bel discorso su applicazioni/tradizione e vaneggiamenti vari perderebbe di significato (basse prestazioni, nuovo linguaggio e cosi' via).
Se Larrabee verra' realizzato sicuramente sara' un qualcosa di molto diverso dagli attuali x86. Il resto sono i soliti vaneggiamenti di marketing Intel.

Potrà essere una dichiarazione impopolare ma secondo me la pubblicità qua non c'entra.
E' una corsa al "vantaggioso", chi riesce a realizzare il prodotto migliore in termini di semplicità/prestazioni/costo la vince; in questo caso AMD è avvantaggiata perchè le nuove architetture GPU sono una bomba e costano la metà delle nVidia, inoltre ha scelto di puntare sull'openSource, il che equivale a costi di sviluppo ridotti in tempi decisamente accettabili (inoltre una documentazione aperta si diffonde più rapidamente ed in anticipo rispetto ad una chiusa.

La pubblicità di massa non serve ad un prodotto che tale non è, basta vedere quello che è successo con firestream e openCL. CUDA è sulla bocca di tutti da tempo, ma quando è saltato fuori il primo chart con le prestazioni di Firestream le attenzioni si sono mitigate. AMD in sordina ha piazzato la mina :)

Poi c'è da aggiungere un fattore non da poco: AMD e ATI sono in sinergia tra loro e con la comunità openSource; Intel invece, al posto di collaborare mette i bastoni tra le ruote nVidia, che a sua volta lavora su una piattaforma chiusa.

Almeno questo è il mio punto di vista, può essere che mi sbagli ma credo che Intel si senta troppo sicura dall'alto della sua posizione.

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.

Alla intel sono solo Nvidiosi

sicuro guarda....:asd:

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

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

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à)
:)

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 ;)

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

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.

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.

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!!!
:D