Link alla notizia: http://www.hwupgrade.it/news/cpu/c-e-del-nuovo-per-i-futuri-processori-desktop-di-amd_55781.html

La volontà di assegnare più risorse di ricerfca e sviluppo per processori destinati a sistemi server potrebbe avere quale ricaduta diretta per AMD anche la futura disponibilità di processori desktop di fascia alta di nuova generazione

Click sul link per visualizzare la notizia.

Speriamo!

E' importante che AMD si svegli e ricominci a mettere sul mercato CPU di valore. Speriamo bene, la concorrenza è fondamentale :D

Credevo che già ci fosse una pianificazione per le soluzioni FX, ma a quanto pare non è vero niente.

E cosa vorrebbero rifilarci su desktop ? Degli Opteron ibridi x86/ARM ?

E poi ci si lamenta se Intel va avanti col gontagocce.

ormai la fascia alta per amd è andata troppi anni persi
speriamo butti fuori qualcosa per la fascia media dove ormai gli i5 sono la scelta obbligata
sui server sta perdendo ancora terreno fra un pò gli avoton andranno come gli opteron se amd non rinnova la linea

E' importante che AMD si svegli e ricominci a mettere sul mercato CPU di valore. Speriamo bene, la concorrenza è fondamentale :D

Ormai AMD ha puntato sul mercato APU, la concorrenza vecchio stile di CPU è morta.

anche con questi investimenti ormai amd ha perso troppo terreno rispetto a intel, non pesno che riuscirà a colmare il gap facilmente

Ormai AMD ha puntato sul mercato APU, la concorrenza vecchio stile di CPU è morta.
Praticamente han puntato sui prodotti ultra economici di scarse prestazioni ad alta distribuzione, presumo un toccasana anche a livello di immagine del brand essere associati a roba del genere.

Intel ha palesemente rallentato da parecchi anni e AMD al posto di approfittarne ha abbandonato del tutto, a casa mia si chiama fallimento, il cambio di strategia commerciale non è stata la causa ma l'effetto.

scordatevi qualcosa di interessante almeno fino al 2016 quando "dovrebbe" uscire ZEN, la prima architettura NON basata su bolldozer :rolleyes: :muro:

scordatevi qualcosa di interessante almeno fino al 2016 quando "dovrebbe" uscire ZEN, la prima architettura NON basata su bolldozer :rolleyes: :muro:
Han appena fatto capire che in realtà non era previsto nulla per desktop.

divertente, i patern amd hanno capito che se comprano solo intel vengono strangolati dai prezzi :)
:sofico:

Mah, devono darsi una svegliata, lo facciano come gli pare, ma in ambito cpu sono assurdamente indietro.
L'ultima architettura decente che hanno tirato fuori sono stati i phenom II, culminati negli esacore x6, ma oramai parliamo di ben 4 anni fa e già ai tempi dovevano puntare tutto sul rapporto q/p per vendere.

Bulldozer e piledriver sono progetti fallimentari, che amd è stata costretta a spingere all'inverosimile in frequenza senza curarsi dei consumi e a vendere a prezzo di saldo per non ritrovarseli tutti sul groppone.

La concorrenza (intel), invece, sta andando col freno a mano tirato, elargendo novità col contagocce, altrimenti l'antitrust se la monta peggio di rocco.

E che non inizino i soiti discorsi "l'architettura amd è vincente per il futuro", perchè è da anni che si sente 'sta storia, e di miracoli ancora non se ne sono visti. Anzi, le stesse cose si dicevano del cell della ps3 (vedrete... in futuro... spaccherà culi a destra e a manca...) e sappiamo tutti com'è andata a finire.
Inoltre, chi acquista cpu oggi, le acquista per oggi, non "tra 2 anni va meglio".

E' importante che AMD si svegli e ricominci a mettere sul mercato CPU di valore. Speriamo bene, la concorrenza è fondamentale :D
Purtroppo il taglio del 15% nella voce R&D tra il trimestre scorso e quello precedente non dà molta speranza sulla "quantità" di investimenti che potranno mettere in gioco. Probabilmente ripartiranno in maniera differente l'attenzione internamente alle proprie divisioni, ma la quantità di cervelli a disposizione è comunuqe in diminuizione. Veloce diminuzione. E non è bello per una azienda che vive di tecnologia e ha concorrenti super agguerriti in tutti i campi in cui già opera o vuole operare (non è che il mercato server con architettura ARM sta aspettando solo AMD, ci sono tanti altri player che stanno lavorando per entrarci, non ultima Qualcomm, che non è certo l'ultima arrivata).

Io continuo a pensare che possono sfornare tutte le architetture dell'universo ma se non hanno un supporto dagli oem e le software house non cambia nulla.
Basti vedere mantle e hsa che fine hanno fatto, belli belli ma li hanno usati su 2 giochi il primo e su libreoffice il secondo.
Pc che montano cpu/apu amd? Devi andarteli a cercare.
Mah, la qualità del prodotto incide anche su queste cose. Costruire un portatile che pesa 3 Kg per avere 6 ore di autonomia ha un certo costo e appeal all'utente che comunque può trovare una soluzione analoga che pesa 2Kg con più o meno le stesse caratteristiche con una soluzione costruita con componenti della concorrenza.
Se il produttore per qualsiasi altra ragione vende 9 portatili da 2Kg e 1 da 3Kg, è logico che non investe nel loro sviluppo.

Mantle è un ritorno al passato. Forse non c'eravate al tempo di 3Dfx con le Glide e le API proprietarie. Per quanto belle e fighe possano essere non sono lo standard e pesa economicamente supportarle.
HSA è una bufala così come è prorposta oggi (hybrid = CPU + GPU). HSA sarà vera quando oltre alle GPU si comincerà ad intergrare anche altre unità di calcolo in modo da rendere molte più soluzioni capaci di alta efficienza, non solo quelle altamente parallelizzate che richiedono 1000 unità di calcolo saturate per avere la meglio su una singola unità di calcolo integrata nella CPU.

Io continuo a pensare che possono sfornare tutte le architetture dell'universo ma se non hanno un supporto dagli oem e le software house non cambia nulla.
Basti vedere mantle e hsa che fine hanno fatto, belli belli ma li hanno usati su 2 giochi il primo e su libreoffice il secondo.
Pc che montano cpu/apu amd? Devi andarteli a cercare.

se sforni qualcosa di nuovo che richiede ricompilazione del software devi andare a bussare porta a porta sulla maggior parte delle SH e dare soldi perchè sviluppino per te, se non hai i soldi è proprio meglio evitare di inventarsi cose nuove

Han appena fatto capire che in realtà non era previsto nulla per desktop.

intendi ZEN o excavator?

sara'...ma io non ho capito ancora se sulla fascia bassa sotto i 50 euro hanno qualcosa di concorrenziale o no...a me sembra di no...

sara'...ma io non ho capito ancora se sulla fascia bassa sotto i 50 euro hanno qualcosa di concorrenziale o no...a me sembra di no...

c'è il soket am1 con il 5350, che vuoi di più?

c'è il soket am1 con il 5350, che vuoi di più?

celeron 1820 35€
mobo h81 36€

il 5350 se lo pappa a colazione

È proprio quello che ho detto io no? :)

:mano: :mano:

celeron 1820 35€
mobo h81 36€

il 5350 se lo pappa a colazione



:mano: :mano:

Peccato che:

1) Il celeron ha tdp di 52watt, il 5350 da 25W, è praticamente fanless ed ha una gpu molto migliore per un utilizzo htpc.
2) Con 35 euro ti fai una scheda socket am1 mini itx, per fare lo stesso con una lga 1150 te ne partono almeno 50.

Abbiamo avuto nell'ordine Bulldozer-piledriver (32nm), steamroller-excavator(28nm), ben 4 generazioni di cpu. Il fallimento dell'architettura francamente non lo vedo, visto che è tutto è andato secondo roadmap, salvo il "piccolo" particolare che steamroller e excavator dovevano essere costruiti con i 22nm fd-soi

Per chi parla di Phenom II di ultima architettura riuscita, direi che il 95% delle prestazioni è stato raggiunto dal primo phenom. Il fallimento commerciale è dovuto al fatto che AMD ha spinto anzitempo i quad-core nativi, sacrificando sia la frequenza complessiva, la resa, l'ipc integrando solo 2mb di cache l3.


Ormai AMD ha puntato sul mercato APU, la concorrenza vecchio stile di CPU è morta.
AMD dipende da GloFo.
steamroller-excavator sono architetture che assorbono certamente di più di bulldozer-piledriver proprio in virtù del CMT meno spinto. Non darei per scontato che sui 32nm possano girare a velocità maggiori di 3,6 GHz o superiore. Proprio excavator che oltre ad avere decoder dedicati, ha una fpu molto più potente potrebbe persino faticare a raggiungere i 3GHz sul SOI (in effetti andrebbe visto come un vero octa-core, l'ipc imho sarà molto diverso).
il bulk 28nm unito alle librerie ad alta densità, per basse frequenze di funzionamento possono simulare le prestazioni di un ipotetico FD-SOI a 22nm, sia a livello di integrazione che di consumi.

celeron 1820 35€
mobo h81 36€

il 5350 se lo pappa a colazione
:mano: :mano:

Peccato che:

1) Il celeron ha tdp di 52watt, il 5350 da 25W, è praticamente fanless ed ha una gpu molto migliore per un utilizzo htpc.
2) Con 35 euro ti fai una scheda socket am1 mini itx, per fare lo stesso con una lga 1150 te ne partono almeno 50.

senza contare che con un po di sbatta puoi occare l'AM1 (praticamente ora con 2 mobo su 3) fino a fargli consumare 50W, e forse a quel punto se la combatte bene con un celeron qualunque

io ho un 5350, se lo paragono a un Pentium 1155 da 60W, non mi pare di aver visto problemani

Peccato che:

1) Il celeron ha tdp di 52watt, il 5350 da 25W, è praticamente fanless ed ha una gpu molto migliore per un utilizzo htpc.

tdp ok ma di fatto un haswell celeron/pentium consuma meno e con ben altre prestazioni

http://www.techspot.com/articles-info/806/bench/Power_01.png
http://www.techspot.com/articles-info/806/bench/Power_02.png
http://www.techspot.com/articles-info/806/bench/Power_03.png

e il celeron ha lo stesso dissi del 4970k per dire e gira appena per raffreddare il celeron

sulla gpu siamo li, forse un pizzico meglio la intel

http://www.techspot.com/review/806-amd-kabini-vs-intel-bay-trail-d/page5.html

sulla cpu ovviamente neanche vale la pena mettere i bench :asd:


2) Con 35 euro ti fai una scheda socket am1 mini itx, per fare lo stesso con una lga 1150 te ne partono almeno 50.

questo è vero ma sono soldi ben spesi secondo me... sono comunque mobo dual channel, possibilità di upgrade fino a i7, southbridge di primo livello, ecc...

senza contare che con un po di sbatta puoi occare l'AM1 (praticamente ora con 2 mobo su 3) fino a fargli consumare 50W, e forse a quel punto se la combatte bene con un celeron qualunque

io ho un 5350, se lo paragono a un Pentium 1155 da 60W, non mi pare di aver visto problemani

non so se è la stessa cosa ma quando ho provato a occare un richland non-K salendo di bus la gpu ha iniziato a fare casini sulla porta vga con desincronizzazioni video perchè sballava la frequenza di refresh...

Abbiamo avuto nell'ordine Bulldozer-piledriver (32nm), steamroller-excavator(28nm), ben 4 generazioni di cpu. Il fallimento dell'architettura francamente non lo vedo, visto che è tutto è andato secondo roadmap, salvo il "piccolo" particolare che steamroller e excavator dovevano essere costruiti con i 22nm fd-soi

Il fatto che sia andato secondo roadmap non vuol dire nulla, tantomeno che sia un'architettura riuscita, visto che per avvicinarsi alle prestazioni di un quad + HT intel ha bisogno di 4 moduli composti ognuno da 2 unità integer e una FPU... ma che devono girare a suppergiù 1 ghz in più.
Inoltre, per fare questo consumano un'accidente di energia. Ok, per utenti comuni non è un problema sula bolletta... ma se vogliamo discutere di bontà o meno del progetto è da tenere in conto, eccome.

Imho con dei phenom II a 32nm con in aggiunta le nuove istruzioni avrebbero ottenuto migliori risultati. O comunque avrebbero ottenuto risultati simili senza però dover sviluppare da zero una nuova architettura. Nonostante i 45nm con henom II sono riusciti ad ottenere dei 6 core a 3,3ghz da 125w di tdp: a 32nm avrebbero potuto tranquillamente fare anche degli 8 core (veri) a frequenze superiori e degli esacore vicini ai 4ghz, restando sempre entro i 125w di tdp e pareggiando in prestazioni gli attuali fx, o magari anche superandoli grazie al maggiore ipc.
Guarda, basta fare due conti della serva guardando qualche review e ammettendo che le prestazioni scalino linearmente: già un 1100T con due core in più (sempre ai suoi 3,3ghz di default), andrebbe suppergiù come un fx 8350 a default (4 ghz).


