Possibile ulteriore ritardo per le CPU Intel Broadwell

[calabar]

Originariamente inviato da cdimauro

Per cui, se hai link e prove... ben vengano.

Continuo a non capire questo passo... se siamo d'accordo, che bisogno hai di altri link?

Originariamente inviato da marchigiano

credo intenda che il SHP è inferiore al SOI ma non al HP, poi magari mi sbaglio non so...

Immagino di si. Evidentemente anche il processo SHP non è ideale per le CPU, AMD si è accontentata per poter avere un processo abbastanza economico da rendere profittevoli le APU.

Originariamente inviato da marchigiano

per le conversioni di alta qualità la cpu rimane la sola via purtroppo. e anche per parecchie ore, tipo 20 ore di una cpu di fascia medio-alta

É un problema di software, non di risorsa utilizzata.
Oggi semplicemente non ci sono software che permettono di fare conversioni di alta qualità, motivo per cui in quei casi sei costretto a ricorrere alle più lente CPU.
Questo in parte è dovuto al fatto che le versioni GPU sono più giovani, in parte alla difficoltà di programmare per GPU (per esempio era difficile il debug), in parte per i limiti di questo hardware (limiti che pian piano stanno eliminando, per esempio le APU ora consentono l'accesso diretto alla memoria principale).
Dai tempo al tempo, queste cose matureranno.

Originariamente inviato da PaulGuru

Ok posso anche farlo questo ma su ogni cosa c'è una gerarchia.
Chi si compra un bene di lusso per quanto limitato sia il mercato ha sempre maggiore considerazione e un assistenza molto superiore [...]

Semplicemente chi compra un bene di lusso lo paga talmente tanto che nel prezzo ti includono anche un'assistenza migliore che ti faccia percepire che la cifra che hai sborsato sia giustificata. In realtà non ti regalano nulla, hai pagato tutto.
Ma questo non significa affatto maggiore considerazione. Fai parte semplicemente di una fascia di mercato che spende di più, e a questa sono associati servizi "premium" che compri con il prodotto.
Ma per loro vale sicuramente di più la clientela mainstream di quella enthusiast (e se tu hai percepito il contrario, significa che hanno fatto un bel lavoro di marketing ), perchè sono loro che tengono in piedi la baracca.

[cdimauro]

Originariamente inviato da calabar

Continuo a non capire questo passo... se siamo d'accordo, che bisogno hai di altri link?

Oggi è la serata dei fraintendimenti. Scusami. Mi riferivo all'altro thread.

É un problema di software, non di risorsa utilizzata.
Oggi semplicemente non ci sono software che permettono di fare conversioni di alta qualità, motivo per cui in quei casi sei costretto a ricorrere alle più lente CPU.
Questo in parte è dovuto al fatto che le versioni GPU sono più giovani, in parte alla difficoltà di programmare per GPU (per esempio era difficile il debug), in parte per i limiti di questo hardware (limiti che pian piano stanno eliminando, per esempio le APU ora consentono l'accesso diretto alla memoria principale).
Dai tempo al tempo, queste cose matureranno.

Non è così semplice. Ci sono cose che le GPU non riescono ancora a fare bene come le CPU.

Ad esempio, quando ho realizzato un decoder JPEG 2000 per STMicroelectronics la fase di decodifica aritmetica era particolarmente onerosa e più pesante di quella della trasformata wavelet. La decodifica aritmetica è un algoritmo che si sposa bene con la natura general purpose di una CPU, che gestisce agevolmente test di bit, confronti interi, table look-up, e salti condizionati, mentre la GPU soffre per questo tipo di calcoli (ma, al contrario, è messa molto bene per la trasformata wavelet; idem per le unità SIMD, ovviamente).

Nello specifico non conosco il funzionamento degli algoritmi video di cui si parlava, ma a naso direi che dovrebbero esserci situazioni simili.

[CrapaDiLegno]

Premettendo che è un piacere il fatto che mi abbia risposto, trovo comunque parte dei tuoi commenti abbastanza lacunosi.

Originariamente inviato da cdimauro

E' un problema che riguarda tutte le fonderie, causa l'approssimarsi dei limiti del silicio.

Sì, ma le altre fonderie non vivono esclusivamente per il vantaggio che hanno rispetto alla concorrenza. Intel sì, e mentre le altre possono permettersi di aggiornarsi con comodità (persino permettendosi qualche nodo solo per usi specifici), Intel non può.
Il fatto che TMSC si sia potuta permettere un 20nm solo per SoC da solo la dice lunga su quanto sia redditizio il mercato dei SoC. Il fatto che Intel cerchi clienti per riempire le su fonderie la dice lunga su quanto in realtà le stiano costando, o meglio, quanto i guadagni non siano quelli preventivati rispetto ai costi di ammortizzazione necessari.

Originariamente inviato da cdimauro

Intel possedeva già una divisione ARM, che sfornò ottimi prodotti; poi la cedette alla Marvell. Dopo qualche tempo presentò gli Atom. Per cui credo che il tutto facesse parte di una strategia a lungo termine.

Scusami, ma poco conta quello che aveva Intel al tempo in cui ARM faceva processori per calcolatrici evolute.
Intel aveva in mano una tecnologia che sapeva benissimo essere migliore della propria, ma non essendo la propria ha semplicemente deciso di non cercare di darle vantaggio iniziando un processo di ottimizzazione e costruzioni con processi produttivi che nessun latro poteva (e può) permettersi.
Il risultato è solo stato un leggero ritardo sui tempi di maturazione dell'architettura ARM che ha preso il largo e oggi pure un colosso come Intel fa fatica ad arginare.

Originariamente inviato da cdimauro

Il quadro non è completo. Intel è entrata nel mondo del mobile (tablet principalmente, e phablet) con Atom, e di recente anche in quello embedded con Quark.

Quindi è vero anche il contrario: Intel sta pestando i piedi ad ARM entrando in quello che era il suo settore dominante.

Inoltre è entrata anche nel mercato HPC/GPGPU-computing con Xeon Phi (che è nato dalle ceneri di Larrabee).

Dunque non è che stia giocando esclusivamente in difesa; sta cercando, anzi, di espandere il suo business verso altri mercati.

Dai, non scadiamo nell'evangelizzazione.
Intel è sempre stata nel mercato embedded. Con scarsi risultati. D'altronde, come con ARM, è difficile competere in un mercato dove conta molto l'efficienza e il basso consumo (il raffreddamento passivo è quasi d'obbligo).
PowerPC, NEC, Hitachi (ora entrambe Renesas), MIPS e ARM e FPGA sono le architetture che normalmente si usano in campo industriale. Quark non farà differenza. Intel non riuscirà mai a vendere un chip allo steso prezzo delle altre architetture. Andrà bene là dove è sempre andata, ovvero dove contano più le performance e ci si può permettere meno limitazioni. Una nicchia nella nicchia.

L'ingresso di Intel nel mondo mobile è frutto solo di sovvenzioni. Nessuno, a parte quelli che sono stati pagati, ha interesse ad usare l'HW di Intel. Mentre mi sembra che ci sia una fila tremenda per gli ultimi OC di Qualcomm (vedi il discorso di prima sul PP a 20nm solo per SoC). Chiediti il perché. Se Intel desse anche a me 500 milioni per fare un telefono con un Atom dentro correrei a cercare la scatola dove infilare tutto. Ma è ovvio che appena Intel molla la pressione sul tasto "sovvenzioni" il motore (cioè l'interesse) si spegnerà da solo. Intel = Windows. Se fai un tablet con Windows 8 allora ci sta un Intel dentro. Altrimenti un x86 con tutti i suoi problemi non serve a nessuno. Vedi iOS e Android che bene hanno dimostrato la cosa.

Nel mondo HPC, sì La Xeon Phi fa ottimi numeri, ma stiamo sempre parlando di qualcosa realizzato con un PP di vantaggio rispetto alla concorrenza, che nonostante quello detiene comunque la migliore efficienza di GFlops/W. E con Maxell la cosa dovrebbe essere peggio per Intel, anche se Maxwell è sempre fatto con lo stesso PP.
D'altronde fosse stata "avanti" in questo campo il mercato HPC l'avrebbe conquistato lei a mani basse. Invece si trova a infilarsi momentaneamente nei varchi quando la concorrenza ha problemi di processo produttivo. Ci fossero oggi 20nm per GPU vedremmo dove starebbe Intel con le sue Xeon Phi fatte da vetusti core x86. Poi un giorno mi spiegherai a che serve usare i core x86 in un sistema che serve da coprocessore e basta quando in verità ci si potrebbe infilare qualsiasi cosa (pure una serie di Cell di IBM).
Insomma, stiamo continuamente ribadendo che senza PP di vantaggio Intel sarebbe già scomparsa o ridimensionata da un bel pezzo.

Originariamente inviato da cdimauro

Non è proprio così, e l'ho scritto in un pezzo più di 4 anni e mezzo fa sulla questione: dipende tutto dai numeri in gioco.

Se hai un chip costituito da pochi transistor, la cosiddetta x86-tax ha il suo peso, senz'altro; non è una cosa che puoi eliminare. Ma quando hai un core costituito da centinaia di milioni di transistor, se non addirittura miliardi com'è ormai diventato usuale nell'ultimo periodo, il suo peso diventa trascurabile.
[...]

In un'altra serie di articoli ho affrontato anche un'analisi di tutti gli altri aspetti "legacy" di x86 (e x64), che hanno un ruolo nettamente minore (IMO è il decoder l'elemento in assoluto di maggior peso).

Puoi studiare tutti i numeri e fare tutte le simulazioni che vuoi, ma i fatti sono diversi. L'architettura x86 non è solo mangiatrice di transistor (e watt), ma è anche una vergogna dal punto di vista dello sfruttamento della memoria. Con quei 4 registri in croce mai ampliati per davvero, perdendo pure la chance dei 64bit, l'accesso alle cache e alla RAM è continuo. E servono cache enormi per tenere le pipeline alimentate.
Il Motorola 68000 ai tempi già dava la paga agli x86 solo per l'efficienza che poteva godere con l'uso di 16 registri e una memoria flat, invece dell'accrocchio made in Intel. Non ci vuole molto a fare delle architetture migliori di quelle x86: basta pensarle bene fin a subito. L'x86 non lo è stata, e infatti è più un mostro Frankenstein completamente rifatto da plastiche su plastiche che una bella donna naturale.

Originariamente inviato da cdimauro

Non mi pare che sia così. Non vende abbastanza, questo sì, ma vende e ci sono aziende come Samsung o Asus che si appoggiano a Intel per soluzioni mobile più "high-end". Ad esempio l'altro ieri hanno regalato a mio figlio un Fonepad 7, e mia figlia mi ha fatto notare il marchio "Intel inside". E' stata una piacevole sorpresa: qualcosa si muove...

Vedi sopra, si muovono le sovvenzioni di Intel per cercare di trovare spazio dopo 4 anni di continui flop uno dietro l'altro. Se non facesse così sarebbe un altro anno in cui nessuno si accorge che Intel esiste nel campo mobile. Sta tentando il tutto per tutto. Se non sfonda (come credo non farà), il business mobile è perso (gli anni futuri non crescerà più come quelli passati e ormai i giochi sono fatti con produttori che sfornano SoC ARM più che sufficienti per smarphone e tablet a prezzi irrisori che Intel non può raggiungere nemmeno se divide per dieci il suo SOC).

Originariamente inviato da cdimauro

Indubbiamente, ma sono mercati che non spariranno. Quello HPC, anzi, è in aumento. Idem per le soluzioni data center. Quello desktop ha un declino fisiologico, ma il peggio IMO è passato, perché il mercato dei tablet si sta saturando.

Inoltre credo che per il futuro l'elemento su cui si punterà maggiormente l'attenzione sarà rappresentato dalle cosiddette soluzioni 2-in-1: notebook/netbook che funge anche da tablet. Il tutto con Windows che gira, col quale ritrovi gli stessi programmi a cui sei abituato.
Il tablet è comodo, ma non puoi farci molto. Il notebook è potente e ci girano i programmi che usi normalmente, ma è scomodo. Una soluzione che permetta entrambe le cose, se venduta a prezzi abbordabili, è possibile che polarizzi l'attenzione degli utenti (che si possono pure scocciare di avere più prodotti per fare cose simili).

In tal caso gli equilibri potrebbero nuovamente cambiare, e riportare alla ribalta Intel, e pure Microsoft. E' uno scenario da non sottovalutare.

E' uno scenario un po' nostalgico. La gente non vuole Windows ovunque. La gente vuole fare le cose nel modo più facile possibile. E questo non significa avere un tablet che pesa 1 kG perché la batteria deve essere grande per garantire una autonomia decente da portarsi sempre appresso e lo schermo è lo stesso che si usa in ufficio (che non può essere un 7" se si vuole davvero lavorare).
E abbiamo dimenticato l'evoluzione che sta avendo il cloud? Io oggi leggo la posta di Google sul mega PC con il mega monitor attualmente in uso, sul tablet e sullo smartphone. E accedo liberamente ai miei dati con Dropbox o Google Drive. Mi serve un processore Intel per farlo? No. Perché se esistono alternative che offrono strumenti migliori per un determinato uso, che me ne frega di avere x86 (= compatibilità con Windows)?

Originariamente inviato da cdimauro

La mia opinione è che al momento Intel non includa componenti comparabili (per prestazioni in rapporto al silicio richiesto) a quelle che sono presenti nelle soluzioni ARM, che possono contare su GPU, video decoder e DSP audio più ottimizzati. Questo è anche uno dei motivi per cui ha adottato le GPU di PowerVR per alcune declinazioni di Atom.

Sarebbe interessante valutare l'impatto dei soli core avendo componenti comparabili per prestazioni/die, per capire quanto possa incidere la suddetta x86-tax, ma al momento non è possibile, e i SoC vanno valutati "as is".

Baytrail non mi sembra che abbia chip esterni, fatta eccezione per il modulo LTE. Come tanti produttori che montano ARM.

Forse no hai compreso che non serve a nulla un confronto transistor per transistor tra i core per vedere chi ce l'ha più lungo qui o lì. Quello che conta sono due fattori: la potenza di calcolo dei processori ARM oggi è sufficiente per soddisfare l'utenza con l'uso di dispositivi che io definisco "passivi". Cioè quelli che non sono usati per creare contenuti. Visto che la maggior parte dell'utenza consuma contenuti invece di crearli (a parte i post sui forum e su FaceBook, ma per quello ARM basta e avanza), direi che la strada di Intel per far pesare la sua maggiore potenza di calcolo è molto in salita. Sopratutto perché, se l'efficienza fosse la stessa questo aumento di potenza di calcolo equivale ad una diminuzione dell'autonomia del dispositivo. Ma già in efficienza siamo ben distanti a parità di processo produttivo.
Il secondo fattore sono i costi: i processi produttivi di vantaggio di Intel le permettono più o meno di pareggiare sul lato efficienza, ma non su quello costi. A parità di area Intel il SoC di Intel costa quasi il doppio. Va 2 volte di più. Boh, forse, ma non è quello che l'utenza chiede. In un mercato che vuole i prezzi in calo (proprio perché si sta saturando vince chi offre a meno, non chi offre di più) un euro in più o in meno sulla BOM fa la differenza.

Originariamente inviato da cdimauro

Non mi pare che sia così, perché TSMC quanto potrà guadagnare da SoC ARM che vengono venduti a poco prezzo? Sì rifarà sulla quantità e questo è sicuramente importante, ma Intel i suoi processori non li svende. D'altra parte non c'è soltanto il costo di acquisto da considerare, ma anche le prestazioni sono importanti e hanno sempre più peso; non a caso c'è la corsa ai core, coi produttori di SoC ARM che fanno a gara a chi ce l'ha più lungo, quando Intel offre ottime prestazioni pur con un numero di core nettamente inferiore...

Intel ha altre carte da potersi giocare senza svenarsi. Altre arriveranno in futuro, come suo solito.

Sono soluzioni diverse per risolvere sostanzialmente gli stessi problemi, con pregi e difetti di ognuna. Starà poi ai produttori di dispositivi valutare quale meglio si adatta per il propri obiettivi.

Per i guadagni di TMSC vedi inizio post: ha creato un PP solo per SoC. Con la felicità estrema di nvidia e AMD. Ma questo semplicemente significa che quel mercato fa guadagnare parecchio (che sia per volumi o costi poco importa).
Intel non ha molte altre carte da giocarsi se non intervenendo sui prezzi per cercare di dare un lancio ai suoi prodotti che nessuno sa nemmeno esistere nel mercato mobile. Cosa altro può fare se non ridurre ulteriormente il transistor? Certo che però le costerò di più, e quindi le sovvenzioni dovranno essere pesanti.

Forse ti è sfuggito che il mercato è radicalmente cambiato: con la semplicità e il facile adattamento dell'architettura ARM progettarsi e realizzare un chip è alla portata di moltissimi. Moltissimi che possono permettersi di non dipendere da un produttore che fa chip monolitici da costi spropositati, possono farselo in casa come vogliono (bilanciando CPU o GPU cme megliono credono per il dispositivo che hanno in mente) e guadagnarci sopra molto di più che rivendendo un chip Intel. Oppure si possono rivolgere a un progettista cinese (come MediaTek per esempio) e arrivare sul mercato con un dispositivo che costa molto meno di quello già sovvenzionato da Intel.
Non c'è più la catena Windows che lega verso i micro Intel. Nel mobile non servono mille mila GFlop (e pure la questione degli octa core ARM sono una buffonata che presto spero evaporerà). Non si possono avere memorie da mille mila GHz per riuscire ad alimentare CPU che non sanno dove mettere i dati.
E inoltre non è più Intel contro uno o l'altro o l'altro, ovvero un elefante che abbatte come birilli gli scoiattoli che la affrontano da soli uno alla volta, o uno squalo che si mangia i tonni che osano sfiorarlo.
Intel è rimasta lo squalo di prima, ma ora intorno ci sono una miriade di piranha, ovvero tutti quelli che adottano in un modo o in un altro, persino sviluppandola in proprio, l'architettura ARM. Per quanti possa riuscire a mangiarsene, anche questi riusciranno a infliggere dei dolorosi morsi e con il tempo a contenerlo.
Questa volta le risorse degli altri non sono dispersi in mille rivoli, ma confluiscono tutti nella stessa pentola, quella delle fonderie terze che permette loro di aggiornarsi più velocemente (se aspettavano AMD per farlo avrebbero smesso da tempo di cercare di rincorrere Intel e sarebbero rimasti con processi produttivi economici utili per la maggior parte dell'elettronica non high speed...).

Originariamente inviato da cdimauro

Non ho capito cosa intendi con la perdita della retrocompatibilità, della faccia, e della parte finale della tua ultima frase. Potresti essere un po' più chiaro, cortesemente? Grazie.

Intendo che se non sfonda con Atom che è x86 based, o rinuncia al mobile o deve cambiare architettura nettamente. Il che vuol dire che perde la retrocompatibilità con il mondo x86 (e Windows) e si mette sulla linea di partenza a livello zero come lo sono gli altri, da ARM a MIPS. E perderebbe la faccia visto che sono anni che cerca di convincere in tutti i modi gli investitori che la sua è l'architettura migliore per qualsiasi cosa, dopo aver venduto la divisione ARM, riciclato il fallimento di Larrabee in un progetto HPC (e ci si chiede cosa abbiano in comune le due cose per far in modo che Intel dichiarasse che Larrabee sarebbe stata la migliore GPU mai creata, giusto per evidenziare come spesso il marketing nasconda ben altre verità.) e aver creato un processore a basso consumo orribile come l'Atom e non essere stata capace in 6 anni a renderlo appetibile per nessuno.

Ora coccolo un po' questo i7 che altrimenti dopo tutta questa critica ad Intel finisce per rompersi solo per dispetto

[carlottoIIx6]

Originariamente inviato da cdimauro

Oggi è la serata dei fraintendimenti. Scusami. Mi riferivo all'altro thread.

Non è così semplice. Ci sono cose che le GPU non riescono ancora a fare bene come le CPU.

Ad esempio, quando ho realizzato un decoder JPEG 2000 per STMicroelectronics la fase di decodifica aritmetica era particolarmente onerosa e più pesante di quella della trasformata wavelet. La decodifica aritmetica è un algoritmo che si sposa bene con la natura general purpose di una CPU, che gestisce agevolmente test di bit, confronti interi, table look-up, e salti condizionati, mentre la GPU soffre per questo tipo di calcoli (ma, al contrario, è messa molto bene per la trasformata wavelet; idem per le unità SIMD, ovviamente).

Nello specifico non conosco il funzionamento degli algoritmi video di cui si parlava, ma a naso direi che dovrebbero esserci situazioni simili.

è proprio qui il vantaggio di hsa, che non è solo gpu, ma cpu e gpu sullo stesso livello con huma e hQ, il sofware sceglie quale unità utilizzare che lo fa prima.
edit
una chicca
http://www.inpai.com.cn/doc/hard/197966.htm
programma video chat hsa con kaveri, fino a 70 video chat contemporanee

[Cappej]

Originariamente inviato da PaulGuru

Classico +3-5% di prestazioni la cui novità più grande sarà quella Iris Pro che verrà portata anche su desktop, ma di cui non frega nulla a nessuno. L'unica forse cosa che può valer la pena di prendere in considerazione è verificare se l'HIS sarà di nuovo saldato o ancora con la pasta del capitano.

ciao
... sono rimasto un po' indietro con i PC... cosa significa esattamente quello che hai scritto?
Pura curiosità.
Grazie

[Littlesnitch]

Originariamente inviato da Cappej

ciao
... sono rimasto un po' indietro con i PC... cosa significa esattamente quello che hai scritto?
Pura curiosità.
Grazie

Che ci sarà il classico aumento di prestazioni del 3-5%, che ci sarà la Iris Pro e che si spera il coperchio della CPU venga saldato come in passato e non come con gli IB e Haswell dove viene messo con della pasta del e se vuoi avere un OC con temp normali devi fargli lo scalpo. Motivo per cui mi tengo il mio SB che a 4.8Ghz ad aria sta a 70 gradi.

[calabar]

Originariamente inviato da cdimauro

Oggi è la serata dei fraintendimenti. Scusami. Mi riferivo all'altro thread.

Eheh hai ragione, non riusciamo a capirci.

Riguardo all'uso della GPU per la codifica/decodifica video, i vantaggi naturalmente stanno proprio nel portare su GPU ciò che su GPU viene calcolato con maggiore efficienza.
Le nuove tecnologie stanno puntando proprio a questo: non una GPU che esegue tutto, ma una GPU che è possibile richiamare come una qualsiasi altra risorsa interna di calcolo (un cluster int, una fpu...) per poter dare ad essa in pasto quello per cui è più efficiente.
Questo potrà permettere di spostare su GPU quelle applicazioni particolarmente gravose per la CPU che oggi ci fanno sentire la necessità di CPU più potenti. Il resto rimarrà su CPU, ma una CPU con un carico di lavoro alleggerito e che esegue calcoli a lei congegnali.

Si tratta naturalmente di teoria, fino a quando non viene concretamente applicata. Però la strada tracciata è quella.

[PaulGuru]

Originariamente inviato da carlottoIIx6

edit
una chicca
http://www.inpai.com.cn/doc/hard/197966.htm
programma video chat hsa con kaveri, fino a 70 video chat contemporanee

Roba utile vedo.

[CarmackDocet]

...basta che le fanno fluxless

[CrapaDiLegno]

Originariamente inviato da calabar

Eheh hai ragione, non riusciamo a capirci.

Riguardo all'uso della GPU per la codifica/decodifica video, i vantaggi naturalmente stanno proprio nel portare su GPU ciò che su GPU viene calcolato con maggiore efficienza.
Le nuove tecnologie stanno puntando proprio a questo: non una GPU che esegue tutto, ma una GPU che è possibile richiamare come una qualsiasi altra risorsa interna di calcolo (un cluster int, una fpu...) per poter dare ad essa in pasto quello per cui è più efficiente.
Questo potrà permettere di spostare su GPU quelle applicazioni particolarmente gravose per la CPU che oggi ci fanno sentire la necessità di CPU più potenti. Il resto rimarrà su CPU, ma una CPU con un carico di lavoro alleggerito e che esegue calcoli a lei congegnali.

Si tratta naturalmente di teoria, fino a quando non viene concretamente applicata. Però la strada tracciata è quella.

Il fatto è che usando la GPU per quel particolare algoritmo sei più efficiente della CPU ma molto meno di un HW fatto ad hoc. Pensa per esempio al QuickSync di Intel che riesce a battere qualsiasi GPU nella codifica.
l'HSA vero prevederebbe di avere a disposizione diversi componenti extra CPU da usare un maniera "intelligente" a seconda della maggiore efficienza per questo o per quel tipo di lavoro.
Come detto precedentemente, avere una sistema di ALU general purpose, ma altamente limitate come quelle delle GPU da usare come coprocessore per l'acclerazione di una serie di algoritmi generici secondo me non porta da nessuna parte. Tanto è che di algoritmi che si adattano alla super parallelizzazione richiesta dalle architetture GPU si contano sulle dita di una mano.

[calabar]

Originariamente inviato da CrapaDiLegno

Il fatto è che usando la GPU per quel particolare algoritmo sei più efficiente della CPU ma molto meno di un HW fatto ad hoc. Pensa per esempio al QuickSync di Intel che riesce a battere qualsiasi GPU nella codifica.

Il problema dell'hardware ad hoc è che non è adattabile.

Quicksync va bene per per fare delle conversioni veloci senza stressarsi molto, ma è assolutamente inadeguato per fare conversioni di qualità. Se ne parlava prima.

In fin dei conti dipende dalle esigenze.
Quicksync non è più veloce di una GPU, è più efficiente. Questo perchè non ha senso dedicare un hardware paragonabile a quello di una GPU ad una singola funzione, se non in situazioni particolari.
Se devo quindi fare conversioni di qualità, quicksync non mi serve a nulla, posso farle con CPU+GPU in tempi anche minori e con risultati superiori. Certo, consumo molto di più, è il prezzo da pagare per l'uso di un hardware general purpose, ma non sempre questo fattore è importante.

La logica fissa non potrà mai evolversi con i nuovi algoritmi, non potrà mai uscire dalle funzionalità per cui è stata creata. Se domani tutti codificano con un nuovo algoritmo, il chip ah hoc lo puoi anche cestinare. Se qualcuno tira fuori una matrice custom particolarmente efficiente o adatta al tipo di source da codificare, con la logica fissa non puoi utilizzarla.

La GPU può essere insomma un'ottima risorsa hardware per una serie di compiti (che non sono così pochi) per i quali useresti altrimenti una CPU più lenta e meno efficiente.
Del resto, a differenza di un hardware dedicato, la GPU fa comunque parte del nostro computer, tanto vale utilizzarla a dovere.

[MiKeLezZ]

Originariamente inviato da calabar

Quicksync va bene per per fare delle conversioni veloci senza stressarsi molto, ma è assolutamente inadeguato per fare conversioni di qualità. Se ne parlava prima.

Non se ne parlava, è stato affermato senza alcuna motivazione.

Ora, tolti i programmini gratuiti limitati per ovvi motivi (in HandBrake è stata Intel stessa che ha fornito la demo di come usare QS e gli sviluppatori non l'hanno integrata in funzionalità), spiegami perché se uso Mediaconcept Reference che ha il supporto QS dovrei fare delle cattive conversioni abilitando tale funzionalità:

Bit rate control (CBR, VBR, CQP).
Selectable profiles up to High Profile.
Selectable levels up to Level 5.1.
Bit rate support up to Level 5.1 restriction (288 Mbps).
Strict HRD restrictions compliance.
Configurable GOP structure (I, P and B frames in different combinations).
Configurable motion estimation (number of reference frames).
Adaptive GOP structure.
Configurable number of slices.

Fermo restando che la CPU è comunque disponibile per i sottoprocessi di compressione che beneficiano meno dell'uso della GPU. Spiegami, in linea ancora più generale, quale è il problema nell'avere un coprocessore in virgola mobile capace di sostituire la CPU nei compiti in cui tale architettura mostra le maggiori potenzialità (domanda retorica se sai in cosa consistono effettivamente le SSE e sei a conoscenza di quanto siano oramai fondamentali per la maggior parte dei programmi in uso).

[calabar]

Originariamente inviato da MiKeLezZ

Non se ne parlava, è stato affermato senza alcuna motivazione. [...]

Affermato si, ma non senza motivazione.
Le possibilità che ti offrono i parametri che hai elencato sono molto lontane da quelle che attualmente un prodotto serio di encoding su CPU può offrirti. Se hai frequentato qualche comunità in cui si discute di ripping, dovresti esserne ben conscio.

Originariamente inviato da MiKeLezZ

Fermo restando che la CPU è comunque disponibile per i sottoprocessi di compressione che beneficiano meno dell'uso della GPU. Spiegami, in linea ancora più generale, quale è il problema nell'avere un coprocessore in virgola mobile capace di sostituire la CPU nei compiti in cui tale architettura mostra le maggiori potenzialità (domanda retorica se sai in cosa consistono effettivamente le SSE e sei a conoscenza di quanto siano oramai fondamentali per la maggior parte dei programmi in uso).

Non mi pare di aver mai affermato il contrario.
Qui si parla di sfruttare le risorse hardware presenti nel computer, e la GPU è una di queste. Anche la fpu integrata in pressoché tutti i processori attuali è un coprocessore (e le SSE che citi girano appunto sulla fpu, come le 3Dnow prima di loro).
Ma sono comunque unità utilizzabili per il calcolo generico, a differenza di un hardware fisso, che ha senso solo per funzionalità stabili e di uso massivo (per esempio i decoder MPEG e H264 integrati, che vengono ampiamente sfruttati).

[CrapaDiLegno]

Originariamente inviato da calabar

Il problema dell'hardware ad hoc è che non è adattabile.

Quicksync va bene per per fare delle conversioni veloci senza stressarsi molto, ma è assolutamente inadeguato per fare conversioni di qualità. Se ne parlava prima.

In fin dei conti dipende dalle esigenze.
Quicksync non è più veloce di una GPU, è più efficiente. Questo perchè non ha senso dedicare un hardware paragonabile a quello di una GPU ad una singola funzione, se non in situazioni particolari.
Se devo quindi fare conversioni di qualità, quicksync non mi serve a nulla, posso farle con CPU+GPU in tempi anche minori e con risultati superiori. Certo, consumo molto di più, è il prezzo da pagare per l'uso di un hardware general purpose, ma non sempre questo fattore è importante.

La logica fissa non potrà mai evolversi con i nuovi algoritmi, non potrà mai uscire dalle funzionalità per cui è stata creata. Se domani tutti codificano con un nuovo algoritmo, il chip ah hoc lo puoi anche cestinare. Se qualcuno tira fuori una matrice custom particolarmente efficiente o adatta al tipo di source da codificare, con la logica fissa non puoi utilizzarla.

La GPU può essere insomma un'ottima risorsa hardware per una serie di compiti (che non sono così pochi) per i quali useresti altrimenti una CPU più lenta e meno efficiente.
Del resto, a differenza di un hardware dedicato, la GPU fa comunque parte del nostro computer, tanto vale utilizzarla a dovere.

Quello che dici è vero, ma si parla di codifica di video, e non nasce un algoritmo di compressione alla settimana.
Infatti i decoder nelle VGA sono altrettanto a funzione fissa e permettono di decodificare i formati più comuni e più richiedenti potenza computazionale.
Una unità che permetter per esempio di calcolare la FFT in tempi rapidissimi con buona precisione sarebbe già un bel blocco base su cui realizzare quasi tutti i codec/decoder. In quel caso potresti farti il tuo algoritmo personalizzato con buona efficienza senza dover scomodare 1000 e rotti ALU general purpose.

Come altro esempio puoi prendere le unità ad-hoc ora inserirte in quasi tutte le CPU che fanno la de/crittazione. Non c'è GPU che possa fare lo stesso lavoro con la stessa efficienza (e latenza).

D'altronde, casi di calcolo scientifico a parte, gli algoritmi pesanti usati in campo consumer sono poi limitati a poche cose: video/audio/crittazione/compressione. L'audio sono decenni che ha il suo coprocessore esterno (dai tempi del Commodore 64). Per gli altri c'è una questione di opportunità. Anche il video sono anni che viene accelerato in decodifica. Per la codifica c'è da tenere in considerazione che chi ne ha veramente bisogno è una minima parte dell'utenza (quando ci si convincerà che gli utlizzatori di contenuti sono 1000 volte e più il numero dei produttori allora si capirà anche perché i tablet Android basati su "lenti" core ARM bastano e avanzano per la maggior parte della popolazione mondiale).
Il delegare ad HW fatto ad-hoc la manipolazione di dati computazionalmente impegnativi è la giusta via (che ARM usa da sempre). Ma HW ad-hoc non è la GPU che potrà anche essere maggiormente efficiente della CPU in qualche caso, ma rimane comunque estremamente inefficiente in quasi tutti gli altri.

Poi teniamo conto che stiamo parlando di Intel che ha tutti i suoi buoni motivi per avere unità di calcolo speciali che non siano legate alla GPU. E comunuqe ottiene ottimi risultati (come con QuickSync che se necessario ptrà anche essere evoluto a supportare qualità migliori o le unità di de/crittazione).
Nessuno sano di mente si metterebbe a fare la de/crittazione dei dati che invia all'HDD tramite GPU... potrà anche essere più veloce della CPU in quel modo, ma ben distante dalle capacità che le unità specializzate fanno in tempo reale.

Dimenticavo: su PC abbiamo il GPGPU per i 4 filtri supportati da Photoshop, su ARM c'è chi già elabora le immagini tramite HW specializzato. Prendiamo per esempio una macchina fotografica.. secondo voi l'elaborazione la fa meglio usando una serie di ALU pensate per la GPU o un blocco HW che applica gli effetti/filtri? Che poi l'HW ad hoc estremizato sia limitativo sotto ceti punti è vero, ma si possoo anche fare le vie di mezzo.

[carlottoIIx6]

per me hsa è un mix tra hardware dedicato e no.
ovvero, è vero che il dedicato va veloce, ma fa solo una cosa.
che succede se metto più cose non dedicate a fare una cosa sola?
che una parte di queste più cose si avvicina megli a quello che sarebbe l'hardware dedicato, pur rimandendo programmabile.
morale: hsa permette di mantenere la programmabilità e grazie all'adattabilità si avvicina al dedicato senza mai raggiungerlo (ovviamente).

[carlottoIIx6]

Originariamente inviato da PaulGuru

Roba utile vedo.

sai la storia del dito e della luna?
ma forse tu guardi solo a quello che ti fa comodo vedere.
l'informzazione che ho voluto dare è che una cpu normale non ce la fa a farlo, come specificato nell'intervista publicata nel link.

[CrapaDiLegno]

Originariamente inviato da carlottoIIx6

per me hsa è un mix tra hardware dedicato e no.
ovvero, è vero che il dedicato va veloce, ma fa solo una cosa.
che succede se metto più cose non dedicate a fare una cosa sola?
che una parte di queste più cose si avvicina megli a quello che sarebbe l'hardware dedicato, pur rimandendo programmabile.
morale: hsa permette di mantenere la programmabilità e grazie all'adattabilità si avvicina al dedicato senza mai raggiungerlo (ovviamente).

Sì certo , ma tutto dipende da quello che è la tua prospettiva.
L'HW ad hoc fa una cosa sola ma è piccolo. Quindi in teoria puoi avere più unità per calcoli ad hoc che in totale rimangono sempre più piccoli di una GPU da mille e rotti ALU con tutto il nesso e connesso.
Poi l'HW ad hoc può essere anche 100 volte più efficiente del miglior algoritmo scritto per GPU.
Quindi se il tuo scopo è avere 4 algoritmi in croce accelerabili in maniera proficua con una architettura programmabile allora la GPU ha il suo perché. Se vuoi realizzare la vera efficienza, il GPGPU (o l'HSA che propone AMD che è la stessa cosa) non basta.
Chiediti perché sia AMD che nvidia mettono un decoder a funzione fissa nelle proprie GPU anche se queste in realtà potrebbero benissimo macinare così tanti calcoli a decomprimere al volo qualsiasi cosa senza l'ausilio di nessun HW ad hoc. Forse per riuscire a consumare 12W (ovvero 10 di idle + 2 del decoder a funzione fissa) invece dei 200W se faccero fare tutto alle ALU general purpose?
Quindi HSA significa dotare la macchina dei migliori strumenti HW per fare un determinato compito. Che comprende anche avere una CPU ridicola in termini di pura capacità di calcolo ma avere a disposizione coprocessori potentissimi in grado di sopperire là dove serve (sentito parlare del Cell? Quello è HSA vero, 8 anni prima che AMD inventasse la fuffaword HSA. E il Cell ha unità general purpose, non a funzione fissa).
Ritenere che le ALU della GPU, per quante siano siano e quanto potenti possano sembrare sia la panacea di tutti gli algoritmi è fare lo stesso identico errore che è stato fatto 30 anni fa quando Intel ha fatto credere che un core monolitico di dimensioni extra e velocità pazzesche sarebbe stato in grado di fare tutto al meglio. O quello che ancora viene marketizzato come il metodo di aumentare la potenza di calcolo a costo zero: i multicore.
In verità il modello assoluto di massima efficienza è quello che vuole unità di calcolo specifiche per specifici tipi di calcolo. Più complessi di una CPU che invia un flusso di istruzioni ad una o più ALU, ma al contempo più semplici perché non necessitano dell'overhead che le CPU normali si portano dietro (fetcher, decoder, esecuzioni tutto come in una catena di montaggio).
La massima summa è una CPU per il calcolo GP di tipo seriale affiancata ad una FPGA o similia per eseguire un algoritmo non maniera puramente sequenziale come lo svolgerebbe al CPU anche quando quello non è il metodo più efficiente. Il vantaggio dell'FPGA è che una volta che l'unità di calcolo non serve più la si cancella e se ne crea un'altra diversa più efficiente per il calcolo successivo.
Siccome è evidente che non è così facile la cosa né tecnicamente né economicamente, si scende di uno scalino di mettere quante più unità a funzione fissa per i più disparati calcoli si possa pensare. Siccome ancora non è possibile usare centinaia di mm^2 di silicio per unità che non servono quasi mai (se non davvero mai), si scende ancora un gradino e si mettono le unità di calcolo che sono in grado di accelerare gli algoritmi più comuni. Questo è l'HSA (o come si è sempre chiamato, architettura ibrida). Il livello di AMD è ancora un gradino (o anche due) più in basso perché dice che invece di usare unità ottimizzate per un determinato calcolo (che è lo scopo di avere unità di calcolo diverse da quelle general purpose della CPU) bisogna usare un nugolo di unità di calcolo diversamente ottimizzate ma sempre general purpose che talvolta superano in efficienza quelle della CPU ma per la maggior parte delle volte non lo sono.
Io, sinceramente non lo vedo un gran passo in avanti, almeno fino a che le unità di calcolo general purpose delle GPU non smetteranno di avere tutte le limitazioni che hanno oggi, tipo avere difficoltà con i salti condizionati o essere in grado di eseguire uno stream di istruzioni in maniera isolata invece di andare di brute force in esecuzione su centinaia o migliaia di unità che devono eseguire necessariamente lo stesso insieme di istruzioni.
Detto tra noi, le SPU del Cell che hanno 8 anni sono più avanti di quanto non lo siano le ALU delle GPU odierne. ALU che sono semplici e fantasticamente super ideali per il calcolo grafico, ma completamente inadatte per quello GP, in cui come detto compensa la questione brute force se ci sono abbastanza dati su cui operare in parallelo (che nasconde l'estrema inefficienza delle singole ALU).
Più si aumenta la capacità di fare GPGPU, minore è l'efficienza in campo prettamente grafico, come ha ben dimostrato nvidia dal G200 in poi e anche AMD con l'arrivo di GCN.

Forse, nella mia ignoranza, trovo l'approccio più corretto quello alla Cell, dove di fianco alle migliaia di semplici ALU che fanno grafica (e che lascerei semplicissime per occupare meno silicio possibile) si affiancano delle unità più general purpose (come gli SPU o meglio core ARM visto che oggi la loro dimensione non pone problemi con la nanometria a disposizione) per gestire i flussi di codice più complesso (nel flow chart) e meno parallelizzabile (che sono la stra grande maggioranza degli algoritmi pensabili dall'uomo). Certo, si usa più silicio in assoluto, ma si migliora notevolmente l'efficienza del codice eseguito (a discapito del rapporto superficie/calcoli grafici realizzati).

Ripeto, così come AMD propone il suo HSA non si va da nessuna parte nel mondo reale (ma solo in quello dei benchmark o nelle 2 o 3 applicazioni di nicchia che sole si adattano all'uso dei core grafici per come sono pensati oggi).

[CrapaDiLegno]

Originariamente inviato da carlottoIIx6

sai la storia del dito e della luna?
ma forse tu guardi solo a quello che ti fa comodo vedere.
l'informzazione che ho voluto dare è che una cpu normale non ce la fa a farlo, come specificato nell'intervista publicata nel link.

Anche tu guardi un po' le cose per come ti fa comodo però.. ad esempio, ti chiedo, e se usassi una VGA discreta sarebbe possibile la cosa? Magari una scheda nvidia, toh, giusto per vedere se questo fantomatico HSA ha veramente vantaggio sulla concorrenza.

Ci sono decine di esempi di compiti che la CPU non riesce ad eseguire mentre con l'aiuto di una GPU (o di altro HW ad-hoc anche molto semplice, non necessariamente super complesso) riesce a svolgere in maniera egregia.
Una delle cose che aiuta i DSP ad esempio sono le decine di canali DMA che permettono di scambiare dati da una parte all'altra dell'intera memoria a cui il DSP è collegato senza che la CPU sia minimamente coinvolta se non per inivare quei 4 byte di configurazione ogni migliaia e migliaia di byte trasmessi in modalità totalmente trasparente ad essa. Persino la più potente CPU Xeon montata su una worstation con la più veloce RAM farebbe fatica a eseguire alcuni di quei semplici compiti di copia e trasmissione di dati (che non necessitano forzatamente sempre elaborazione da parte di ALU, bada bene, dato che anche il semplice metodo di copia può già essere di per sé una elaborazione sufficiente). E nel caso lo farebbe in maniera completamente inefficiente. E questa cosa è così da decenni. Dunque? Questa cosa l'HSA di AMD sarebbe in grado di gestirla? Risposta no.

Il Cell è in grado di decodificare 2 stream video full HD (senza HW a funzione fissa. E per decodifica intendo la completa decodifica d tutti i dati, non della loro parziale decodifica ridotta su schermo, in quel caso ne fa anche 10 o 12). L'HSA di AMD senza il decoder della VGA sarebbe in grado di farlo? In maniera più efficiente?

Il micro dell'Amiga 1000 era un CPU a 7MHz, uno sputo in confronto all'HW che Intel da lì a poco riuscì a sfornare. Ebbene, prendi un PC del tempo e tenta di fare un programma come Scala (se non sai cosa è Google rimane tua amica). Non c'è Pentium a nessun Ghz che sia in grado di eguagliare le performace dello sputo a 7Mhz. Perché? Semplicemente perché c'erano 2 coprocessori che facevano il lavoro che nessuna delle migliaia di ALU presenti oggi nelle GPU è un grado di fare (e infatti le GPU ancora oggi usano unità simili a quelle per fare il 2D). I Pentium proprio non avevano speranza di fare un bel nulla, nemmeno con le VGA esterne, dato che mancava il segnale di sincronismo al pennello elettronico, ritenuto superfluo al tempo.

E posso continuare con altri esempi. Il tutto per farti notare che non è la prima volta nella storia che si dimostra che le CPU hanno i loro problemi ad eseguire anche compiti semplici, e non è la prima volta che si dimostra che semplici unità (ben più semplici di una sola ALU all'interno d una GPU CGN) permettono accelerazioni di diversi ordini di grandezza nella velocità di esecuzione degli algoritmi.

Nessuno mette in dubbio che l'uso della GPU per fare determinati compiti possa dare una forte accelerazione. Ma la domanda a cui tu non rispondi (e non lo fa nemmeno AMD dall'altro della sua enorme conoscenza) è: a quanti compiti di utilità reale l'accelerazione delle GPU (così come sono realizzate oggi) si adatta? Quanti altri (o magari gli stessi) compiti si possono accelerare con unità di calcolo ben più semplici ed efficienti?
Ovvero, dove è la dimostrazione che servono mille mila unità di calcolo e decine e decine di Watt di potenza per realizzare le cose che ci mostra?
Il Cell fa il post processing delle immagini provenienti dalla debole GPU della PS3 in tempo reale. Ma non ha mille mila ALU all'interno. E non usa codice super mega parallelizzato per ottenerlo. Aggiungo che il Cell di Sony, quello nella PS3 con ridotte capacità di calcolo DP, costa di circa 230 milioni di transistor. Canali I/O e memory controller inclusi. Vuol dire che in una GPU come l'ultima Hawaii ce ne starebbero qualcosa come 25, interi così come sono fabbricati da Sony (con 8 SPE ciascuno). Togli memory controller e uncore ridondante e cambia il rapporto PPE/SPE e probabilmente arrivi ad avere fino a 500 SPE sulla stessa superficie per un vero HSA che non richiede parallelismo alcuno (1 thread per ogni 1 SPE, senza grafica 3D ultra però). Secondo te con quell'HW quanti canali di videochat riesci a gestire? Hawaii o una GPU integrata quanto Hawaii, cioè con la stessa superficie di silicio occupato potrebbe fare lo stesso? E quanti altri algoritmi potrebbe accelerare una scheda del genere che nessuna GPU potrebbe fare?
Sicuro che il futuro sia nell'architettura limitata (di natura, non per incapacità di AMD, intendiamoci) delle GPU?

[cdimauro]

Originariamente inviato da CrapaDiLegno

Premettendo che è un piacere il fatto che mi abbia risposto, trovo comunque parte dei tuoi commenti abbastanza lacunosi.

Beh, è un forum, e siamo qui per discutere. Vedremo se quelle sono effettivamente lacune o informazioni / punti di vista diversi.

Sì, ma le altre fonderie non vivono esclusivamente per il vantaggio che hanno rispetto alla concorrenza.

Ma questo come fai a dirlo? In base a cosa puoi sostenere un'affermazione così assoluta oltre che lapidaria?

Intel sì, e mentre le altre possono permettersi di aggiornarsi con comodità (persino permettendosi qualche nodo solo per usi specifici), Intel non può.

Intel non aggiorna immediatamente tutte le sue fabbriche. Infatti i chip (da Quark a Itanium, inclusi i chipset) che produce non utilizzano tutti l'ultimo processo produttivo.

Il fatto che TMSC si sia potuta permettere un 20nm solo per SoC da solo la dice lunga su quanto sia redditizio il mercato dei SoC. Il fatto che Intel cerchi clienti per riempire le su fonderie la dice lunga su quanto in realtà le stiano costando, o meglio, quanto i guadagni non siano quelli preventivati rispetto ai costi di ammortizzazione necessari.

Il che è naturale, visto che un processo produttivo migliore le consente di sfornare molti più chip per wafer. Per cui o utilizza lei tutta quella capacità produttiva, oppure le servono altri clienti se vuole migliorare (massimizzare, idealmente) i profitti.

In passato non ha avuto bisogno di clienti perché riusciva a soddisfare da sola la sua capacità produttiva, ma adesso è diverso.

Scusami, ma poco conta quello che aveva Intel al tempo in cui ARM faceva processori per calcolatrici evolute.

Ti ricordo che tutta la linea PocketPC era basata su ARM, come pure altri palmari, e quest'architettura era impiegata anche in diversi altri dispositivi: Set-Top-Box, decoder, lettori CD, lettori DVD, player DivX, ecc. ecc. gli esempi si sprecano. Per ricordare i più famosi, l'Archimedes di Acorn che ha fatto debuttare quest'architettura, e poi il Newton di Apple.

Per cui forse ti confondi con Texas Instruments e le sue famose calcolatrici, che però erano basate per lo più su 68000.

ARM ha goduto di una diffusione notevole in ambito embedded, e certamente non esclusivamente per le calcolatrici. Infatti ha introdotto numerose estensioni e versioni dell'architettura che sono tutt'altro che orientate alle sole calcolatrici; basti vedere la storia di quest'architettura (di cui ho parlato in una serie di articoli su Appunti Digitali).

Intel aveva in mano una tecnologia che sapeva benissimo essere migliore della propria, ma non essendo la propria ha semplicemente deciso di non cercare di darle vantaggio iniziando un processo di ottimizzazione e costruzioni con processi produttivi che nessun latro poteva (e può) permettersi.
Il risultato è solo stato un leggero ritardo sui tempi di maturazione dell'architettura ARM che ha preso il largo e oggi pure un colosso come Intel fa fatica ad arginare.

Non mi pare che sia Intel ad avere in mano le redini dell'architettura ARM, e a decidere in che modo far maturare quest'architettura. E' ARM che produce le sue IP e fa evolvere le proprie micro/architetture.

Intel è stato un cliente come un altro, che ne ha acquisito le licenze, e prodotto le sue versioni personalizzate (a cui ha aggiunto estensioni simili alle MMX, ad esempio).

Non vedo, quindi, in che modo il lavoro di Intel avrebbe potuto avvantaggiare ARM, visto che non ne aveva il pieno (e assoluto, come da sua tradizione) controllo...

Dai, non scadiamo nell'evangelizzazione.

Permettimi: hai riportato soltanto una parte della torta, io ho semplicemente aggiunto quella mancante, e mi tacci di "evangelizzazione"?

Intel è sempre stata nel mercato embedded. Con scarsi risultati. D'altronde, come con ARM, è difficile competere in un mercato dove conta molto l'efficienza e il basso consumo (il raffreddamento passivo è quasi d'obbligo).

Infatti s'è ritagliata il suo segmento anche nel settore embedded, ma questo con la serie 8085 di microcontrollori a 8-bit, perché in questo campo per parecchio tempo non serviva altro. Tant'è che è stato un fiorire di architetture a 8-bit dedicate allo scopo, oppure sono stati impiegati vecchi processori (6502, Z80, 6800 sono gli esempi più noti) e riutilizzati allo scopo.

Questo non vuol dire che non ci fossero architetture a 16 o 32 bit utilizzate in ambito embedded, ma queste venivano impiegate in scenari più complessi. Qui Intel non è riuscita a diffondere la sua architettura IA32 (anche con apposite declinazioni), ma non era nemmeno interessata a spingersi così tanto, visto che poteva contare su un mercato molto più redditizio.

Negli ultimi anni, però, le cose sono cambiate, e anche nel settore embedded è cresciuta la richiesta di architetture in grado di macinare più numeri, e non a 8 bit. Ecco perché molte aziende hanno sfornato versioni a 16 o direttamente a 32 bit delle proprie architetture embedded (che in realtà spesso sono architetture completamente nuove). E questo è anche il motivo per cui Intel ha pensato bene di riutilizzare quello che già aveva per entrare con decisione anche in questo mercato, che è diventato molto più importante (Smart-TV e automobili sono esempi eloquenti).

PowerPC, NEC, Hitachi (ora entrambe Renesas), MIPS e ARM e FPGA sono le architetture che normalmente si usano in campo industriale. Quark non farà differenza. Intel non riuscirà mai a vendere un chip allo steso prezzo delle altre architetture. Andrà bene là dove è sempre andata, ovvero dove contano più le performance e ci si può permettere meno limitazioni. Una nicchia nella nicchia.

Non è che PowerPC e MIPS pecchino proprio nelle prestazioni. Tutt'altro.

Quanto ai prezzi, forse faresti bene a dare un'occhiata ai listini dei produttori di processori e SoC in ambito embedded (avanzato; come quello in cui operano le realtà che hai citato): la parola "economico" non è esattamente ciò che ispirano.

Infine, se vai a vedere l'ultima roadmap sfornata dal consorzio POWER, relativamente al POWER 8, vedrai che loro stessi segnalano un trend in discesa quanto a diffusione, e citano Intel come una delle cause in merito.

Per cui sarà pure una nicchia, o una nicchia nella nicchia, ma se Intel riesce a vendere lo stesso e gli altri produttori si preoccupano tanto da citarla come causa della contrazione del loro mercato, qualcosa vorrà pur dire...

L'ingresso di Intel nel mondo mobile è frutto solo di sovvenzioni. Nessuno, a parte quelli che sono stati pagati, ha interesse ad usare l'HW di Intel. Mentre mi sembra che ci sia una fila tremenda per gli ultimi OC di Qualcomm (vedi il discorso di prima sul PP a 20nm solo per SoC). Chiediti il perché. Se Intel desse anche a me 500 milioni per fare un telefono con un Atom dentro correrei a cercare la scatola dove infilare tutto.

Infatti mi chiedo com'è che siano stati realizzati dei prodotti basati su Atom quando:
- non c'erano sovvenzioni di Intel;
- il PP utilizzato era vecchio (rispetto a quello impiegato per altri processori).

Il primo esempio che mi viene in mente: il (primo) Samsung Galaxy Tab da 10", realizzato anni fa.

Ma è ovvio che appena Intel molla la pressione sul tasto "sovvenzioni" il motore (cioè l'interesse) si spegnerà da solo. Intel = Windows. Se fai un tablet con Windows 8 allora ci sta un Intel dentro. Altrimenti un x86 con tutti i suoi problemi non serve a nessuno. Vedi iOS e Android che bene hanno dimostrato la cosa.

iOS è un mondo e mercato blindato da Apple. Android è aperto, e proprio lì Intel si sta espandendo. Anzi, persino MIPS è entrato nel ramo ufficiale, e mi sembra che anche PowerPC ci giri, sebbene non sia ancora nel ramo ufficiale.

Quali sarebbero, poi, i problemi di x86?

Nel mondo HPC, sì La Xeon Phi fa ottimi numeri, ma stiamo sempre parlando di qualcosa realizzato con un PP di vantaggio rispetto alla concorrenza, che nonostante quello detiene comunque la migliore efficienza di GFlops/W. E con Maxell la cosa dovrebbe essere peggio per Intel, anche se Maxwell è sempre fatto con lo stesso PP.

Come per Atom, Intel non ha utilizzato da subito l'ultimo PP per queste soluzioni. Soltanto con l'ultima incarnazione, Knights Corner, ha utilizzato (finalmente) i 22nm.

Al resto rispondo sotto.

D'altronde fosse stata "avanti" in questo campo il mercato HPC l'avrebbe conquistato lei a mani basse.

Scusami, ma c'è entrata giusto da qualche anno. Per conquistare un mercato ci vuole un po' di tempo; vedi, ad esempio, la classifica TOP 500, dove prima era totalmente assente, mentre ormai ha percentuali bulgare quanto a quote di mercato.

Invece si trova a infilarsi momentaneamente nei varchi quando la concorrenza ha problemi di processo produttivo. Ci fossero oggi 20nm per GPU vedremmo dove starebbe Intel con le sue Xeon Phi fatte da vetusti core x86. Poi un giorno mi spiegherai a che serve usare i core x86 in un sistema che serve da coprocessore e basta quando in verità ci si potrebbe infilare qualsiasi cosa (pure una serie di Cell di IBM).

Te lo spiego oggi: serve a utilizzare facilmente un'architettura molto ben conosciuta, e per la quale esistono tool di sviluppo che consentono di ottenere velocemente risultati e sfruttare la potenza di calcolo a disposizione.

Il fatto che Maxwell offrirà una certa potenza di calcolo teorica superiore non significa che automaticamente e immediatamente la si potrà utilizzare.

La potenza di calcolo grezza è soltanto un parametro, certamente molto importante, ma non è il solo di cui tenere conto; anche perché praticamente è molto difficile che si arrivi a questi numeri su carta.

Prova a chiedere a uno sviluppatore se preferisce lavorare con CUDA e sputare sangue per riscrivere e ottimizzare al meglio il kernel dell'algoritmo che vuole implementare, oppure semplicemente includere la MKL di Intel che gli consente di sfruttare al meglio fin da subito il suo codice esistente scritto in C/C++ o Fortran che utilizza le funzioni già note e diffuse da decenni e usate da matematici, fisici, ecc. per i loro calcoli. Questo per fare un esempio, ma te ne potrei fare altri.

Insomma, stiamo continuamente ribadendo che senza PP di vantaggio Intel sarebbe già scomparsa o ridimensionata da un bel pezzo.

Con lo stesso metro di giudizio aziende come Tilera avrebbero dovuto eclissare nVidia, AMD, IBM, Fujitsu, ecc. nell'ambito della pura potenza di calcolo, visto quello che sulla carta offrono.

Evidentemente le valutazioni non possono tenere conto di un solo parametro, per quanto sia importante. Vale per il PP più aggiornato di Intel (ma sul quale spesso vengono sollevati dubbi che sia tanto buono, per cui potrebbe anche non essere un vero vantaggio per Intel) quanto per altre cose (tool di sviluppo, librerie, compilatori, e ovviamente anche la stessa architettura).

Puoi studiare tutti i numeri e fare tutte le simulazioni che vuoi, ma i fatti sono diversi. L'architettura x86 non è solo mangiatrice di transistor (e watt), ma è anche una vergogna dal punto di vista dello sfruttamento della memoria.

Scusami, ma questa è un'assurdità. I numeri e le simulazioni servono a capire l'impatto che ha proprio l'elemento più problematico di x86: la sua eredità legacy.

Se per te un decoder che si mangia circa un milione di transistor ha lo stesso peso su un core da 3 milioni di transistor e su un altro che ne ha 30, 300, o addirittura 3 miliardi (pur se diviso per il numero di core/thread hardware a disposizione), beh, allora non posso che alzare le mani e arrendermi, perché non posso controbattere con una presa di posizione del tutto priva di senso.

Con quei 4 registri in croce mai ampliati per davvero,

Veramente sono 8, ampliati a 16 da AMD con x64, per la "sola" unità SIMD sono diventati 32 per Larrabee/Xeon Phi, e saranno sempre 32 quando AVX-512 arriverà, a breve, anche su architetture più "consumer" Xeon Phi.

perdendo pure la chance dei 64bit,

Cioè? AMD ha fatto evolvere IA32 a 64 bit, che anche Intel ha abbracciato e propone da circa 10 anni. Questo rimanendo in ambito x86. In passato Intel ha già sfornato architetture a 64 bit completamente nuove, anche se non sono andate bene commercialmente.

l'accesso alle cache e alla RAM è continuo. E servono cache enormi per tenere le pipeline alimentate.

A parte che non è affatto così, visto che le cache non sono enormi (AMD ha proposto le soluzioni che ne avevano di più, ma è un caso unico nel panorama x86), proprio le cache servono a ridurre l'accesso alla RAM.

Poi ti faccio notare che anche i processori ARM fanno uso di ampie cache. Vedi l'ultima incarnazione di Apple, l'A7. Mi chiedo a cosa serviranno a questo punto, visto l'enorme vantaggio che (sulla carta) avrebbe la concorrenza, a tuo dire...

Inoltre x86 ha una densità di codice superiore ai RISC, ARM inclusi, che le consente di risparmiare sia spazio in memoria sia poi nelle cache, e dunque anche nella banda consumata.
Quando parliamo di cache e RAM c'è anche questo fattore di cui bisogna tenere conto, che è decisamente importante. Tanto che i RISC hanno dovuto tradire la loro natura e diventare dei CISC pur di competere in questo campo; Thumb di ARM è l'esempio più noto.

Il Motorola 68000 ai tempi già dava la paga agli x86 solo per l'efficienza che poteva godere con l'uso di 16 registri

Infatti ho un ottimo ricordo dei 68000. Ma sono morti, e non si sono evoluti, mentre IA32 sì. Infatti ha raggiunto i 16 registri, che però sono diventati totalmente general purpose (i 68000 avevano 8 registri dati e 8 registri indirizzi) con x64.

ARM ha 16 registri, anche se un paio sono riservati per il PC e per l'indirizzo di ritorno da una funzione. Per cui non mi sembra che x64 sia messa così male come ISA.

e una memoria flat, invece dell'accrocchio made in Intel.

Veramente è da una trentina d'anni che Intel ha messo a disposizione un modello flat per la memoria, che peraltro tutti i s.o. utilizzano ormai da almeno una ventina d'anni.

Con x64, poi, esiste esclusivamente il modello flat nella modalità a 64 bit...

Non ci vuole molto a fare delle architetture migliori di quelle x86: basta pensarle bene fin a subito.

Quindi Intel doveva "pensare bene" un'architettura quasi 40 anni fa, quando a stento circolavano processori a 8 bit? Interessante tesi...

Magari Motorola avrebbe dovuto evitare di inserire le mostruose (da implementare in una microarchitettura) modalità d'indirizzamento con doppia indirezione verso la memoria, che ha introdusse col 68020, e che l'hanno poi fatta piangere amaramente col 68040 e 68060.

Che dire, poi, di Acorn, che nella prima versione (v1) della sua nuova CPU ARM aveva "ben pensato" di utilizzare 6 bit del PC per infilarci i flag del registro di stato, castrandola così a un massimo di 64MB di memoria virtuale, e costringendola poi al radicale (nonché non retrocompatibile, ovviamente) cambiamento avvenuto con la v2 di appena qualche anno dopo, che li ha scorporati e spostati nei nuovi registri di stato. E non era il 1978, ma il 1985 quando è stata presentata questa ISA, per cui una scelta così insensata se la sarebbe potuta risparmiare, alla luce di quanto avevano già realizzato altri produttori di CPU.

Con ciò penso sia chiaro dove voglio arrivare: di errori madornali nell'ambito delle architetture ne sono stati commessi da tanti produttori di CPU, e inoltre nessuno nasce con la sfera di cristallo, per cui la portata di alcune scelte non era prevedibile a distanza di anni (no, la scelta di ARM non ci rientra: è stata una sciocchezza fin dall'inizio).

L'x86 non lo è stata, e infatti è più un mostro Frankenstein completamente rifatto da plastiche su plastiche che una bella donna naturale.

Ha saputo rifarsi bene il trucco, visto quello che è riuscita a fare. Sarà brutta quanto vuoi, ma è stata in grado di evolversi e limitare l'eredità che si porta dietro. Già da parecchi anni non si programma più come l'8086...

Ma anche altre architetture sono state costrette a ricorrere alla chirurgia plastica. Visto che parliamo spesso di ARM, vedi la sua v1 che è stata velocemente soppiantata dalla v2 che ha corretto quell'assurdità di cui sopra, costringendo a dare un taglio alla (retro) compatibilità. E la v8 (aka ARM64) è l'ultimo esempio.

Vedi sopra, si muovono le sovvenzioni di Intel per cercare di trovare spazio dopo 4 anni di continui flop uno dietro l'altro.

Le sovvenzioni sono roba di pochi mesi fa, come già detto.

Se non facesse così sarebbe un altro anno in cui nessuno si accorge che Intel esiste nel campo mobile. Sta tentando il tutto per tutto. Se non sfonda (come credo non farà), il business mobile è perso (gli anni futuri non crescerà più come quelli passati e ormai i giochi sono fatti con produttori che sfornano SoC ARM più che sufficienti per smarphone e tablet a prezzi irrisori che Intel non può raggiungere nemmeno se divide per dieci il suo SOC).

Vedremo. Intanto sono già diversi i prodotti mobile che integrano un chip Intel, anche senza far girare Windows.

E' uno scenario un po' nostalgico. La gente non vuole Windows ovunque. La gente vuole fare le cose nel modo più facile possibile. E questo non significa avere un tablet che pesa 1 kG perché la batteria deve essere grande per garantire una autonomia decente da portarsi sempre appresso e lo schermo è lo stesso che si usa in ufficio (che non può essere un 7" se si vuole davvero lavorare).

Mi sembra che prodotti come SurfacePro abbiamo dimostrato come la situazione di x86 non sia esattamente come la stai dipingendo.

E abbiamo dimenticato l'evoluzione che sta avendo il cloud? Io oggi leggo la posta di Google sul mega PC con il mega monitor attualmente in uso, sul tablet e sullo smartphone. E accedo liberamente ai miei dati con Dropbox o Google Drive. Mi serve un processore Intel per farlo? No. Perché se esistono alternative che offrono strumenti migliori per un determinato uso, che me ne frega di avere x86 (= compatibilità con Windows)?

Forse perché Dropbox e Google Drive utilizzano Python per i loro client, che richiede non poca potenza di calcolo per avere certi risultati, e predilige nettamente architetture che offrono elevate prestazioni su singolo core/thread?

Hai mai aperto il task manager per vedere quanti core vengono utilizzati, e con quale carico, durante l'operazione di indicizzazione effettuata da queste applicazioni? Hai mai visto la differenza che passa per effettuare la stessa operazione su un AMD C-50 e un Phenom II 4 a 3,2Ghz (rispettivamente il sub-notebook da cui ti sto scrivendo e il desktop che ho a casa)? E non è soltanto una questione di dischi più lenti per il primo sistema, visto che su desktop utilizzo hard disk a basso consumo da 5400rpm, per cui non c'è un grosso distacco con quello da 4200rpm (mi pare) del portatile.

Poi c'è da dire che, sempre rimanendo in ambito cloud, i client basati sulla triade HTML/CSS/Javascript sono affamati di potenza di calcolo, e Javascript è... intrinsecamente mono-thread (anche se in futuro saranno introdotti i worker nello standard, per alleviare un po' la situazione). Per cui, sì, l'accelerazione hardware sfruttando la GPU ha migliorato le prestazioni dei browser, ma Javascript richiede sempre una grossa potenza di calcolo su singolo core/thread.

Sì, puoi fare le stesse cose anche senza x86, ma ovviamente non hai gli stessi tempi di risposta, anche se hai 8 core a disposizione per macinare numeri...

Forse no hai compreso che non serve a nulla un confronto transistor per transistor tra i core per vedere chi ce l'ha più lungo qui o lì.

Serve a capire se un'architettura è intrinsecamente scarsa oppure no, visto che la discussione s'è focalizzata sull'architettura di per sé.

Quello che conta sono due fattori: la potenza di calcolo dei processori ARM oggi è sufficiente per soddisfare l'utenza con l'uso di dispositivi che io definisco "passivi". Cioè quelli che non sono usati per creare contenuti. Visto che la maggior parte dell'utenza consuma contenuti invece di crearli (a parte i post sui forum e su FaceBook, ma per quello ARM basta e avanza), direi che la strada di Intel per far pesare la sua maggiore potenza di calcolo è molto in salita. Sopratutto perché, se l'efficienza fosse la stessa questo aumento di potenza di calcolo equivale ad una diminuzione dell'autonomia del dispositivo. Ma già in efficienza siamo ben distanti a parità di processo produttivo.
Il secondo fattore sono i costi: i processi produttivi di vantaggio di Intel le permettono più o meno di pareggiare sul lato efficienza, ma non su quello costi. A parità di area Intel il SoC di Intel costa quasi il doppio. Va 2 volte di più. Boh, forse, ma non è quello che l'utenza chiede. In un mercato che vuole i prezzi in calo (proprio perché si sta saturando vince chi offre a meno, non chi offre di più) un euro in più o in meno sulla BOM fa la differenza.

Premesso che concordo sulla valutazione dell'intero ecosistema (perché è quello che, nella sua interezza, finisce in mano alla gente), la situazione non è esattamente quella che dipingi.

Se vuoi ottenere prestazioni mediamente migliori in tutti gli ambiti di utilizzo, Intel ha sicuramente le sue buone carte da giocare. ARM sta andando avanti a colpi di core, ma 9 donne non fanno un bambino in un mese. Ci sono ambiti in cui puoi sfruttare poco o per nulla i numerosi core a disposizione. Meglio un'architettura più bilanciata, che consente buone prestazioni anche quando viene usato un solo core da un particolare software.

Fermo restando che, anche guardando alle prestazioni complessive, Intel non ha proprio nulla da invidiare a nessuno; tutt'altro.

Per i guadagni di TMSC vedi inizio post: ha creato un PP solo per SoC. Con la felicità estrema di nvidia e AMD. Ma questo semplicemente significa che quel mercato fa guadagnare parecchio (che sia per volumi o costi poco importa).

nVidia e AMD sfornano GPU, per cui hanno bisogno di un PP adeguato alle loro particolari esigenze. E dunque mi pare normale che la fonderia da cui si servono gliene metta a disposizione uno apposito.

A Intel, invece, serve altro, per cui non ha avuto questa necessità.

Intel non ha molte altre carte da giocarsi se non intervenendo sui prezzi per cercare di dare un lancio ai suoi prodotti che nessuno sa nemmeno esistere nel mercato mobile. Cosa altro può fare se non ridurre ulteriormente il transistor? Certo che però le costerò di più, e quindi le sovvenzioni dovranno essere pesanti.

Come dicevo sopra, ha anche altre carte che si può giocare.

Le sovvenzioni sono arrivate adesso, e servono a darle un'accelerata per far diffondere le sue architetture, in modo da guadagnare quote da un mercato in cui ha pensato troppo tardi di entrare.

Ricordo, in merito, il recente mea culpa di Otellini, che chiuse le porte ad Apple e al suo iPhone...

Forse ti è sfuggito che il mercato è radicalmente cambiato: con la semplicità e il facile adattamento dell'architettura ARM progettarsi e realizzare un chip è alla portata di moltissimi. Moltissimi che possono permettersi di non dipendere da un produttore che fa chip monolitici da costi spropositati, possono farselo in casa come vogliono (bilanciando CPU o GPU cme megliono credono per il dispositivo che hanno in mente) e guadagnarci sopra molto di più che rivendendo un chip Intel. Oppure si possono rivolgere a un progettista cinese (come MediaTek per esempio) e arrivare sul mercato con un dispositivo che costa molto meno di quello già sovvenzionato da Intel.

Non mi sfugge affatto, come non mi sfugge che un chip ARM te lo puoi realizzare in casa anche e soprattutto grazie al fatto che acquisti la licenza e i progetti di ARM, quindi non parti assolutamente da zero.

Non c'è più la catena Windows che lega verso i micro Intel. Nel mobile non servono mille mila GFlop (e pure la questione degli octa core ARM sono una buffonata che presto spero evaporerà).

Non evaporerà e, anzi, arriveranno sempre più core.

Inoltre i GFLOPS servono perché la gente vuole sempre più, e non si limita a fare la telefonata o mandare l'SMS. Infatti i SoC mobili hanno superato la soglia del miliardo di transistor, mettendo a disposizione CPU con molti core e GPU con molti stream processor; se non ci fosse stata richiesta non si sarebbero viste queste soluzioni, e puoi metterci la mano sul fuoco che il trend è destinato a crescere e certamente non a diminuire. Anche qui, non è un caso che gli smartphone abbiano superano i feature-phone in termini di vendite.

Il futuro è ben delineato...

Non si possono avere memorie da mille mila GHz per riuscire ad alimentare CPU che non sanno dove mettere i dati.

Tipo? Questa non l'ho capita.

E inoltre non è più Intel contro uno o l'altro o l'altro, ovvero un elefante che abbatte come birilli gli scoiattoli che la affrontano da soli uno alla volta, o uno squalo che si mangia i tonni che osano sfiorarlo.
Intel è rimasta lo squalo di prima, ma ora intorno ci sono una miriade di piranha, ovvero tutti quelli che adottano in un modo o in un altro, persino sviluppandola in proprio, l'architettura ARM. Per quanti possa riuscire a mangiarsene, anche questi riusciranno a infliggere dei dolorosi morsi e con il tempo a contenerlo.
Questa volta le risorse degli altri non sono dispersi in mille rivoli, ma confluiscono tutti nella stessa pentola, quella delle fonderie terze che permette loro di aggiornarsi più velocemente (se aspettavano AMD per farlo avrebbero smesso da tempo di cercare di rincorrere Intel e sarebbero rimasti con processi produttivi economici utili per la maggior parte dell'elettronica non high speed...).

Non mi sembra che qualcuno neghi il successo dei processori ARM e le difficoltà di Intel, sia in questi nuovi mercati sia nel suo mercato di riferimento che è calato. Ma non vedo lapidi all'orizzonte...

Intendo che se non sfonda con Atom che è x86 based, o rinuncia al mobile o deve cambiare architettura nettamente.

E quale architettura dovrebbe adottare (o progettare)? ARM, che ha già abbandonato in favore della sua favorita?

Non vedo poi, perché dovrebbe abbandonare la battaglia proprio adesso che con gli ultimi modelli di Atom l'hanno resa competitiva con ARM anche in termini di consumo. Sarebbe, al contrario, un gesto folle.

Il che vuol dire che perde la retrocompatibilità con il mondo x86 (e Windows) e si mette sulla linea di partenza a livello zero come lo sono gli altri, da ARM a MIPS.

Beh, intanto non è detto che una nuova architettura debba necessariamente perdere la compatibilità con x86.

Poi anche gli altri che hai citato hanno dovuto effettuare cambiamenti radicali e non retrocompatibili; mi riferisco in particolare ad ARM, di cui ho parlato anche sopra.

E perderebbe la faccia visto che sono anni che cerca di convincere in tutti i modi gli investitori che la sua è l'architettura migliore per qualsiasi cosa, dopo aver venduto la divisione ARM, riciclato il fallimento di Larrabee in un progetto HPC (e ci si chiede cosa abbiano in comune le due cose per far in modo che Intel dichiarasse che Larrabee sarebbe stata la migliore GPU mai creata, giusto per evidenziare come spesso il marketing nasconda ben altre verità.)

Larrabee è stata progettata con la consulenza di mostri sacri nel campo della computer grafica. Gente del calibro di Abrash e Sweeney. L'obiettivo era quello di entrare nel mondo delle GPU, ma quella proposta era una soluzione troppo general purpose, pur con tutte le migliorie introdotte, incluse unità specializzate in alcuni ambiti. S'è andata a scontrare con Nvidia e AMD, che avevano soluzioni ad hoc, e dunque più efficienti (per il discorso che hai poi fatto negli altri commenti, che ben delinea pregi e difetti di soluzioni general purpose e specializzate). Per cui il progetto non è stato in grado di competere. Magari in futuro, con l'introduzione di ray tracing in tempo reale, quest'architettura potrebbe essere ripresa visto che è molto interessante per questo tipo di calcoli, ma al momento è morta.

Ciò precisato, tolte le vesti e le parti specificamente da GPU, il progetto Larrabee presentava comunque caratteristiche da renderlo particolarmente appetibile per il settore HPC, dove le sue nuove unità vettoriali potevano tranquillamente dire la loro rispetto alla concorrenza. Concorrenza che, viceversa, si trascina dietro l'essere progettata principalmente come GPU, e dunque con parti del tutto inutili in quest'ambito; potremmo chiamarla GPU-tax.

Per questo motivo Larrabee è stata riadattata e ottimizzata per competere nel settore HPC, e mi sembra che qualche risultato lo stia raggiungendo, pur essendo arrivata da poco. In futuro sono previste novità che renderanno Xeon Phi ancora più interessante e competitiva.

e aver creato un processore a basso consumo orribile come l'Atom e non essere stata capace in 6 anni a renderlo appetibile per nessuno.

Che abbia venduto poco IN AMBITO MOBILE ci può stare, ma... i netbook ti dicono niente? E poi cos'avrebbe di orribile?

Ora coccolo un po' questo i7 che altrimenti dopo tutta questa critica ad Intel finisce per rompersi solo per dispetto

Dovrei fare lo stesso col mio C-50, dopo quello che ho scritto sulla "mamma".

[cdimauro]

Originariamente inviato da carlottoIIx6

è proprio qui il vantaggio di hsa, che non è solo gpu, ma cpu e gpu sullo stesso livello con huma e hQ, il sofware sceglie quale unità utilizzare che lo fa prima.
edit
una chicca
http://www.inpai.com.cn/doc/hard/197966.htm
programma video chat hsa con kaveri, fino a 70 video chat contemporanee

Non mi dice nulla.

Comunque forse non hai chiaro come funzioni una pipeline grafica, come ad esempio quella di un decoder JPEG / JPEG 2000, o MPEG 1/2/4 - H264/265.

Non è uno scenario in cui continuamente cambi contesto e hai bisogno di eseguire calcoli per una FFT o trasformata wavelet, per il decoder aritmetico, la (de)quantizzazione, ecc., che si intrecciano in maniera caotica, e che richiedono l'utilizzo di unitò della CPU o della GPU (tramite HSA) magari nello stesso ciclo di clock. Si tratta di fasi che vengono eseguite "in blocco"; si finisce, ad esempio, la decodifica aritmetica di una porzione dell'immagine, e DOPO si passa alla quantizzazione della medesima area; e così via per le altre fasi.

Mi spieghi in che modo porterebbe vantaggi l'HSA? Sì, magari posso eseguire l'offloading di alcune parti più velocemente, ma non cambia la vita di una pipeline grafica come quella; il guadagno, SE C'E', è molto ridotto.

Per il resto sono sostanzialmente d'accordo con CrapaDiLegno, che ha ben analizzato ed esposto gli scenari.