Per chi parla di Phenom II di ultima architettura riuscita, direi che il 95% delle prestazioni è stato raggiunto dal primo phenom.
Il fallimento commerciale è dovuto al fatto che AMD ha spinto anzitempo i quad-core nativi, sacrificando sia la frequenza complessiva, la resa, l'ipc integrando solo 2mb di cache l3.

Phenom I è nato male e con un processo produttivo che non consentiva di spingersi con la frequenza e di mettere più cache, oltre al bug dello stepping B2. Mi piace considerarlo un po' la versione alpha dei phenom II, che per essere cpu a 45nm hanno fatto faville, specie nelle ultime versioni.

Spero proprio che AMD riesca a tornare ai fasti degli Athlon e dei Phenom II, (tutt'oggi uso con soddisfazione un Phenom II 965), pagato allora una cifra modesta e oggi fa un ottimo lavoro, l'unica cosa che ho dovuto cambiare èil dissipatore stock che cominciava a far rumore. Per il resto è un mulo.
Il predominio totale di Intel lo vedo come una sciagura e se ne vedono i primi effetti, tipo uscire con un processo produttivo in ritardo e una architettura nuova a dispetto di oem e investimenti, alla faccia di tutti e costi decisi con prendere o lasciare.

Ma esattamente cosa me ne faccio una una gpu molto migliore in ottica htpc? :mbe:

1) Hai una qualità video superiore
2) Riesci a gestire correttamente la riproduzione dei film in 24p (le schede intel non ce la fanno e saltano un frame ogni 42 secondi circa)

tdp ok ma di fatto un haswell celeron/pentium consuma meno e con ben altre prestazioni

http://www.techspot.com/articles-info/806/bench/Power_01.png
http://www.techspot.com/articles-info/806/bench/Power_02.png
http://www.techspot.com/articles-info/806/bench/Power_03.png



Io veramente leggo che il sistema con l'8350 consuma 51 watt mentre il celeron 1820 ne consuma 75. Solo il celeron j1900 consuma meno, che in realtà è un Bay Trail (quindi un Atom, ben più moscio di un Haswell) con TDP da 10W per sistemi embedded, tablet e AIO, non è venduto in versione retail e quindi non ti ci puoi assemblare un pc.

in ambito server come va amd?

Intel ha palesemente rallentato da parecchi anni
Non mi pare proprio.
La concorrenza (intel), invece, sta andando col freno a mano tirato, elargendo novità col contagocce,
Come sopra. A sembra che di innovazioni ne abbia portato. Cos'avrebbe dovuto fare?
altrimenti l'antitrust se la monta peggio di rocco.
Ma anche no, specialmente dopo il calo delle vendite dovute all'invasione dei tablet, le cose non stanno più come prima.
E che non inizino i soiti discorsi "l'architettura amd è vincente per il futuro", perchè è da anni che si sente 'sta storia, e di miracoli ancora non se ne sono visti. Anzi, le stesse cose si dicevano del cell della ps3 (vedrete... in futuro... spaccherà culi a destra e a manca...) e sappiamo tutti com'è andata a finire.
Permettimi: ben prima che fosse commercializzata la PS3 c'era chi affermava, fatti e argomentazioni tecniche alla mano, che Cell non era quel mostro che veniva dipinto da IBM, Sony, e Toshiba.

Questo forum è pieno di discussioni dell'epoca, precedenti e successive alla sua commercializzazione, che lo dimostrano ampiamente.

Il problema rimane sempre lo stesso: all'epoca c'era chi, senza adeguato background tecnico, abboccava agli slogan e contribuiva alla diffusione di un mito che, successivamente, si è rivelato per quello che era.

1) Hai una qualità video superiore
2) Riesci a gestire correttamente la riproduzione dei film in 24p (le schede intel non ce la fanno e saltano un frame ogni 42 secondi circa)

Tutte le schede video non gestiscono correttamente il 23.976 , la storia dei 42 secondi e vecchia di 3 anni fà , risolta quasi completamente e non presente sulle versioni iris.

ATI 23.978 +0.002
NVIDIA 23.972 -0.004
INTEL 23.973 -0.003

Non dovrebbero essere conivolta tutta la serie alta prodotto dal 2012 in poi , (geforce 650-680 o radeon hd 7850-7970)

Stesso per la qualità video , le ati di default hanno colori più brillanti sia di intel che di nvidia che a non tutti piacciono , rendendo le immagini spesso troppo artificiali, ma il problema è comunque superabile dato che basta modificare le impostazioni di colore e tonalità nel pannello di controllo per entrambe le vga (ati/nvida/intel)

Tutte le schede video non gestiscono correttamente il 23.976 , la storia dei 42 secondi e vecchia di 3 anni fà , risolta quasi completamente e non presente sulle versioni iris.

ATI 23.978 +0.002
NVIDIA 23.972 -0.004
INTEL 23.973 -0.003

Non dovrebbero essere conivolta tutta la serie alta prodotto dal 2012 in poi , (geforce 650-680 o radeon hd 7850-7970)

Stesso per la qualità video , le ati di default hanno colori più brillanti sia di intel che di nvidia che a non tutti piacciono , rendendo le immagini spesso troppo artificiali, ma il problema è comunque superabile dato che basta modificare le impostazioni di colore e tonalità nel pannello di controllo per entrambe le vga (ati/nvida/intel)

Sulle iris non saprei, però ho letto che con le GT1 e le GT2 ci sono ancora problemi.

E che non inizino i soiti discorsi "l'architettura amd è vincente per il futuro", perchè è da anni che si sente 'sta storia, e di miracoli ancora non se ne sono visti. Anzi, le stesse cose si dicevano del cell della ps3 (vedrete... in futuro... spaccherà culi a destra e a manca...) e sappiamo tutti com'è andata a finire.
Inoltre, chi acquista cpu oggi, le acquista per oggi, non "tra 2 anni va meglio".

Come sopra. A sembra che di innovazioni ne abbia portato. Cos'avrebbe dovuto fare?
Continuare a migliorare le prestazioni come fatto dal 286 in poi (saltando i P4)?
Perché con il 5% all'anno di media non si va molto lontano. Anche per Intel. Non si sorprenda se uno il PC lo tiene 10 anni invece che 4...


Permettimi: ben prima che fosse commercializzata la PS3 c'era chi affermava, fatti e argomentazioni tecniche alla mano, che Cell non era quel mostro che veniva dipinto da IBM, Sony, e Toshiba.

Questo forum è pieno di discussioni dell'epoca, precedenti e successive alla sua commercializzazione, che lo dimostrano ampiamente.

Il problema rimane sempre lo stesso: all'epoca c'era chi, senza adeguato background tecnico, abboccava agli slogan e contribuiva alla diffusione di un mito che, successivamente, si è rivelato per quello che era.
Scusate se il Cell, con processo produttivo non dell'ultima generazione a disposizione, ha permesso di passare la barriera del Petaflop usando 1/3 dell'energia necessaria rispetto al più vicino (e più lento) PC x86 based dell'epoca.
E coadiuvato da processori AMD (ben lungi dall'essere efficienti) come gestori dei nodi (quindi l'efficienza globale sarebbe potuta essere anche più alta).
Che poi il Cel fosse un disastro per quanto riguarda il cervello dei programmatori che si sono trovati a dover gestire molto più che 8 core simmetrici con un OS a cui demandare qualsiasi cosa, allora siamo d'accordo.
Ma definirlo un fallimento, direi no. Ha dimostrato che è possibile andare oltre (e con ottimi risultati) all'idea del core monolitico "faso tuto mi".
Visto che a molti di voi piace parlare di mille mila core da sfruttare contemporaneamente, fatevi solo il conto di quanti Cell (costituiti da 1 core centrale PPC + 8 SPU) ci starebbero in un die odierno a 22nm (non dico a 14, che altrimenti dovreste passare alla calcolatrice).

E scusate se l'architettura del Cell che ha dei DMA e due bus di I/O separati (urca, DMA? Quando mai li vedremo su un x86?) ha permesso alla PS3 di compensare il gap della sua GPU rispetto a quella della XBox360 permettendo di eseguire effetti post processing alla grafica in real time da parte delle SPU. Quando vedremo i potentissimi processori Intel o AMD riuscire a fare lo stesso, allora parleremo (forse) di un passo avanti rispetto al paradigma che ci trasciniamo da trent'anni.
Persino l'Amiga dell'86 era architetturalmente più avanti dei PC che usiamo oggi :rolleyes:
Progresso perché sono stati aggiunte le AVX e le AVX2 in 6 anni di sviluppo con una media di crescita dell'IPC del 5% (forse) annuo... o cosa mi tocca sentire :muro:
Ma va bene così. Questo è sicuramente il miglior progresso che si possa sperare di avere. Almeno ancora si avanza, seppur a passo di lumaca zoppa.

@Crapa di Legno, cioè (odio quelli che iniziano le frasi con "cioè" ma in questo caso ci sta) il tuo intervento che espone la realtà oggettiva dei fatti mi ha messo addosso una tristezza infinita :(

Continuare a migliorare le prestazioni come fatto dal 286 in poi (saltando i P4)?
Se riesci a piegare le leggi della fisica a tuo uso e consumo, sì, si potrebbe continuare a scalare allo stesso modo.
Perché con il 5% all'anno di media non si va molto lontano. Anche per Intel.
Su questo ho già riportato altri dati nell'altro thread.
Non si sorprenda se uno il PC lo tiene 10 anni invece che 4...
E' anche "colpa" del fatto che ormai c'è abbastanza potenza di calcolo per l'ordinaria amministrazione (navigare, leggere mail, chattare, ecc.), mentre per i giochi è divenuta più importante la scheda video, che puoi cambiare abbastanza facilmente mantenendo il resto.
Scusate se il Cell, con processo produttivo non dell'ultima generazione a disposizione, ha permesso di passare la barriera del Petaflop usando 1/3 dell'energia necessaria rispetto al più vicino (e più lento) PC x86 based dell'epoca.
E coadiuvato da processori AMD (ben lungi dall'essere efficienti) come gestori dei nodi (quindi l'efficienza globale sarebbe potuta essere anche più alta).
Che poi il Cel fosse un disastro per quanto riguarda il cervello dei programmatori che si sono trovati a dover gestire molto più che 8 core simmetrici con un OS a cui demandare qualsiasi cosa, allora siamo d'accordo.
Ma definirlo un fallimento, direi no.
Per quello per cui è nato, direi sì: s'è rivelato un fallimento.

Nulla da dire sulle sue capacità di calcolo parallelo & distribuito, ma con un prezzo molto elevato da pagare per poterlo sfruttare adeguatamente.
Ha dimostrato che è possibile andare oltre (e con ottimi risultati) all'idea del core monolitico "faso tuto mi".
Diciamo che non è campato abbastanza per dimostrarlo. Infatti quell'architettura non la ritrovi più già da tempo.
Visto che a molti di voi piace parlare di mille mila core da sfruttare contemporaneamente, fatevi solo il conto di quanti Cell (costituiti da 1 core centrale PPC + 8 SPU) ci starebbero in un die odierno a 22nm (non dico a 14, che altrimenti dovreste passare alla calcolatrice).
Possono essercene molti, ma è difficile farli scalare adeguatamente. Oltre che programmarli.

Soprattutto, Cell è morto perché le GPU gli hanno scavato la fossa. Come, peraltro, avevo predetto ben 5 anni fa (http://www.appuntidigitali.it/5965/perche-sony-mettera-una-pietra-tombale-su-cell/)...
E scusate se l'architettura del Cell che ha dei DMA e due bus di I/O separati (urca, DMA? Quando mai li vedremo su un x86?)
Ci sono già, fin dai tempi dell'8086 (http://en.wikipedia.org/wiki/Intel_8237)...
ha permesso alla PS3 di compensare il gap della sua GPU rispetto a quella della XBox360 permettendo di eseguire effetti post processing alla grafica in real time da parte delle SPU.
Il post processing sulla PS3 era usato spesso per nascondere la bassa risoluzione del rendering effettuato.

Sì, opera di Cell, senz'altro. D'altra parte per questi compiti andava benissimo.
Quando vedremo i potentissimi processori Intel o AMD riuscire a fare lo stesso, allora parleremo (forse) di un passo avanti rispetto al paradigma che ci trasciniamo da trent'anni.
Premesso che questo lavoro lo fanno meglio le GPU, almeno Intel con Xeon Phi ha realizzato qualcosa di meglio di Cell proprio in quest'ambito.
Persino l'Amiga dell'86 era architetturalmente più avanti dei PC che usiamo oggi :rolleyes:
Difatti i PC di oggi, anche di parecchi anni fa, la emulano tranquillamente e molto dell'originale.

A parte questo, mi faresti vedere in che modo l'architettura di Amiga sarebbe meglio di quella PC odierni? Elenca pure, e scendi pure nei dettagli quanto vuoi: conosco discretamente bene le architetture di entrambi, per cui non ho difficoltà a capire.
Progresso perché sono stati aggiunte le AVX e le AVX2
Direi proprio di sì, se sai come sono fatte queste estensioni.
in 6 anni di sviluppo con una media di crescita dell'IPC del 5% (forse) annuo... o cosa mi tocca sentire :muro:
Ti tocca sentire una cosa che è stata smentita nell'altro thread, in cui ho riportato link e numeri.
Ma va bene così. Questo è sicuramente il miglior progresso che si possa sperare di avere. Almeno ancora si avanza, seppur a passo di lumaca zoppa.
Si avanza a colpi di SIMD e core. Che poi sono gli elementi su cui è stato fondato Cell...

Ma esattamente cosa me ne faccio una una gpu molto migliore in ottica htpc? :mbe:

su htpc conta di più il decoder dei flussi video che il framerate dei giochi (che comunque fanno schifo...)

http://www.techspot.com/articles-info/806/bench/Video_03.png

1) Hai una qualità video superiore
2) Riesci a gestire correttamente la riproduzione dei film in 24p (le schede intel non ce la fanno e saltano un frame ogni 42 secondi circa)

vedi link sopra :rolleyes:

Io veramente leggo che il sistema con l'8350 consuma 51 watt mentre il celeron 1820 ne consuma 75. Solo il celeron j1900 consuma meno, che in realtà è un Bay Trail (quindi un Atom, ben più moscio di un Haswell) con TDP da 10W per sistemi embedded, tablet e AIO, non è venduto in versione retail e quindi non ti ci puoi assemblare un pc.

consuma di più sotto bench ma meno in idle

inoltre facendo più lavoro per unità di tempo significa che a pari lavoro svolto il consumo è inferiore

onestamente a meno di volere pc grandi come un NUC eviterei atom...

Come sopra. A sembra che di innovazioni ne abbia portato. Cos'avrebbe dovuto fare?

A me sembra che da un punto di vista puramente prestazionale da sandy bridge in poi non ci siano stati tutti 'sti progressi.
Certo, non ho detto che intel sia stata ferma... cambiamenti ci sono, ma non sono notevoli come in passato, specie al cambio di architettura.

Ma anche no, specialmente dopo il calo delle vendite dovute all'invasione dei tablet, le cose non stanno più come prima.

Eh, insomma... intel, potenzialmente potrebbe immettere sul mercato processori che renderebbero fuori mercato quelli amd... a meno di venderli a prezzo di costo.

Permettimi: ben prima che fosse commercializzata la PS3 c'era chi affermava, fatti e argomentazioni tecniche alla mano, che Cell non era quel mostro che veniva dipinto da IBM, Sony, e Toshiba.

Questo forum è pieno di discussioni dell'epoca, precedenti e successive alla sua commercializzazione, che lo dimostrano ampiamente.

Il problema rimane sempre lo stesso: all'epoca c'era chi, senza adeguato background tecnico, abboccava agli slogan e contribuiva alla diffusione di un mito che, successivamente, si è rivelato per quello che era.

Infatti, era proprio a questi che mi riferivo.

Ormai AMD ha puntato sul mercato APU, la concorrenza vecchio stile di CPU è morta.

quella risata a fine messaggio mi fa riflettere e forse ho capito, vuole la concorrenza di amd cosi puo' acquistare un intel a prezzo piu' basso. sta storia e' vecchia ormai, la gente si fida talmente tanto di amd che non vede l'ora di acquistare intel.

in pratica altri 2 anni con gli Fx :D

Meglio tanto la potenza già c'è ! chissà visto che cpu non aumenteranno di potenza comincino a sfruttare di piu il software.

tanto win 10 e le dx 12 arrivano aggratis

poi giusto prima di zen mi faccio un 5690x , e tiro avanti un altro po di anni :D

Il fatto che sia andato secondo roadmap non vuol dire nulla, tantomeno che sia un'architettura riuscita, visto che per avvicinarsi alle prestazioni di un quad + HT intel ha bisogno di 4 moduli composti ognuno da 2 unità integer e una FPU... ma che devono girare a suppergiù 1 ghz in più.
Sarebbe bene sottolineare il fatto che tra una soluzione HT aumenta il die size del 5% contro il 12% di un CMT. Parliamo del 6,6% di differenza, potremmo dire che la complessità del CMT è pari a quella di un core con un doppio SMT, ben distante dall'avere due core...
Se il CMT fosse stato il problema, secondo te AMD avrebbe fatto 4 revisioni di bulldozer, tanto più che in origine era stato pensato come soluzione con risorse non condivise?
Ti ricordo anche che oltre a girare a 4,5GHz (senza il Resonant Clock Mesh) piledriver doveva avere 10 core. Il processo produttivo sulla carta si è mangiato il 56% delle prestazioni.
PS Il SOI a 32nm, rende meglio ad alte frequenze, come dimostra il fatto
che il 28nm Bulk, fa molto meglio nel mobile con un architettura più assetata sul piano energetico (steamroller).


Imho con dei phenom II a 32nm con in aggiunta le nuove istruzioni avrebbero ottenuto migliori risultati.
Atteniamoci ai fatti. k10 su 32nm non gira ad oltre 3GHz nello stesso TDP in cui Piledriver gira a 4GHz, e in overclock non supera i 3,6GHz. Nel recente passato si è dato la colpa alla natura apu, dimenticandosi presto il tutto quando un a10-5800k poteva superare i 4,5GHz in OC nonostante l'igp.
il confronto piledriver vs k10 su 32nm dimostra chiaramente che bulldozer è un'architettura ben più prestante, o meglio che si adatta meglio alle caratteristiche dei 32nm SOI.

Nonostante i 45nm con henom II sono riusciti ad ottenere dei 6 core a 3,3ghz da 125w di tdp: a 32nm avrebbero potuto tranquillamente fare anche degli 8 core (veri) a frequenze superiori e degli esacore vicini ai 4ghz, restando sempre entro i 125w di tdp e pareggiando in prestazioni gli attuali fx, o magari anche superandoli grazie al maggiore ipc.
Guarda, basta fare due conti della serva guardando qualche review e ammettendo che le prestazioni scalino linearmente: già un 1100T con due core in più (sempre ai suoi 3,3ghz di default), andrebbe suppergiù come un fx 8350 a default (4 ghz).
Ma guarda non darei per scontato che i 45nm low-k siano inferiori al 32nm SOI. Ricordo che i 4GHz con il Resonant Clock Mesh, equivalgono a 3,6GHz sul piano della dissipazione energetica.
Fin dall'uscita di llano, che le prestazioni dei 32nm non mi convincono.
sui 45nm abbiamo avuto Phenom x6 2,8GHz (3,3GHz turbo) in 95W. Con i 32nm teoricamente il TDP doveva scendere a 65W...ci sarebbe stato spazio per deca-core da oltre 3 GHz. Mentre llano consumava tanto a default e peggio in OC nonostante avesse solo 4 core.


Phenom I è nato male e con un processo produttivo che non consentiva di spingersi con la frequenza e di mettere più cache, oltre al bug dello stepping B2. Mi piace considerarlo un po' la versione alpha dei phenom II, che per essere cpu a 45nm hanno fatto faville, specie nelle ultime versioni.
a livello di architettura, a parte il TLB bug, k10 era già maturo con Phenom I. A livello di IPC le prestazioni sono state aumentate per lo più grazie all'integrazione di un maggior quantitativo di cache l3 (la cache di soli 2MB è figlia del limitato livello di integrazione dei 65nm).
Ma è utile osservare che con un solo die shrink, AMD è riuscita a raddoppiare le prestazioni, è come se con il passaggio ad un ipotetico 22nm AMD sarebbe risciuta ad integrare 12 core steamroller a 5GHz nello stesso TDP.

Continuare a migliorare le prestazioni come fatto dal 286 in poi (saltando i P4)?
Perché con il 5% all'anno di media non si va molto lontano. Anche per Intel. Non si sorprenda se uno il PC lo tiene 10 anni invece che 4...


ma cosa ti aspetti? Seriamente.
Poi non è il mancato aumento dell'ipc il problema di non cambiare PC. Per AMD l'ultimo die shrink in ambito desktop l'abbiamo avuto nel 2011, il successivo è previsto nel 2016. 5 anni con lo stesso livello di miniaturizzazione, porta ad uno stallo delle prestazioni non certo indifferente.
Anche Nehalem, che è stato un gigantesco passo in avanti rispetto a Conroe, non ha portato con sé, ad aumenti incredibili rispetto alle soluzioni esistenti da giustificare un cambio di sistema.


Scusate se il Cell, con processo produttivo non dell'ultima generazione a disposizione, ha permesso di passare la barriera del Petaflop usando 1/3 dell'energia necessaria rispetto al più vicino (e più lento) PC x86 based dell'epoca.
cpu interessante, ma imho decisamente superata oggi a livello HW dalle soluzione kaveri.


E coadiuvato da processori AMD (ben lungi dall'essere efficienti) come gestori dei nodi (quindi l'efficienza globale sarebbe potuta essere anche più alta).

era più giusto scrivere x86. Le soluzioni AMD, prima dell'avvento di Nehalem erano di gran lunga più efficienti di quelle Intel.
PS notare come l'apu kaveri sia in grado di triplicare grazie ad HSA l'efficienza come gestore dei nodi, cosa che sulla carta non è un compito adatto alla gpu tantomeno ad una cpu come il CELL.


Progresso perché sono stati aggiunte le AVX e le AVX2 in 6 anni di sviluppo con una media di crescita dell'IPC del 5% (forse) annuo... o cosa mi tocca sentire :muro:
Ma va bene così. Questo è sicuramente il miglior progresso che si possa sperare di avere. Almeno ancora si avanza, seppur a passo di lumaca zoppa.
Le AVX e le AVX2 richiedono fpu di grandi dimensioni (credo che l'idea della condivisione della fpu sia nata in AMD proprio nella prospettiva di fare un uso più efficiente di unità floating point dalla elevata complessità)
Aumento del 5%? Ma tu l'evoluzione hardware la vedi con software obsoleto, (magari 80486 compatibile) o con software in grado di sfruttare fino all'ultima risorsa disponibile?

Detto questo, sono curioso di conoscere l'ipc di excavator. Pronostico un +30% su steamroller, visto che la fpu dovrebbe raddoppiare la potenza

Se riesci a piegare le leggi della fisica a tuo uso e consumo, sì, si potrebbe continuare a scalare allo stesso modo.
Le leggi della fisica dicono che al dimezamento della nanometria usata di quadruplica il numero di transistor integrabili, onde ne viene l'interpretazione della legge di Mooreche dice che ogni 12 mesi (oggi 24) le prestazioni raddoppiano.

A parte questo, mi faresti vedere in che modo l'architettura di Amiga sarebbe meglio di quella PC odierni? Elenca pure, e scendi pure nei dettagli quanto vuoi: conosco discretamente bene le architetture di entrambi, per cui non ho difficoltà a capire.
E lo so che sei esperto dell'architettura Amiga, ma volermi farmi credere che il processore monolitico vecchio di 30 anni nella sua concezione sia meglio del sistema che aveva l'Amiga nell'86, mi sembra davvero troppo.
Quando hai unità specializzate per fare un determinato lavoro, e non un immenso core che tenta di fare tutto, l'efficienza si vede
I PC di oggi emulano l'miga dell'86? Grazie al piffero. Hai per caso calcolato quanto sono più veloci i processori di oggi rispetto all'Amiga dell'86? Ripeto, '86. 30 anni praticamente. Solo per emulare il Copper ci vuole una potenza di calcolo pari a quella di una GPU completa.
E molte altre cose ancora non sono possibili (schermi multipli con risoluzione differente? Scommetto che qui dentro solo pochi hanno avuto la possibilità di vederli).

Ti tocca sentire una cosa che è stata smentita nell'altro thread, in cui ho riportato link e numeri.
L'altro thread non so quale sia. Non vivo all'interno del sito.

Riguardo al DMA... dai, lo sai bene quali sono le limitazioni di quel coso vecchio di 30 anni che mi hai linkato. E spero bene che tu sappai a cosa servono i DMA e quali benefici possono portare. Ma è contro il concetto della CPU monolitica quella di distribuire dati in maniera efficiente verso possibili unità di elaborazione che non siano gli immensi core pensati appunto per fare tutto.

Si avanza a colpi di SIMD e core. Che poi sono gli elementi su cui è stato fondato Cell...
Peccato solo che i SIMD del Cell non erano semplici unità di calcolo "stupide" connesse al solo bus del core dal quale dipendevano al 100%. 1/3 dell'energia con più prestazioni direi che hanno dimostrato di essere ben superiori a stupide unità di calcolo semplicemente ingrandite.
E di core il Cell ne aveva 1. Non 4 o 8. Di che stiamo parlando? Che cosa stai confrontando sullo stesso piano?

Io continuo a pensare che possono sfornare tutte le architetture dell'universo ma se non hanno un supporto dagli oem e le software house non cambia nulla.
Basti vedere mantle e hsa che fine hanno fatto, belli belli ma li hanno usati su 2 giochi il primo e su libreoffice il secondo.
Pc che montano cpu/apu amd? Devi andarteli a cercare.

HSA è una tecnologia inutile in quanto la natura di molte tipologie di applicativi fra cui le più importanti non sono predisposte.

Mantle porta vantaggi là dove c'è il cpu limited, gli altri sono marginali e perchè faticare ad adattare i titoli a Mantle quando con le DX12 diventerà uno standard ?

Non mi pare che AMD ai tempi dell'Athlon64 avesse riscosso poco successo, non ha di certo saputo sfruttare commercialmente il momento al 100% ma se il prodotto c'è le spalle sono coperte, il problema è che non c'è e nonostante ciò continuavano a mentire spudoratamente sulle prestazioni, oltre ai ritardi, all'NDA ( per mascherare lo scempio ) e ora han lasciato campo libero alla concorrenza.

Aumento del 5%? Ma tu l'evoluzione hardware la vedi con software obsoleto, (magari 80486 compatibile) o con software in grado di sfruttare fino all'ultima risorsa disponibile?

No, vivo nel mondo reale, non quello delle favole e delle slide.
Da uno dei pochi siti che oltra a parole mostra anche i numeri:
http://www.anandtech.com/bench/product/287?vs=836
2600K (SB) vs 4770K (HW)
Mancano i bench con HS refresh (inutili, si parla di overclock a discapito del TDP).

No, vivo nel mondo reale, non quello delle favole e delle slide.
Da uno dei pochi siti che oltra a parole mostra anche i numeri:
http://www.anandtech.com/bench/product/287?vs=836
2600K (SB) vs 4770K (HW)
Mancano i bench con HS refresh (inutili, si parla di overclock a discapito del TDP).

Cinebench 11.5 MT :

6.86 vs 8.51

Direi che siamo oltre il 20% in più.

Cinebench 11.5 MT :

6.86 vs 8.51

Direi che siamo oltre il 20% in più.

Guarda il clock... c'è un intero PP di vantaggio+ 2 raffinazioni dell'architettura per Haswell. Direi che siamo al minimo sindacabile (e vale solo per quel test, dato che in altri il risultato è peggiore).

Mi correggo, 1PP e una nuova architettura, non revisione (con una revisione su nuovo PP ci sta un guadagno di quel genere, con una nuova architettura proprio no).

Guarda il clock... c'è un intero PP di vantaggio+ 2 raffinazioni dell'architettura per Haswell. Direi che siamo al minimo sindacabile (e vale solo per quel test, dato che in altri il risultato è peggiore).

Mi correggo, 1PP e una nuova architettura, non revisione (con una revisione su nuovo PP ci sta un guadagno di quel genere, con una nuova architettura proprio no).

contando pure che con un 2600 a parità di raffreddamento si hanno quasi 200 mhz di clockin piu per le temperature il divario è veramente irrisorio ;)

HSA è una tecnologia inutile in quanto la natura di molte tipologie di applicativi fra cui le più importanti non sono predisposte.
Mi spiace smentirti ma praticamente tutti gli applicativi ci sono algoritmi che possono essere accelerati efficientemente dalla gpu, compreso il sistema operativo.
Fino ad oggi l'overhead non ha reso conveniente usare la gpu per accelerare poche, ma costose righe di codice.
HSA quindi al contrario, è una tecnologia estremamente utile, anche se acerba proprio per l'enorme numero di applicativi (e non solo) che possono trarne giovamento.
AMD ha previsto un aumento dell'efficienza di 25x nell'uso tipico in 6 anni considerando oltre i die shrink anche un pesante uso di HSA (con hardware maggiormente evoluto)
http://www.tomshw.it/files/2014/06/immagini_contenuti/57127/amd-apu-2020-05_t.jpg
E proprio per questo che nel consorzio fanno parte i big del settore mobile.

No, vivo nel mondo reale, non quello delle favole e delle slide.
Da uno dei pochi siti che oltra a parole mostra anche i numeri:
http://www.anandtech.com/bench/product/287?vs=836
2600K (SB) vs 4770K (HW)
Mancano i bench con HS refresh (inutili, si parla di overclock a discapito del TDP).
ma bench sintetici dimostrano che Haswell ha una potenza grezza decisamente superiore rispetto a sandy/ivy bridge. Aspettiamo software AVX2 per trarre le dovute conclusioni.
Comunque al cinebench r10 c'è un certo trascurabile +31%, non male per un architettura matura, praticamente a fine ciclo.

Mi spiace smentirti ma praticamente tutti gli applicativi ci sono algoritmi che possono essere accelerati efficientemente dalla gpu, compreso il sistema operativo.
Fino ad oggi l'overhead non ha reso conveniente usare la gpu per accelerare poche, ma costose righe di codice.
HSA quindi al contrario, è una tecnologia estremamente utile, anche se acerba proprio per l'enorme numero di applicativi (e non solo) che possono trarne giovamento.
AMD ha previsto un aumento dell'efficienza di 25x nell'uso tipico in 6 anni considerando oltre i die shrink anche un pesante uso di HSA (con hardware maggiormente evoluto)
http://www.tomshw.it/files/2014/06/immagini_contenuti/57127/amd-apu-2020-05_t.jpg
E proprio per questo che nel consorzio fanno parte i big del settore mobile.
Si ma che cosa in particolare accelera nello specifico ? Quello è per caso una slide AMD ?
In una conversione video o rendering puoi già usare la VGA discreta, mentre nei giochi è marginale o nullo.

E soprattutto perchè investire su una tecnologia che mira a sfruttare una risorsa limitatissima ?
La GPU integrata sarà sempre ridicola di fronte ad una discreta e limitata in quanto non espandibile nè aggiornabile e usata per le fasce dalle basse prestazioni, che quindi non hanno pretese in certi campi.

Sarebbe stata tutta un altra storia se avesse coinvolto in modo efficiente tutto il reparto grafico discreto.

A me sembra che da un punto di vista puramente prestazionale da sandy bridge in poi non ci siano stati tutti 'sti progressi.
Vedi i commenti successivi, in particolare di tuttodigitale, e poi:

http://www.anandtech.com/show/7003/the-haswell-review-intel-core-i74770k-i54560k-tested/6

"Compared to Sandy Bridge, Haswell looks even more impressive. The Core i7-4770K outperforms the i7-2700K by 7 - 26%, with an average performance advantage of 17%."

Inoltre:

"Compared to Nehalem the gains average almost 44%."
Certo, non ho detto che intel sia stata ferma... cambiamenti ci sono, ma non sono notevoli come in passato, specie al cambio di architettura.
Se per passato ti riferivi all'era precedente al Pentium 4, è vero, ma perché a un certo punto non è stato più possibile salire in frequenza come prima, causa limiti intrinseci della fisica, e quelli non li può superare nemmeno Intel.
Eh, insomma... intel, potenzialmente potrebbe immettere sul mercato processori che renderebbero fuori mercato quelli amd... a meno di venderli a prezzo di costo.
Scusami, ma Intel ha tantissimi modelli e copre tutte le fasce di mercato, incluse alcune per le quali AMD non ha nulla da proporre. Cos'altro dovrebbe presentare?

A parte il fatto che ogni modello addizionale significa costi aggiuntivi (e non di poco) per l'azienda.
Infatti, era proprio a questi che mi riferivo.
Volevo sottolineare che le analisi, all'epoca, sono state fatte da professionisti del settore, ma sono rimaste praticamente inascoltate dalla massa, che ha continuato ad abboccare alla propaganda, alimentando il mito e continuando ad aspettare le meraviglie che sarebbero dovuto uscire fuori da Cell.
sui 45nm abbiamo avuto Phenom x6 2,8GHz
Hum... :fiufiu: :D
Le leggi della fisica dicono che al dimezamento della nanometria usata di quadruplica il numero di transistor integrabili, onde ne viene l'interpretazione della legge di Mooreche dice che ogni 12 mesi (oggi 24) le prestazioni raddoppiano.
Non ci siamo proprio. La superficie occupata si dimezza nell'arco di 12-24 mesi (12 mesi nel primo periodo, quando è stata originariamente formulata; successivamente è stata "aggiustata" a 24 mesi a causa della variazione di tendenza rilevata). Di conseguenza cui il numero di transistor impacchettabili raddoppia a parità area occupata.

Ma NON si riferisce alla "potenza", per la quale poi servirebbe una metrica, tra l'altro, e vorrei proprio vedere cosa si dovrebbe usare in merito.

Ciò precisato, tale legge si riferisce esclusivamente ai transistor. Nulla dice, infatti, tutte le problematiche a cui si incontro riducendo la dimensione dei transistor, e che sono la causa per cui i processori hanno sostanzialmente smesso di scalare in frequenza nell'ultima decina d'anni. Siamo passati dai 4,77Mhz degli 8086 ai 4,4Ghz (in turbo) del mio Devil's Canyon, con un aumento di quali 1000 volte in poco più di 35 anni, e adesso siamo al palo.

Ecco perché la situazione non è più florida come una volta. Ma se qualcuno ha la bacchetta magica a disposizione, può farci vedere come fare a mantenere i ritmi del passato coi limiti fisici attuali...
E lo so che sei esperto dell'architettura Amiga,
Già. E, dunque, dovresti aver capito che sarebbe meglio parlare esclusivamente di cose che si conoscono. Bene.
ma volermi farmi credere che il processore monolitico vecchio di 30 anni nella sua concezione sia meglio del sistema che aveva l'Amiga nell'86, mi sembra davvero troppo.
Intanto ritorni con questa storia del processore "monolitico", che non esiste nella letteratura informatica. Cortesemente, potresti almeno fornire una definizione e quali precisi requisiti dovrebbe avere un siffatto oggetto?

Ciò precisato, stai confrontando mele con pere. Un processore, l'8086 (vabbé, all'epoca dell'introduzione dell'Amiga c'erano già gli 80286 e gli 80386, ma al momento sorvoliamo su questi dettagli, sebbene abbiano un peso non indifferente nelle valutazioni da effettuare quando si confrontano dei sistemi), con un'intera piattaforma hardware, l'Amiga. Non ha alcun senso.

Ma andiamo avanti.
Quando hai unità specializzate per fare un determinato lavoro, e non un immenso core che tenta di fare tutto, l'efficienza si vede
Perdonami, ma un 8086 integra MENO DELLA META' dei transistor del 68000 usato nell'Amiga:
http://en.wikipedia.org/wiki/Transistor_count

Dunque di quale "immenso" core parli?
I PC di oggi emulano l'miga dell'86? Grazie al piffero. Hai per caso calcolato quanto sono più veloci i processori di oggi rispetto all'Amiga dell'86?
Dipende dal software che fai girare nell'ambiente emulato. Diciamo nell'ordine delle centinaia di volte più veloci.
Ripeto, '86. 30 anni praticamente. Solo per emulare il Copper ci vuole una potenza di calcolo pari a quella di una GPU completa.
ROFL. Ti rendi conto dell'assurdità che hai riportato? Il Copper è un processore RISC a 7,09Mhz (7,16 per la versione NTSC), che esegue istruzioni lunghe 2 word a 16-bit, e siccome caricare una word richiede 2 cicli di clock, vuol dire che TEORICAMENTE (molto teoricamente) potrebbe eseguire 1,77 milioni di istruzioni al secondo. In realtà sono la metà, perché può accedere alla memoria soltanto ogni 2 cicli di clock, e dunque arriviamo a 886 MILA (!!!) istruzioni al secondo (TEORICHE!).

Considerato che le sole TRE istruzioni che esegue hanno un formato semplicissimo, la loro decodifica è veramente banale per un emulatore.

Tirando le somme, UN solo stream processor di una GPU, che gira con clock di circa 3 ordini di grandezza superiore, è perfettamente in grado di emulare il funzionamento del Copper, e avanza pure tantissima potenza di calcolo.

Per cui... che stai a dire?!?
E molte altre cose ancora non sono possibili (schermi multipli con risoluzione differente? Scommetto che qui dentro solo pochi hanno avuto la possibilità di vederli).
E ancora meno sanno come funzionano, te incluso, visto che visualizzare tanti schermi con risoluzione differente era possibile ESCLUSIVAMENTE usando risoluzioni che erano multipli esatti (potenze di due) della frequenza video "base" (il volgare segnale televisivo: PAL, NTSC, o SECAM).

In soldini, NON potevi visualizzare uno schermo PAL contemporaneamente a uno VGA (a partire dal chipset ECS), tanto per fare un esempio. Ma anche rimanendo all'interno degli schermi tutti basati sul segnale televisivo, c'erano delle problematiche irrisolvibili, come ad esempio il fatto che se uno degli n schermi era in modalità interlacciata, allora anche tutti gli altri erano costretti a essere interlacciati (anhe se non lo erano).

Questo giochetto degli schermi multipli era, quindi, possibile soltanto in un preciso contesto: sfruttando il segnale televisivo.
L'altro thread non so quale sia. Non vivo all'interno del sito.
Quello che hai abbandonato. Comunque vedi sopra: ho copia & incollato link e informazioni, anche se mi trovo d'accordo con tuttodigitale.
Riguardo al DMA... dai, lo sai bene quali sono le limitazioni di quel coso vecchio di 30 anni che mi hai linkato. E spero bene che tu sappai a cosa servono i DMA e quali benefici possono portare.
Io sì che lo so. Ma tu, invece, lo sai? O per caso sei convinto che ancora oggi sia la CPU a occuparsi di copiare manualmente i dati da o verso una qualunque delle periferiche?
Ma è contro il concetto della CPU monolitica quella di distribuire dati in maniera efficiente verso possibili unità di elaborazione che non siano gli immensi core pensati appunto per fare tutto.
Premesso che il concetto di CPU "monolitica" in letteratura (informatica) non esiste, e dunque aspetto quanto meno una definizione, di quali "immensi core" stai parlando? Pensi che oggi un'ipotetica CPU della famiglia 68000 non sarebbe ciocciottella come quelle di Intel, AMD, e in generale di tutti i produttori di processori?

Ma, soprattutto, non hai notato che la CPU è coadiuvata da diversi coprocessori a cui scarica tanto lavoro?
Peccato solo che i SIMD del Cell non erano semplici unità di calcolo "stupide" connesse al solo bus del core dal quale dipendevano al 100%.
In realtà, tolto l'avvio, potevano tranquillamente essere indipendenti al 100% dal core PowerPC. L'hai mai aperto il manuale dell'architettura di Cell? Sai cosa significhi modello SPE-Centric? Mi pare proprio di no, da quello che hai appena scritto....
1/3 dell'energia con più prestazioni direi che hanno dimostrato di essere ben superiori a stupide unità di calcolo semplicemente ingrandite.
Scusami, superiori in cosa?
E di core il Cell ne aveva 1. Non 4 o 8.
Veramente ne aveva proprio 8: 1 core PowerPC + 7 core SPE. Questo per la versione Playstation 3. Alcune versioni usate da IBM ne avevano 9 (1 + 8).
Di che stiamo parlando? Che cosa stai confrontando sullo stesso piano?
Me lo chiedo anch'io, a questo punto, alla luce di tutte le cose sbagliate che hai scritto...
Mi spiace smentirti ma praticamente tutti gli applicativi ci sono algoritmi che possono essere accelerati efficientemente dalla gpu, compreso il sistema operativo.
Non è così. Non propagandiamo cose che non sono vere. Puoi accelerare lo scheduling dei processi/thread di una CPU? Il gestore della memoria? Il filesystem? Le primitive di sincronizzazione? E così via.

Ci sono sicuramente ambiti in cui è possibile sfruttare la potenza di calcolo di una GPU, questo nessuno lo nega, ma non sono universali.
Fino ad oggi l'overhead non ha reso conveniente usare la gpu per accelerare poche, ma costose righe di codice.
HSA quindi al contrario, è una tecnologia estremamente utile, anche se acerba proprio per l'enorme numero di applicativi (e non solo) che possono trarne giovamento.
Ma bisogna riscrivere il codice per poterne fare uso, e questo non è certo cosa semplice.

Tra l'altro scrivere codice appositamente per HSA non è conveniente per una software house, perché significherebbe farlo esclusivamente per una piccola quota di mercato: soltanto per i processori AMD. Mentre la tendenza è quella di spendere risorse per coprire la maggioranza del mercato, che è rappresentata da processori Intel.
AMD ha previsto un aumento dell'efficienza di 25x nell'uso tipico in 6 anni considerando oltre i die shrink anche un pesante uso di HSA (con hardware maggiormente evoluto)
http://www.tomshw.it/files/2014/06/immagini_contenuti/57127/amd-apu-2020-05_t.jpg
E proprio per questo che nel consorzio fanno parte i big del settore mobile.
Sì, ma non sono i big del consorzio che devono impiegare le risorse per riscrivere il software in modo da fruttarlo.
ma bench sintetici dimostrano che Haswell ha una potenza grezza decisamente superiore rispetto a sandy/ivy bridge. Aspettiamo software AVX2 per trarre le dovute conclusioni.
Comunque al cinebench r10 c'è un certo trascurabile +31%, non male per un architettura matura, praticamente a fine ciclo.
Assolutamente d'accordo. Purtroppo ci vorrà tempo prima che le applicazioni, per lo meno le più diffuse, saranno ricompilate per sfruttare almeno in parte AVX e AVX2.

Si ma che cosa in particolare accelera nello specifico ? Quello è per caso una slide AMD ?
In una conversione video o rendering puoi già usare la VGA discreta, mentre nei giochi è marginale o nullo.

E soprattutto perchè investire su una tecnologia che mira a sfruttare una risorsa limitatissima ?
La GPU integrata sarà sempre ridicola di fronte ad una discreta e limitata in quanto non espandibile nè aggiornabile e usata per le fasce dalle basse prestazioni, che quindi non hanno pretese in certi campi.

Sarebbe stata tutta un altra storia se avesse coinvolto in modo efficiente tutto il reparto grafico discreto.
La gpu integrata seppur è una frazione di quella discreta, ha una potenza di elaborazione nettamente maggiore a quella dei core x86, 737 GFlops dei 853 di kaveri sono dovute alla gpu, mentre il rapporto consumo energetico è circa 25-75,
quindi se si danno i giusti dati la gpu è in grado di superare di un fattore 20 la cpu quando si parla di potenza per watt.

Hai fatto l’esempio della conversione video come applicazione adatta alla gpu.
Test alla mano in simili applicazioni, spesso si ha una migliore prestazione per watt con i core x86, segno che il codice ha alcune parti indigeste per la gpu. e nonostante che per buona parte sia praticamente perfetto per le schede grafiche.

Il problema è che la gpu ha bisogno di lavorare su un grandissimo numero di dati (e le matrici del encoding video sono l’ideale), ma i salti sono deletieri ai fini della prestazione.
Almeno di non fare calcoli pesantissimi, che occupano le gpu per migliaia di cicli di clock nell’elaborazione dati tra un salto e il successivo, penso al rendering, non si può non tener conto della penalità dovuta al salto. In questo caso è praticamente assicurato uno stallo visto che le gpu non prevedono predizione rami o esecuzione speculativa.

Le cpu per farti un esempio sbagliano predizione solo nel 5% dei casi, e nonostante ciò le architetture a pipeline lunghe, vedi bulldozer, possono diventare lente. E parliamo di cpu che girano a 4GHz e hanno un quantitativo enorme di cache. Oltre ad essere molto più frequenti sono anche più dannosi per la relativa lentezza delle gpu. Senza contare che le cache memory hanno cicli assurdi di circa 100-300 cicli.

La cosa da fare è banalmente quella di far eseguire la porzione di codice più adatta ad essere elaborata dalla cpu o dalla gpu. Il primo fattore limitante è il dialogo (o meglio, il non dialogo) tra cpu e gpu. Con la gpu in forma discreta e con il collegamento pci express non è possibile una manipolazione dei dati diretta dei core x86 e gli sp-gcn. Questa avviene con la copia, che ha un costo computazionale tanto elevato da rendere non conveniente il trasferimento delle mansioni tra gpu e cpu. hUMA annulla le distanze sia fisiche che linguistiche: ovvero possono accedere allo stesso address bus e i dati sono coerenti.

Tutto risolto? Ma neanche per sogno.
Risolti i problemi dovuti al linguaggio c’è quello della velocità. La gpu è troppo lenta per rendersi operativa. Bisogna usare dei metodi che consentono di nascondere le latenze.
La prima soluzione è quella creare una cache che metta in comunicazione gpu e cpu. Soluzione necessaria per i quad core figuriamoci con 12.
La seconda che farà il suo debutto con Carrizo: la preemption. Il sistema è di tipo fine-grained, lo scambio di contesto avviene senza cicli di clock di stallo. Questa tecnica riduce le latenze dovute alla dipendenza dei dati e può mascherare in modo efficace lo svuotamento delle pipeline della gpu.

E proprio in virtù del fatto che è davvero complicato dire senza analisi dei costi quanto possa essere efficiente un applicazione su cpu eterogenee, con onesta intellettuale per quel poco che ho potuto studiare, posso dirti che i moltissimi software di uso comune sono presenti algoritmi ad elevato costo computazionale che fanno ampio uso di vettori. Potenzialmente si, il calcolo eterogeneo è il futuro ma kaveri e GCN rappresentano solo un punto di partenza e non certo d’arrivo.
La possibilità di accelerare milioni di apps c'è (o almeno così recita l'ennesima slide di AMD). Ma non oggi, ma con l'hardware di domani e con il software di settimana prossima (spero che si sia capito il senso).

Non solo dalle slide, ma magari anche di qualche ingegnere di AMD che frequenta il forum. :fiufiu: :D A parte gli scherzi, non ci sarebbe nulla di male; anzi, sarebbe molto interessante poter scambiare quattro chiacchiere con persone altamente qualificate. Quel che conta, come recito da tempo, dovrebbero essere sempre i fatti e le argomentazioni esposte, anche se è difficile farlo capire a tanti utenti che si devono per forza scannare per la loro "squadra" del cuore.

Comunque è tutto chiarissimo e ampiamente condivisibile, ma quella tecnologia si deve anche diffondere. :)

Che una GPU abbia grande potenza di elaborazione nei calcoli in virgola mobile è lapalissiano, dato che ha un'architettura differente rispetto ad una CPU "classica".
Ma non sempre (almeno ad oggi, se non mi sono perso nulla) è conveniente spostare i calcoli su GPU, visto che si deve anche tener conto della copia host-to-device e device-to-host.

Detto ciò, una tecnologia (hw e sw) può essere buona o potenzialmente utile quanto si vuole, ma senza diffusione, rimane del tutto inutile.

AMD nelle sue APU ha proprio eliminato il problrma della copia con huma e hsa.

Il problema è che vista la scarsa diffusione di apu kaveri che al momento sono le uniche che sfruttano hsa, visto lo scarso peso commerciale di amd e viste il considerevole peso commerciale di intel suo concorrente, tutta questa tecnologia è stata un po' accantonata.

Ammetto di non essere molto informato sul livello attuale delle APU AMD, ma, secondo me, i vantaggi della parallelizzazione del calcolo su GPU si notano principalmente quando questo diventa "intensivo".

La gpu integrata seppur è una frazione di quella discreta, ha una potenza di elaborazione nettamente maggiore a quella dei core x86, 737 GFlops dei 853 di kaveri sono dovute alla gpu, mentre il rapporto consumo energetico è circa 25-75,
quindi se si danno i giusti dati la gpu è in grado di superare di un fattore 20 la cpu quando si parla di potenza per watt.

Hai fatto l’esempio della conversione video come applicazione adatta alla gpu.
Test alla mano in simili applicazioni, spesso si ha una migliore prestazione per watt con i core x86, segno che il codice ha alcune parti indigeste per la gpu. e nonostante che per buona parte sia praticamente perfetto per le schede grafiche.

Il problema è che la gpu ha bisogno di lavorare su un grandissimo numero di dati (e le matrici del encoding video sono l’ideale), ma i salti sono deletieri ai fini della prestazione.
Almeno di non fare calcoli pesantissimi, che occupano le gpu per migliaia di cicli di clock nell’elaborazione dati tra un salto e il successivo, penso al rendering, non si può non tener conto della penalità dovuta al salto. In questo caso è praticamente assicurato uno stallo visto che le gpu non prevedono predizione rami o esecuzione speculativa.

Le cpu per farti un esempio sbagliano predizione solo nel 5% dei casi, e nonostante ciò le architetture a pipeline lunghe, vedi bulldozer, possono diventare lente. E parliamo di cpu che girano a 4GHz e hanno un quantitativo enorme di cache. Oltre ad essere molto più frequenti sono anche più dannosi per la relativa lentezza delle gpu. Senza contare che le cache memory hanno cicli assurdi di circa 100-300 cicli.

La cosa da fare è banalmente quella di far eseguire la porzione di codice più adatta ad essere elaborata dalla cpu o dalla gpu. Il primo fattore limitante è il dialogo (o meglio, il non dialogo) tra cpu e gpu. Con la gpu in forma discreta e con il collegamento pci express non è possibile una manipolazione dei dati diretta dei core x86 e gli sp-gcn. Questa avviene con la copia, che ha un costo computazionale tanto elevato da rendere non conveniente il trasferimento delle mansioni tra gpu e cpu. hUMA annulla le distanze sia fisiche che linguistiche: ovvero possono accedere allo stesso address bus e i dati sono coerenti.

Tutto risolto? Ma neanche per sogno.
Risolti i problemi dovuti al linguaggio c’è quello della velocità. La gpu è troppo lenta per rendersi operativa. Bisogna usare dei metodi che consentono di nascondere le latenze.
La prima soluzione è quella creare una cache che metta in comunicazione gpu e cpu. Soluzione necessaria per i quad core figuriamoci con 12.
La seconda che farà il suo debutto con Carrizo: la preemption. Il sistema è di tipo fine-grained, lo scambio di contesto avviene senza cicli di clock di stallo. Questa tecnica riduce le latenze dovute alla dipendenza dei dati e può mascherare in modo efficace lo svuotamento delle pipeline della gpu.

E proprio in virtù del fatto che è davvero complicato dire senza analisi dei costi quanto possa essere efficiente un applicazione su cpu eterogenee, con onesta intellettuale per quel poco che ho potuto studiare, posso dirti che i moltissimi software di uso comune sono presenti algoritmi ad elevato costo computazionale che fanno ampio uso di vettori. Potenzialmente si, il calcolo eterogeneo è il futuro ma kaveri e GCN rappresentano solo un punto di partenza e non certo d’arrivo.
La possibilità di accelerare milioni di apps c'è (o almeno così recita l'ennesima slide di AMD). Ma non oggi, ma con l'hardware di domani e con il software di settimana prossima (spero che si sia capito il senso).
Concettualmente però HSA pone come logica l'avere una GPU dedicata per la CPU, oltre a quelle discrete, perchè diversamente vanificheresti tutto ogni qual volta la GPU sia impegnata in altro.

Un altra cosa sarebbe stata quella di integrare l'x86 direttamente anche con le soluzioni discrete qualunque sia la configurazione.

Ho fatto l'esempio della conversione video mi dici e tu mi hai fatto notare che alcune righe di codice non godono della giusta predisposizione a tale esecuzione, ok ma con HSA sarai sempre limitato da una GPU ridicola.

Ascolta, discutere con te diventa sempre più difficile perché il tuo intento non è fare una disciussione decente ma solamente fare inutile polemica e confuzione.

"Compared to Sandy Bridge, Haswell looks even more impressive. The Core i7-4770K outperforms the i7-2700K by 7 - 26%, with an average performance advantage of 17%."
Cacchio, 17% in più.
Vediamo... AMD/nvidia escono con una GPU nuova quest'anno a 16nm e scopriamo che va il 17% in più di Tahiti/GK110. Huhu!!!!! Squilli di tromba e rulli di tamburi a festa.

Non ci siamo proprio. La superficie occupata si dimezza nell'arco di 12-24 mesi (12 mesi nel primo periodo, quando è stata originariamente formulata; successivamente è stata "aggiustata" a 24 mesi a causa della variazione di tendenza rilevata). Di conseguenza cui il numero di transistor impacchettabili raddoppia a parità area occupata.

Ma NON si riferisce alla "potenza", per la quale poi servirebbe una metrica, tra l'altro, e vorrei proprio vedere cosa si dovrebbe usare in merito.
Infatti ho detto "interpretazione". M sembra di aver scritto giusta la legge, o sbaglio? Allora perché sindachi sulla questione?

Ciò precisato, tale legge si riferisce esclusivamente ai transistor. Nulla dice, infatti, tutte le problematiche a cui si incontro riducendo la dimensione dei transistor, e che sono la causa per cui i processori hanno sostanzialmente smesso di scalare in frequenza nell'ultima decina d'anni. Siamo passati dai 4,77Mhz degli 8086 ai 4,4Ghz (in turbo) del mio Devil's Canyon, con un aumento di quali 1000 volte in poco più di 35 anni, e adesso siamo al palo.
A me sembra ch ein altri campi il problema non si pone.. Solo Intel e l'archiettura x86 ha questi problemi. Forse perché anche se la densità raddoppia per via dei costi l'area non è rimasta uguale e quindi con i nuovi PP non si può realmente avere il doppio dei transistor sul die?

Dunque di quale "immenso" core parli?
Quello che oggi ha una CPU x86 dopo essere passata da 4, 5, 6 revisioni (ho perso il conto) dell'ISA?

Poi pargonare un 8086 a 16bit con un 68000 a 32 bit con il triplo dei registri D+A general purpose usabili senza vincoli (a parte 1), con indirizzamento di memoria flat già dall'origine..

ROFL. Ti rendi conto dell'assurdità che hai riportato? Il Copper è un processore RISC a 7,09Mhz (7,16 per la versione NTSC), che esegue istruzioni lunghe 2 word a 16-bit, e siccome caricare una word richiede 2 cicli di clock, vuol dire che TEORICAMENTE (molto teoricamente) potrebbe eseguire 1,77 milioni di istruzioni al secondo. In realtà sono la metà, perché può accedere alla memoria soltanto ogni 2 cicli di clock, e dunque arriviamo a 886 MILA (!!!) istruzioni al secondo (TEORICHE!).

Tirando le somme, UN solo stream processor di una GPU, che gira con clock di circa 3 ordini di grandezza superiore, è perfettamente in grado di emulare il funzionamento del Copper, e avanza pure tantissima potenza di calcolo
Ti manca un particolare... il tuo bellissimi immenso super powa chip di emulazione non è collegato al segnale video e non può sincronizzarsi con esso, per cui sei costretto a lavorare sull'immagine nel frame buffer, con un frame di ritardo. Non è un caso che il Coper, già proprio quel coso da 3 istruzioni a 16 bit, sia stato uno deigli scogli maggiori da superare nell'emulazione. E molti giochi che lo usavano in maniera "creativa" hanno richiesto diverso tempo per poter girare in maniera decente quando emulati.
Certo, con 1000 volte la potenza di calcolo del sistema origianale, direi che si possa emularlo in maniera quasi esatta.

E ancora meno sanno come funzionano, te incluso, visto che visualizzare tanti schermi con risoluzione differente era possibile ESCLUSIVAMENTE usando risoluzioni che erano multipli esatti (potenze di due) della frequenza video "base" (il volgare segnale televisivo: PAL, NTSC, o SECAM).

In soldini, NON potevi visualizzare uno schermo PAL contemporaneamente a uno VGA (a partire dal chipset ECS), tanto per fare un esempio. Ma anche rimanendo all'interno degli schermi tutti basati sul segnale televisivo, c'erano delle problematiche irrisolvibili, come ad esempio il fatto che se uno degli n schermi era in modalità interlacciata, allora anche tutti gli altri erano costretti a essere interlacciati (anhe se non lo erano).
Le limitazioni c'erano, ovvio. Ma trascuri sempre quello che non ti fa comodo.. ragazzo, stiamo parlando del '86, quando il PC aveva 16 colori e risoluzione fissa a 800x600 con una potenza di calcolo che oggi un orologio digitale supera di brutto... eppure tutto quello era possibile.
Perché? Semplicemente perché si usavano unità di elaborazione specializate per ogni lavoro.

Cosa è una CPU monolitica? Quella che fa eseguire tutti i lavori alle stesse (limitate in numero) unità non specializzate. Che diventano sempre più elefantiache per migliorare il throughtput (cache dati/istruzioni enormi, predizioni di salti, cache interne per evitare doppie decodifiche che COSTANO su x86).

Quello che hai abbandonato.
I thread non sono discussioni infinite in cui uno continua a dire le stesse cose. Se per te avere ragione vuol dire postare l'ultimo messaggio, fai pure.

Io sì che lo so. Ma tu, invece, lo sai?
No ho idea, sai. Io ci sviluppo con le architetture che usano DMA con16 canali indipendenti e hanno 8 ALU con capacità diverse a seconda del compito da svolgere, con la capacità di riempire tutte e 8 le unità di calcolo... già, il DMA dell'8086, che grande cosa che sia in uso ancora oggi...

Ma, soprattutto, non hai notato che la CPU è coadiuvata da diversi coprocessori a cui scarica tanto lavoro?
A parte la FPU/unità AVX, potresti cortesemente elencarmi i coprocessori interni alle moderne CPU x86 che collaborano con le "classiche" ALU, per favore?
Stai parlando delle unità per fare de/crypting?


In realtà, tolto l'avvio, potevano tranquillamente essere indipendenti al 100% dal core PowerPC. L'hai mai aperto il manuale dell'architettura di Cell? Sai cosa significhi modello SPE-Centric? Mi pare proprio di no, da quello che hai appena scritto....
Questo è quello che dicevo. Vuoi solo far polemica e non ti intessa capire quello che l'altro scrive.
Rileggi quello che ho scritto. Rileggilo ancora. Poi un'altra volta.
E forse arrivi a capire che quello che tu hai scritto è lo stesso che ho detto io.

Certo che ho aperto un manuale Cell. E certo che so come funzionano sia l'unità centrale che le SPE. Ma a quanto pare anche se a te non mancano le capacità di capire i manuali tecnici hai seri problemi a capire la lingua italiana.

Veramente ne aveva proprio 8: 1 core PowerPC + 7 core SPE. Questo per la versione Playstation 3. Alcune versioni usate da IBM ne avevano 9 (1 + 8).
In verità le SPE non puoi considerarle core veri e propri perché mancano loro una serie di caratteristiche basilari, tipo appunto che senza un core che li inizializza, ne programmi il funzionamento e li coordini non li puoi usare. Sono avanzatissime unità di calcolo affiancati al core centrale. Mordernissimi coprocessori. Non certo core a tutti gli effetti come lo sono quelli Intel o quelli AMD.
Quindi i core del Cell sono 1 (dual thread) che governa 8 unità di calcolo avanzate. Che è cosa ben diversa da avere 3 core PPC, come per esempio sullo Xenon della XBox360. Infatti sono due architetture completamente diverse con carateristiche diverse e capacità di calcolo diverse. E il Cell ha dimostrato, se correttamente programmato, di essere decisamente molto più potente della versione con 3 core PPC. Certo, con un Cell non basta scrivere fork() e avere un thread in esecuziuone parallela.

E magari, se non lo sai, il PowerXCell 8i di IBM è leggermente diverso dal Cell della Playstation, non solo per il numero di SPE attive, ma proprio per le capacità di calcolo delle SPE stesse.

E tutto ciò non infica quanto detto prima: 1 Petaflop con 1/3 dell'energia di un sistema con architettura x86. Con senza usare l'utlimo PP disponibile...

Me lo chiedo anch'io, a questo punto, alla luce di tutte le cose sbagliate che hai scritto...
Io mi chiedo che senso ha discutere con te invece che non fai altro che fare accuse, minacce e a distorcere il pensiero degli altri a tuo uso e consumo.
Ora vado che ho ben altro a cui pensare

No hsa è pensato anche per usi brevi come il caricamente di immagini e simili.
È proprio questa una delle grosse differenze tra hsa e openCL/cuda.



Si HSA pone come logica di avere la GPU dedicata per HSA.
Infatti è (o devo dire "era"?) prevista una configurazione xfire dove la discreta si occupa della grafica e l'IGP si occupa di HSA.
Chiaramente non penso ci siano grossi problemi a usare l'IGP per entrambe le cose in applicazioni che non impiegano grafica 3D come conversioni video o cose del genere, questa configurazione servirebbe per cose come giochi o cad e simili.
Ma si parla di teoria fino a quando qualcuno non sviluppa un gioco compatibile HSA... ma anche AMD non può mettere un povero cristo a sviluppare un cavolo di demo giusto per dimostrare che funziona?

L'IGP dovrà essere adeguata alla potenza della CPU, lo è? Non lo sappiamo perchè HSA non lo usa nessuno e quindi è difficile trarre conclusioni.
Comunque non avrebbe senso fare una APU con IGP enorme da usare per lavori molto pesanti, ha più senso un IGP medio/piccola per accellerare la CPU senza però occupare troppo spazio.
Poi per i lavori particolarmente gravosi si continuerà ad usare la discreta, ma parliamo di configurazioni particolari che interessano ben pochi utenti.
Gli impieghi che l'utenza esigente guarda son le conversioni, il rendering, i giochi ed anche il folding, indipendentemente se queste centrino o meno con la tecnologia discussa.

Queste mansioni o chi ha pretese a riguardo sono utenze di fasce più elevate delle APU, anche se HSA fosse supportato adeguatamente nessuno si prenderebbe una cpu di fascia bassa, sarebbero tutti quanti più interessati invece ad avere un sistema meno vincolato dove posso abbinare la CPU che voglio con la GPU che voglio.

Non ci sono problemi ad utilizzare IGP e VGA ? Ok questo vuol dire avere prima di tutto una logica che comprende il dover gestire 2 sezioni GPU ben distinte ( una è l'IGP e l'altra sono tutte le VGA che hai su slot ), quando utilizzi l'IGP per un applicativo lascia ferma la discreta che invece ha un enormità di potenza in più.

Di certo molto meno con applicativi di minore entità come l'apertura di un foglio elettronico o di un elaborazione con photoshop o una decompressione di un compresso, non sono mansioni attorno a cui puoi avere delle pretese ( a parte qualche eccezione ).






E' comunque meglio di una qualunque FPU dici ? Per ora è possibile ma di certo nessuno investirebbe su una soluzione il cui concetto di funzionamento è vincolato già sul nascere e sviluppato non come miglioramento della gpu ma come una soluzione espressamente indicata su prodotti compatti a basso costo ( in quanto non si possono integrare CPU e IGP di grosse dimensioni causa limiti fisici ), oltre che il dover separare in 2 la sezione GPU. Altrimenti anche Intel e Nvidia avrebbero sviluppato ciascuna una loro versione.

Le utenze sopracitate non cercano soluzioni limitate, vogliono sia cpu che gpu potenti ( in relazione alla generazione presente sul mercato )

Invece Nvidia e Intel a pare invece che loro stiano lavorando appunto su un miglioramento fra l'interazione VGA e CPU specie in ambito GPU computing.
Per quel che riguarda le proporzioni, teoricamente esistono fino ad un certo punto, entrambi possono sempre essere colli di bottiglia l'uno dell'altro a seconda dell'applicativo, quindi avere una GPU o CPU più potente non è mai sconveniente.

Il problema di HSA e derivati è al questione "astrazione". Uno può avere la migliore tecnologia per eseguire il calcolo eterogenero come meglio si può, ma se ti tocca sudare sangue per eseguire uno stupido algoritmoo di ordinamento sulle unità di supporto invece che sulla ALU della CPU, uno non è incentivato a fare tale algoritmo sapendo che quello che usa la ALU deve farlo comunque per supportare anche chi quelle (sottolineo quelle, perché magari ne ha altre migliori, peggiori ma comunque diverse) unità di calcolo non le ha.
Il Cell, di cui si parlava, ha avuto proprio questo problema. Non è che non fosse in grado di fare calcoli a manetta o eseguire algoritmi complessi pure in maniera sofisticata che una CPU+GPU non può nemmeno sognarsi (tipo mettere le SPE in cascata e lasciarle lavorare autonomamente senza che il core centrale dovesse fare alcunché). Ma la complessità per ottenere certi risultati diventa un ostacolo all'uso dell'architetura stessa.
In seconda battuta se ogni archietettura supporta unità di calcolo diverse, l'algoritmo non potrà essere né unico né ottimizzato. Serve quindi una libreria di funzioni che si occupi di astrarre quello che c'è sotto. Uno strato in più di SW su cui non hai controllo e fa solo quello che la libreria permette di fare. O di usare linguaggi ad alto livello come OpenCL.
E' un metodo di programmazione che è diverso dal mettersi davanti ad un editor e scrivere codice un'istruzione dietro l'altra. E la libreria va scritta per supportare diversi linguaggi.

Insomma oltra alla parte tecnica, che già di per sè non è semplice da risolvere, esiste anche il problema umano che molti sottovalutano anche se di esempi di questo tipo ce ne sono tutti i giorni e ce ne sono stati anche in passato.

Ascolta, discutere con te diventa sempre più difficile perché il tuo intento non è fare una disciussione decente ma solamente fare inutile polemica e confuzione.
Non puoi certo ribaltare la realtà. I miei commenti hanno funzione opposta: fare chiarezza e mostrare come stanno realmente le cose rispetto a quanto hai scritto.

Poi, come già detto anche nell'altro thread, lascia che siano gli altri a giudicare.
Cacchio, 17% in più.
Vediamo... AMD/nvidia escono con una GPU nuova quest'anno a 16nm e scopriamo che va il 17% in più di Tahiti/GK110. Huhu!!!!! Squilli di tromba e rulli di tamburi a festa.
Adesso tiri in ballo anche le GPU, che non c'entrano nulla con le CPU per quanto riguarda la scalabità delle prestazioni rispetto al processo produttivo.

Ciò precisato, proprio perché parliamo di CPU un 17% è un valore decisamente elevato.
Infatti ho detto "interpretazione". M sembra di aver scritto giusta la legge, o sbaglio? Allora perché sindachi sulla questione?
Perché hai riportato una cosa completamente diversa. Ecco qui cos'hai detto:

"Le leggi della fisica dicono che al dimezamento della nanometria usata di quadruplica il numero di transistor integrabili, onde ne viene l'interpretazione della legge di Mooreche dice che ogni 12 mesi (oggi 24) le prestazioni raddoppiano."

1) Non sono le leggi della fisica che parlano del dimezzamento della nanometria. Dove l'hai letto?
2) Ai tempi della formulazione non c'erano nemmeno i nanometri, ma si usavano i micrometri.
3) E' proprio la legge di Moore che parla esplicitamente di raddoppio del numero di transistor integrabili.
4) Nella legge di Moore si parla esclusivamente di transistor e NON di prestazioni.
5) Non c'è nessuna interpretazione della legge di Moore. Al contrario, la legge di Moore nasce come risultato dell'analisi dei dati riguardo all'andamento dei processi produttivi (dimensione dei transistor) e del relativo numero di transistor integrabili. E tale formulazione non ha bisogno di ulteriori interpretazioni: è abbastanza semplice e secca da poter essere assimilata così com'è.
6) E' stata un'altra persona a mettere in relazione il raddoppio del numero di transistor col raddoppio della "potenza".
7) Anche volendo tenere conto di questo punto, hai completamente sbagliato i calcoli, visto che hai messo in relazione la quadruplicazione dei transistor col raddoppio della "potenza" di calcolo.

Dunque mi pare ci sia abbastanza da sindacare, no?

E rimane, in ogni caso, l'assenza della metrica utilizzata per misurare la "potenza" di calcolo. Quale metrica definiresti in merito? Non l'hai ancora specificato.
A me sembra ch ein altri campi il problema non si pone..
In quali campi? Stiamo parlando di circuiti integrati basati su transistor al silicio.

Riporta pure quali sarebbero questi campi.
Solo Intel e l'archiettura x86 ha questi problemi.
Nel 2000 Intel predisse, basandosi sull'andamento registrato fino ad allora, l'arrivo di processori a 10Ghz nel 2011, quindi ben 4 anni fa: http://www.geek.com/chips/intel-predicts-10ghz-chips-by-2011-564808/

Che, ovviamente, non si sono visti, a causa dei limiti della fisica che hanno impedito la scalata in frequenza.

Se, come affermi, è un problema di Intel, e addirittura di x86, allora fammi vedere chip della concorrenza che lavorano a ben più di 10Ghz (10Ghz 4 anni fa; oggi sarebbero molti di più, ovviamente).

"Stranamente" non se ne vedono. Anzi, le ultime notizie dicono che qualcuno ha problemi di surriscaldamento, e con clock ben inferiori ai 10Ghz.

Comunque aspetto di vedere processori della concorrenza che viaggiano a frequenze di gran lunga più elevate.
Forse perché anche se la densità raddoppia per via dei costi l'area non è rimasta uguale e quindi con i nuovi PP non si può realmente avere il doppio dei transistor sul die?
No, c'è sempre il raddoppio dei transistor. Ovviamente bisogna vedere in che modo vengono impiegati, e quanti ne vengono impiegati per una determinata micro-architettura.
Ecco qualche link in cui si denota l'andamento del numero di transistor per i processori, che segue abbastanza bene il citato raddoppio:
http://en.wikipedia.org/wiki/Transistor_count
http://en.wikipedia.org/wiki/Transistor_count#mediaviewer/File:Transistor_Count_and_Moore's_Law_-_2008.
Quello che oggi ha una CPU x86 dopo essere passata da 4, 5, 6 revisioni (ho perso il conto) dell'ISA?
Pensi che le altre famiglie di processori siano rimaste alla prima revisione della loro architettura? Perché non provi a dare un'occhiata alla storia della tua amata ARM?

Comunque, sì, una CPU x86 moderna ha una quantità enorme di transistor rispetto all'hardware dell'Amiga. Ma NON si tratta di un'esclusiva: sono così i processori moderni che hanno prestazioni comparabili.

A parte questo, che senso ha fare confronti di questo tipo? Andrebbero fatti nel contesto storico di riferimento, prendendo quello che c'era all'epoca.
Poi pargonare un 8086 a 16bit con un 68000 a 32 bit con il triplo dei registri D+A general purpose usabili senza vincoli (a parte 1),
L'8086 ha 8 registri general purpose, di cui 4 utilizzabili come indici. E 4 registri di segmento per indirizzare zone di memoria diversa. Dunque il 68000, che ha 8 registri dati e 8 indici, non ha affatto il triplo dei registri...
con indirizzamento di memoria flat già dall'origine..
Cosa pretendevi all'epoca? Il 68000 nemmeno esisteva nella mente dei suoi progettisti, quando l'8086 è stato commercializzato. Soprattutto, con l'8086 Intel ha marcato il passaggio dei microprocessori dagli 8 ai 16 bit: non c'era altro, infatti.
Ti manca un particolare... il tuo bellissimi immenso super powa chip di emulazione non è collegato al segnale video e non può sincronizzarsi con esso,
Falso: si può aspettare il segnale di vertical sync/blank, infatti.
per cui sei costretto a lavorare sull'immagine nel frame buffer,
Cosa che fanno tutti i chip video, e non soltanto quelli usati dai PC.

Questo perché il modo di creare e visualizzare grafica è totalmente cambiato dai tempi dell'Amiga, ma soprattutto era già cambiato qualche anno dopo l'arrivo di questa macchina, con l'introduzione della grafica 3D.

Anche i giochi 3D su Amiga facevano ben poco uso del Copper (a parte per il classico multiplexing degli sprite), proprio per questi motivi.

Per caso conosci qualche modo diverso di creare grafica oggi (ma anche una venticinquina d'anni fa), per il quale l'uso di un processore simile al Copper possa essere utile? Riportalo pure.
con un frame di ritardo.
Di anticipo, semmai: si lavora al frame da renderizzare successivamente a quello che si sta visualizzando al momento.
Non è un caso che il Coper, già proprio quel coso da 3 istruzioni a 16 bit, sia stato uno deigli scogli maggiori da superare nell'emulazione.
Ah, sì? Mi faresti vedere come, cortesemente? Perché, come già detto, emulare il Copper è decisamente semplice.
E molti giochi che lo usavano in maniera "creativa" hanno richiesto diverso tempo per poter girare in maniera decente quando emulati.
E' l'emulazione del chipset il principale problema, certamente non quello del Copper, che è la cosa più semplice da emulare proprio a motivo della sua struttura e del suo funzionamento.
Certo, con 1000 volte la potenza di calcolo del sistema origianale, direi che si possa emularlo in maniera quasi esatta.
L'emulazione cycle-exact, che sarebbe meglio chiamare simulazione, si riferisce al chipset.

Il Copper lo DEVI emulare sempre allo stesso modo, a prescindere se per il resto del chipset decidi di emularlo a più alto livello (HLE) oppure in maniera precisa (cycle-exact).
Le limitazioni c'erano, ovvio. Ma trascuri sempre quello che non ti fa comodo..
Vedremo.
ragazzo, stiamo parlando del '86,
L'Amiga è stato presentato nell'85, ragazzo.
quando il PC aveva 16 colori e risoluzione fissa a 800x600
Senza scomodare il mercato professionale, ma rimanendo soltanto a quello consumer, all'epoca c'era la EGA, che non aveva una risoluzione fissa, e spaziava dai 320x200 ai 640x350 pixel a 16 colori.

D'altra parte il PC non era certo nato per il gaming, anche se con l'arrivo della VGA (nell'87) e della sua 320x200 a 256 colori, pose le basi per diventarne il nuovo protagonista.
con una potenza di calcolo che oggi un orologio digitale supera di brutto... eppure tutto quello era possibile.
Perché? Semplicemente perché si usavano unità di elaborazione specializate per ogni lavoro.
Vero, ma è quello che si continua a fare anche oggi.
Cosa è una CPU monolitica? Quella che fa eseguire tutti i lavori alle stesse (limitate in numero) unità non specializzate.
Se ti riferisci alle unità d'esecuzione interne, già da diversi anni ci sono coprocessori esterni che si occupa di tante cose. Ma ne parlo meglio dopo.
Che diventano sempre più elefantiache per migliorare il throughtput (cache dati/istruzioni enormi,
Sono i RISC a richiedere cache più grandi, a causa della minor densità di codice rispetto ai CISC, e x86 in particolare che è una delle architetture con più elevata densità di codice.
predizioni di salti,
Problema comune a tutti i processori.
cache interne per evitare doppie decodifiche che COSTANO su x86).
Si tratta di piccolissime cache. Qual è il problema? Tra l'altro in questo modo si disabilitano completamente i decoder nei loop che ne fanno uso, al contrario degli altri processori che sono costretti a decodificare sempre le istruzioni anche in queste condizioni.
I thread non sono discussioni infinite in cui uno continua a dire le stesse cose. Se per te avere ragione vuol dire postare l'ultimo messaggio, fai pure.
Scusa l'ovvietà, ma io replico se vedo che c'è da replicare. E con te c'è sempre tanto da fare, come dimostra anche quest'ultimo messaggio. Cosa che non succederebbe se ti limitassi a parlare soltanto di cose che conosci realmente.
No ho idea, sai. Io ci sviluppo con le architetture che usano DMA con16 canali indipendenti e hanno 8 ALU con capacità diverse a seconda del compito da svolgere, con la capacità di riempire tutte e 8 le unità di calcolo... già, il DMA dell'8086, che grande cosa che sia in uso ancora oggi...
"Stranamente" hai eliminato la domanda che t'avevo posto in merito a ciò, e che chiarisce come stanno le cose. Eccola di nuovo:

"O per caso sei convinto che ancora oggi sia la CPU a occuparsi di copiare manualmente i dati da o verso una qualunque delle periferiche?"

Ribadisco: come pensi che faccia la CPU a gestire le periferiche oggi? Lo usa oppure no il DMA?

No, non conta quello che fai con quel sistema a 16 canali DMA di cui parli. Qui conta sapere come funziona un PC moderno, da diversi anni a questa parte.
A parte la FPU/unità AVX, potresti cortesemente elencarmi i coprocessori interni alle moderne CPU x86 che collaborano con le "classiche" ALU, per favore?
Da quando le FPU e le unità SIMD sono diventate "coprocessori"? Casomai è l'esatto contrario: l'FPU, da coprocessore, è divenuta parte integrante della CPU (una delle sue unità d'esecuzione).

Vedi cosa succede a parlare di cose che non si conoscono?
Stai parlando delle unità per fare de/crypting?
No, quelle sono estensioni al set d'istruzioni, che possono riguardare l'unità "intera" e/o quella SIMD. Sono, dunque, istruzioni aggiunte che consentono di accelerare quei particolari compiti. E sono aggiunte che operano tutti i produttori di processori se vogliono aumentare le prestazioni in questi ambiti.

Riguardo all'elenco che chiedevi, i coprocessori li ritrovi all'interno del chipset e/o della scheda audio e/o della scheda dei rete e/o del controller SATA e/o nella scheda video. Qualunque compito la CPU voglia delegare alle periferiche, fa uso coprocessori che si occupano, tramite canali DMA, di gestire la richiesta della CPU.
Questo è quello che dicevo. Vuoi solo far polemica e non ti intessa capire quello che l'altro scrive.
Rileggi quello che ho scritto. Rileggilo ancora. Poi un'altra volta.
E forse arrivi a capire che quello che tu hai scritto è lo stesso che ho detto io.
Quello che hai scritto tu è questo:

"Peccato solo che i SIMD del Cell non erano semplici unità di calcolo "stupide" connesse al solo bus del core dal quale dipendevano al 100%."

E rimane falso. No, le SPE NON dipendono al 100% dal core (PowerPC). Una volta avviate, sono perfettamente in grado di lavorare per i fatti loro senza intervento alcuno da parte della PPE.
Certo che ho aperto un manuale Cell. E certo che so come funzionano sia l'unità centrale che le SPE. Ma a quanto pare anche se a te non mancano le capacità di capire i manuali tecnici hai seri problemi a capire la lingua italiana.
La tua frase l'ho riportata sopra, e lingua italiana alla mano chiunque può capire quello che hai detto, e verificare che non corrisponde al vero.
In verità le SPE non puoi considerarle core veri e propri perché mancano loro una serie di caratteristiche basilari, tipo appunto che senza un core che li inizializza, ne programmi il funzionamento e li coordini non li puoi usare.
E come pensi che funzioni una CPU, non solo x86, dotata di più di un core (o thread hardware)? Mai sentito parlare di "boot processor"? O pensi che se una CPU ha 8 core, all'accensione partono tutti, e tutti si mettona a eseguire il codice del BIOS/firmware?
Sono avanzatissime unità di calcolo affiancati al core centrale.
Nel caso di Cell, non sono pensati per affiancare la PPE, ma per sostituirla (SPE-Centric), o lasciarle al più il ruolo di coordinatore (PPE-Centric), ma in ogni caso rappresentano il punto di riferimento di questo processore.
Mordernissimi coprocessori.
Oddio. Sono stati dismessi da un pezzo proprio perché il loro modello è, ormai, obsoleto.
Non certo core a tutti gli effetti come lo sono quelli Intel o quelli AMD.
Questo è senz'altro vero, ma nulla toglie alla loro capacità di calcolo del tutto autonoma dal PPE.
Quindi i core del Cell sono 1 (dual thread) che governa 8 unità di calcolo avanzate. Che è cosa ben diversa da avere 3 core PPC, come per esempio sullo Xenon della XBox360. Infatti sono due architetture completamente diverse con carateristiche diverse e capacità di calcolo diverse.
Mai detto nulla in contrario, mi pare.
E il Cell ha dimostrato, se correttamente programmato, di essere decisamente molto più potente della versione con 3 core PPC.
Ma anche no. Dipende tutto da quello che si deve realizzare.
Certo, con un Cell non basta scrivere fork() e avere un thread in esecuziuone parallela.
Non è così semplice nemmeno in una normale CPU. Per non parlare poi degli stream processor delle GPU, che richiedono particolari attenzioni.
E magari, se non lo sai, il PowerXCell 8i di IBM è leggermente diverso dal Cell della Playstation, non solo per il numero di SPE attive, ma proprio per le capacità di calcolo delle SPE stesse.
Il limite di Cell era la scarsa capacità di calcolo a doppia precisione, ed è quello che IBM ha sistemato col suo PowerXCell. Per il resto le SPE rimangono 8.
E tutto ciò non infica quanto detto prima: 1 Petaflop con 1/3 dell'energia di un sistema con architettura x86. Con senza usare l'utlimo PP disponibile...
All'epoca sì, e per QUEL particolare impiego. Oggi, ma già da tempo, c'è di meglio, e per impieghi ben più generali.
Io mi chiedo che senso ha discutere con te invece che non fai altro che fare accuse,
Di quali accuse parli?
minacce
ROFL E dov'è che ti avrei minacciato? Cos'è, vorresti farmi passare per uno di Mafia Capitale adesso, soltanto perché ho replicato a qualche tuo commento? :p
e a distorcere il pensiero degli altri a tuo uso e consumo.
Ho anche riportato le tue frasi, cosicché chiunque può benissimo rendersi conto se è vero oppure no.
Ora vado che ho ben altro a cui pensare
Pensa anche a documentarti prima di scrivere ancora, che è meglio.

Unica risposta che merita chiarimento:
"Peccato solo che i SIMD del Cell non erano semplici unità di calcolo "stupide" connesse al solo bus del core dal quale dipendevano al 100%."
C'è un NON che nega la frase successiva. "Non erano stupide unità[...] dal quale dipendevano al 100%" E' così difficile capirlo?
Se ti scrive che NON sono stupide, come puoi capire che poi dipendono al 100%???
Davvero, l'italiano e la comprensoine del testo non sono il tuo forte. Ed è quindi inutile che si continui a discutere. Una discussione costruttiva con te è praticamente impossibile a meno di non dirti "certo, hai ragione".
E quindi la risposta a tutto quello che hai scritto è: certo hai ragione.
Vivi felice ora. Il mio tempo libero è prezioso come l'oro, dato che ne ho davvero poco, e non ho intenzione di spenderlo a discutere in questo modo.
Saluti

P.S: la FPU non è un coprocessore? :rolleyes:

Unica risposta che merita chiarimento:

C'è un NON che nega la frase successiva. "Non erano stupide unità[...] dal quale dipendevano al 100%" E' così difficile capirlo?
Se ti scrive che NON sono stupide, come puoi capire che poi dipendono al 100%???
Perché il "non" agisce certamente fino alla parola "stupide", ma non dopo. Dal "connesse" in poi stai soltanto qualificando in che modo si relazionano col resto del sistema.

Si potrebbe pensare di estendere il non anche al resto della frase, ma quest'interpretazione sarebbe arbitraria. Non dico sbagliata: arbitraria.

A dirimere la questione, però, sei stato proprio tu, che hai scritto anche questo:

"In verità le SPE non puoi considerarle core veri e propri perché mancano loro una serie di caratteristiche basilari, tipo appunto che senza un core che li inizializza, ne programmi il funzionamento e li coordini non li puoi usare."

Dunque senza PPE che li fa partire, sono inutilizzabili (il che è vero). Risultato: dipendono assolutamente da questo componente. Senza se e senza ma.
Davvero, l'italiano e la comprensoine del testo non sono il tuo forte.
Vedi sopra. E lascia che siano gli altri utenti a giudicare, o senti anche il bisogno di indossare le vesti del giudice per autoassolverti da ciò tu stesso hai affermato?
Ed è quindi inutile che si continui a discutere. Una discussione costruttiva con te è praticamente impossibile a meno di non dirti "certo, hai ragione".
Stiamo parlando di questioni tecniche. Non siamo al bar dello sport. Se fai un'affermazione che non ha fondamento, è giusto che venga sottolineato per non far passare il messaggio, agli altri utenti del forum, che ciò che hai scritto sia vero. Altrimenti si creano o si alimentano le classiche leggende metropolitane di cui il web, purtroppo, è pieno.
E quindi la risposta a tutto quello che hai scritto è: certo hai ragione.
Vivi felice ora. Il mio tempo libero è prezioso come l'oro, dato che ne ho davvero poco, e non ho intenzione di spenderlo a discutere in questo modo.
Saluti
Ti auguro di impiegalo meglio studiando, allora, considerato tutti gli strafalcioni che continuamente riporti.
P.S: la FPU non è un coprocessore? :rolleyes:
Avevi scritto prima che avresti riportato soltanto una risposta. Adesso ne aggiungi un'altra, che non è affatto una domanda, a giudicare dalla faccina che hai messo. Come dire: almeno su questo hai torto, no? No. E te lo avevo anche spiegato prima. Ecco qui:

"Da quando le FPU e le unità SIMD sono diventate "coprocessori"? Casomai è l'esatto contrario: l'FPU, da coprocessore, è divenuta parte integrante della CPU (una delle sue unità d'esecuzione)."

E infatti se molti anni fa le FPU erano, per l'appunto, coprocessori, da ben 25 anni a questa parte (dunque non "ieri"), con la possibilità di impacchettare sempre più transistor, non sono più coprocessori, ma unità di esecuzione, per l'appunto.

La differenza è molto semplice. Un coprocessore è un dispositivo ESTERNO alla CPU (quanto meno al core), che è in grado di eseguire certe operazioni molto meglio rispetto a essa (o comunque di togliergli di mezzo una gran seccatura), e a cui la CPU (o core) demanda un certo compito, che è in grado di eseguire autonomamente.

Un'unità d'esecuzione, invece, è parte integrante del core: non c'è alcuna comunicazione con l'esterno, e le istruzioni di appartenenza le vengono smistate direttamente dal decoder (tramite delle code poste subito dopo di esso) esattamente come le unità intere, load / store, o SIMD (se presente/i). Sono, quindi, "first citizen" all'interno del core: stessa "dignità" di tutte le altre unità.

Spero che sia chiaro una buona volta, perché già in altre occasioni hai dimostrato di non capire le differenze fra i concetti di core, unità d'esecuzione, e coprocessore.

Come già detto prima: studia. Nel frattempo evita d'intervenire in questioni tecniche di cui non hai un sufficiente know-how. Come sempre, dovrebbe valere la regola d'oro: è meglio parlare di ciò che si conosce.

Saluti