Link alla notizia: http://www.hwupgrade.it/news/cpu/16137.html

L'evoluzione del processore Yonah, introdotto la scorsa settimana, è attesa al debutto nel corso del prossimo mese di Settembre

Click sul link per visualizzare la notizia.

il merom segnerà finalmente la fine del tunnel netburst per intel =) ho una domanda: nessuno sa niente sulle fantomatiche estensioni multimediali che dovrebbe integrare? per quel poco che ho letto si tratta di una nuova unità per il calcolo vettoriale (oppure un miglioramento di quelle esistenti)... com'è?

ps: andrea, il rilascio di Vista sbaglio o è fissato per l'autunno 2006? che io sappia la roadmap è stata confermata anche di recente

Ma quel benedetto processore chiamato conroe che tutti aspettano con impazienza dove cavolo è andato a finire?

http://arstechnica.com/news.ars/post/20050823-5232.html

Qua lessi qualcosa ai tempi dell'IDF, ma non c'è + di tanto.

Ma rispetto a Yonah cambiano solo i 64 bit e la frequenza? Il processo produttivo?

bello...questo processore dovrebbe essere il "restiling" più corposo dell'architettura del Pentium M dalla sua nasciata (BANIAS)...
quindi non sarà una semplice estensione di YONAH (ormai Core Duo o Core Solo)!
speriamo solo che riescano a risolvere i problemi di consumo che lo affliggono...sarebbe uno shock perdere il punto di forza del Pentium M :O

Quindi INTEL sarè in grado di lanciare a fine 2006 un processore della "superfantascentifica" frequenza di 2,33GHz. Andiamo bene!

vincino forse ti sfugge che non sara' netburst 2,33 GHz poi sono solo iniziali e ti invito anche a guardare il TDP...

Siamo in ambito Mobile mica desktop, per il Desktop arrivera' Conroe!!!!!! :yeah:

Quindi INTEL sarè in grado di lanciare a fine 2006 un processore della "superfantascentifica" frequenza di 2,33GHz. Andiamo bene!
ah perchè adesso la frequenza della cpu è l'elemento "di potenza" più importante... vedo che te ne intendi :p
tutto quello che AMD ha insegnato al mondo me sa che ti è sfuggito ;)

Quindi INTEL sarè in grado di lanciare a fine 2006 un processore della "superfantascentifica" frequenza di 2,33GHz. Andiamo bene!

Mi complimento per il livello di cultura informatica!!! :read:

La critica avrebbe un senso se scritta cosi:

Quindi INTEL sarè in grado di lanciare a fine 2006 un processore A 64 BIT della frequenza di 2,33GHz!

Infatti prima di allora i 64 bit saranno solo su processori con tecnologia netburst.

Quindi INTEL sarè in grado di lanciare a fine 2006 un processore A 64 BIT della frequenza di 2,33GHz!

Infatti prima di allora i 64 bit saranno solo su processori con tecnologia netburst.
:wtf:

Mi sembra che Intel stia andando sulla giusta direzione, attendo novità in merito a queste nuove cpu.
P.S. Uso Amd. ;)

ripongo molte aspettative in questo Merom... sono proprio curioso di vedere come se la caverà!

intel inizia a muoversi...ma non ci siamo ancora.

Parlavano di un -20% dei consumi....e qui si parla di un aumento del 5 / 10%

Merom o no... Intel rimane dietro se non integra il controller della RAM... A fine 2006 esce con questa CPU, nello stesso periodo ci sarà il nuovo socket AMD con BUS a 333 DDR2 dual core e frequenze prossime ai 3GHz... LOL

L'athlon64 non ha il bus...

a64 non ha bus veri...
ha soltanto il "bus" HT HyperTransport che serve per collegare i vari chiepset, pci, vga e cose varie alla cpu...
le memorie ram dialogano col processore per mezzo di una connessione diretta che lavora alla velocità effettivq del controller che poi altro non è che la velocità del processore...
L'ampiezza di banda delle memorie è sempre e solo (per a64, se non dico una cazzata) limitata ormai dalla velocità stessa delle memorie...

Per intel invece, per la comunicazione con le memorie, si utilizza un bus che pone con la propria frequenza delle limitazioni...

Santa Rosa... i Viterbesi ringrazieranno :D

l'a64 non ha il bus?
Rofl e come comunica con il resto? Percezione medianica? Con un Palantir? :asd:

L'a64 non ha un FSB vero e proprio semmai, ma un bus deve averlo per forza, è scritto nella definizione stessa di connessione dati tra circuiti.
L'Hyper transport è un BUS PuntoPunto, molto efficente e scalabile.

l'a64 non ha il bus?
Rofl e come comunica con il resto? Percezione medianica? Con un Palantir? :asd:

L'a64 non ha un FSB vero e proprio semmai, ma un bus deve averlo per forza, è scritto nella definizione stessa di connessione dati tra circuiti.
L'Hyper transport è un BUS PuntoPunto, molto efficente e scalabile.

aggiungerei che memorie ddr che vanno a più di 2ghz non si sono ancora viste ;)

ah quindi adesso l'a64 non ha il bus..

bella sta discussione, molto "acculturata" :D

Commento # 1 di: Fx :
-..." ho una domanda: nessuno sa niente sulle fantomatiche estensioni multimediali che dovrebbe integrare? per quel poco che ho letto si tratta di una nuova unità per il calcolo vettoriale (oppure un miglioramento di quelle esistenti)... com'è? "...-

io ricordo che l'unico processore desktop che integra untita' vettoriali sia il PPC con le altivec; le estensioni multimediali delle CPU intel e AMD sono solo delle istruzioni prefissate, ban diverse da un calcolatore vettoriale, che e' programabile, nel senso che possono, ad esempio, calcolare l'inverso del coseno con una passata di clock, ma fanno solo quello, quando richiesto.

non ho notizie di un'integrazione di una unita' vettoriale nei prossimi processori intel o AMD.

x lucusta

e le sse2 & sse3 cosa sono?

Guarda che si parla di 5-10% in piu' di quanto previsto!
Cioe', invece dell'80% della dissipazione attuale si "teme" circa un 85%...

Athlon64 e bus...

Il bus è la connessione attraverso la quale distinti elementi di uno o più complessi circuitali scambiano informazioni tramite segnali elettrici o ottici. Tutti i microprocessori dispongono di bus, esterni e interni, non ne possono fare a meno.
L'Athlon64 non fa eccezione, ha diversi bus, chiamati con nomi particolari, ma sempre bus rimangono. Connessione punto a punto o hypertransport, connessione con la memoria, tutti bus. Si tende a non chiamarli "bus" ma con nomi abbastanza fantasiosi perchè "bus" non evoca nulla di innovativo o prestazionale. Volete mettere un futuristico "Link HyperTransport" contro un misero "optimized bus" ? ;)
La definizione di Link viene dal fatto che, nella categoria dei bus, un link collega direttamente due blocchi circuitali e basta. In un tipico PC un "link HT" di un A64, composto da più canali fisici utilizzabili parzialmente o in una botta sola, collega la cpu al chip che gestisce il northbridge e il southbridge.
L'HyperTransport è un bus molto evoluto, di rottura con i tradizionali bus o PCIexpress, parallelizza invece di serializzare e ha latenze molto basse. Grazie al minor numero di segnali di controllo necessari per sincronizzare i flussi di dati, l'HT spreca pochissima banda e massimizza quella disponibile per i dati veri e propri. Per saperne di più:

http://www.hypertransport.org/index.cfm

L'athlon64 non ha il bus...

si sentirà solo... :Prrr:

io ricordo che l'unico processore desktop che integra untita' vettoriali sia il PPC con le altivec; le estensioni multimediali delle CPU intel e AMD sono solo delle istruzioni prefissate, ban diverse da un calcolatore vettoriale, che e' programabile, nel senso che possono, ad esempio, calcolare l'inverso del coseno con una passata di clock, ma fanno solo quello, quando richiesto.
Altivec e MMX/3DNow!/SSE/2/3 sono tutti esempi unità di calcolo vettoriali.

"Bisognerà aspettare fino al secondo trimestre del 2007 per la nuova
piattaforma Santa Rosa.."

Ma com'è che si chiamerà??? :eek:

Santa Rosa..? Potevano chiamarla Santa Rosalia.. non era meglio?! :p

si sentirà solo... :Prrr:

un po' come il core solo :mc:


(duo is megl che solo!)

Santa Rosa..? Potevano chiamarla Santa Rosalia.. non era meglio?! :p
(tanto per stare al livello di questo thread...)

ma no... vedi che non capisci? intel implementerà nel 2007 un nuovo tipo di silicio derivato dalla marmellata di mele cotogne, da lì il nome.

Commento # 26 di: cdimauro:
-..."Altivec e MMX/3DNow!/SSE/2/3 sono tutti esempi unità di calcolo vettoriali "...-

a quanto ho sempre inteso, per altivec si parla di programmabilita' per MMX/3DNow!/SSE-2-3 si parla di istruzioni.
anche queste sono delle unita' di calcolo vettoriali, ma come gia' ho detto, sono prefissate, ossia fanno solo determinati sequenze di calcoli (non tipo, ma sequenze), percio' per utilizzarle, un programma, deve usare quel tipo d'istruzioni, sommandole e manipolandole per il proprio scopo.
Le istruzioni da integrare sono state scelte tra' quelle che sembravano le piu' probabili da usare, compatibili tra' loro atte a costruire una'unita' di calcolo unica da integrare.

nella pratica e' come se le istruzioni MMX/3DNow!/SSE-2-3 fossero sequenze di operazionali come +, -, *, e /, in predeterminate sequenze, e quando hai un calcolo da eseguire e questo e' "compatibile" con la sequenza operazionale di una determinata istruzione, usi l'istruzione e ti arriva il risultato.
La Altivec e' un calcolatore vettoriale puro; c'e' bisogno di un programma o algoritmo da fargli seguire, ma e' "general porpouse" in ambito vettoriale.
Questo e' anche il motivo per cui altivec e' molto usato in diversi ambiti su mac, perche' basta compilare il giusto progrmma per fargli fare tante cose, mentre i programmi windows devono essere compilati per usare un susseguirsi di istruzioni necessarie per ottenere il calcolo, rendendo il lavoro piu' difficile ai programmatori, in quanto avvolte e' piu' produttivo utilizzare direttamente il core logico della CPU che andare a fare piu' di diversi passagi tra istruzioni e core logico per ottenere lo stesso risultato.

ritornando alla domanda, non credo che intel integrera' una unita' di calcolo tipo altivec in merom, o almeno non ho scovato notizie al riguardo, ma se lo facesse, meglio per chi lo acquistera'.

lol non avevo letto questa chicca di cidimauro, perde i colpi ultimamente ;)

Athlon64 e bus...

Il bus è la connessione attraverso la quale distinti elementi di uno o più complessi circuitali scambiano informazioni tramite segnali elettrici o ottici. Tutti i microprocessori dispongono di bus, esterni e interni, non ne possono fare a meno.
L'Athlon64 non fa eccezione, ha diversi bus, chiamati con nomi particolari, ma sempre bus rimangono. Connessione punto a punto o hypertransport, connessione con la memoria, tutti bus. Si tende a non chiamarli "bus" ma con nomi abbastanza fantasiosi perchè "bus" non evoca nulla di innovativo o prestazionale. Volete mettere un futuristico "Link HyperTransport" contro un misero "optimized bus" ? ;)
La definizione di Link viene dal fatto che, nella categoria dei bus, un link collega direttamente due blocchi circuitali e basta. In un tipico PC un "link HT" di un A64, composto da più canali fisici utilizzabili parzialmente o in una botta sola, collega la cpu al chip che gestisce il northbridge e il southbridge.
L'HyperTransport è un bus molto evoluto, di rottura con i tradizionali bus o PCIexpress, parallelizza invece di serializzare e ha latenze molto basse. Grazie al minor numero di segnali di controllo necessari per sincronizzare i flussi di dati, l'HT spreca pochissima banda e massimizza quella disponibile per i dati veri e propri. Per saperne di più:

http://www.hypertransport.org/index.cfm

Hum.. il discorso "A64 non ha il bus" in genere si riferisce al fatto che negli A64, essendo il controller delle memorie integrato, non esiste il Front Side Bus tra CPU e chipset+memory controller come negli Intel, o meglio, il bus verso le memorie è integrato nella CPU e ha la stessa velocità del processore, il che consente agli A64 di scalare meglio in frequenza rispetto alle soluzioni "tradizionali". A questo si aggiunge il link Hypertransport, che collega la CPU al chipset che poi è connesso a sua volta alle periferiche, diversamente da quello che accade nei sistemi Intel dove la banda passante è condivisa tra memorie e periferiche. A parte questo, Hypertranport non è propriamente un bus "parallelo" come ad esempio quello verso la memoria, anzi il concetto è moto simile a quello dei link del PCI-Express, ossia con link seriali scalabili da 2 a 16 bit e oltre, con elevata velocità per singolo link, e non è nemmeno un bus in senso stretto, dato che mentre ad un bus io posso connettere più periferiche, il link HT è solo un link punto-punto, nato non per connettere delle periferiche ma per l'interconnessione ad alta velocità dei circuiti integrati. Quindi tra l'altro il bus PCI-Express è PIU' evoluto dell'Hypertransport, perchè permette di collegare più periferiche, sincronizzarle, ecc. D'altra parte la maggiore semplicità di HT gli consentirà IMHO con tutta probabilità di ottenere velocità elevatissime prima di PCI-Express, e molto probabilmente i due standard conviveranno ancora per un pò insieme (e forse anche quando AMD integrerà i link PCI-Express nelle CPU, come sembra abbia pianificato).

Commento # 26 di: cdimauro:
-..."Altivec e MMX/3DNow!/SSE/2/3 sono tutti esempi unità di calcolo vettoriali "...-

a quanto ho sempre inteso, per altivec si parla di programmabilita' per MMX/3DNow!/SSE-2-3 si parla di istruzioni.
anche queste sono delle unita' di calcolo vettoriali, ma come gia' ho detto, sono prefissate, ossia fanno solo determinati sequenze di calcoli (non tipo, ma sequenze), percio' per utilizzarle, un programma, deve usare quel tipo d'istruzioni, sommandole e manipolandole per il proprio scopo.
Le istruzioni da integrare sono state scelte tra' quelle che sembravano le piu' probabili da usare, compatibili tra' loro atte a costruire una'unita' di calcolo unica da integrare.

nella pratica e' come se le istruzioni MMX/3DNow!/SSE-2-3 fossero sequenze di operazionali come +, -, *, e /, in predeterminate sequenze, e quando hai un calcolo da eseguire e questo e' "compatibile" con la sequenza operazionale di una determinata istruzione, usi l'istruzione e ti arriva il risultato.
La Altivec e' un calcolatore vettoriale puro; c'e' bisogno di un programma o algoritmo da fargli seguire, ma e' "general porpouse" in ambito vettoriale.
Questo e' anche il motivo per cui altivec e' molto usato in diversi ambiti su mac, perche' basta compilare il giusto progrmma per fargli fare tante cose, mentre i programmi windows devono essere compilati per usare un susseguirsi di istruzioni necessarie per ottenere il calcolo, rendendo il lavoro piu' difficile ai programmatori, in quanto avvolte e' piu' produttivo utilizzare direttamente il core logico della CPU che andare a fare piu' di diversi passagi tra istruzioni e core logico per ottenere lo stesso risultato.

ritornando alla domanda, non credo che intel integrera' una unita' di calcolo tipo altivec in merom, o almeno non ho scovato notizie al riguardo, ma se lo facesse, meglio per chi lo acquistera'.

Ehm... ma anche i programmi Altivec sono composti da istruzioni...
Poi Altivec può essere più flessibile di SSE1/2/3 o 3DNow!, ma sempre di unità SIMD si tratta...

@Leoneazzurro

La FAQ ufficiale del consorzio HyperTransport dice:

Serial technologies such as PCI Express and RapidIO require serial-deserializer interfaces and have the burden of extensive overhead in encoding parallel data into serial data, embedding clock information, re-acquiring and decoding the data stream. The parallel technology of HyperTransport needs no serdes and clock encoding overhead making it far more efficient in data transfers.

Nel sito ufficiale del consorzio HyperTransport ci sono notizie interessanti che bastano a farsi un'idea corretta del sistema, per i dettagli si possono consultare i manuali tecnici.
Da notare che nell'elenco delle industrie consociate, alcune famose e altre molto meno, è presente Apple ma "spicca" la mancanza di Intel ( forse per "conflitto di interessi" con il PCI expr ? )

Il PCI-express non è che sia sto gran bus, ha le sue limitazioni, ne parlava un tecnico creative che affermava quanto fosse inadatto ad esempio per le schede sonore.

Cque:
PCIE: bus seirale multipoint, adatto a collegare molte periferiche, le caratteristiche che lo rendono versatile lo rendono anche meno scalabile.

HTT: bus di collegamento punto punto, adatto a collegare 2 "periferiche", la sua semplicità lo rende facilmente scalabile, per collegare più periferiche assieme si usano i crossbar switch.

@Leoneazzurro

La FAQ ufficiale del consorzio HyperTransport dice:

Serial technologies such as PCI Express and RapidIO require serial-deserializer interfaces and have the burden of extensive overhead in encoding parallel data into serial data, embedding clock information, re-acquiring and decoding the data stream. The parallel technology of HyperTransport needs no serdes and clock encoding overhead making it far more efficient in data transfers.

Nel sito ufficiale del consorzio HyperTransport ci sono notizie interessanti che bastano a farsi un'idea corretta del sistema, per i dettagli si possono consultare i manuali tecnici.
Da notare che nell'elenco delle industrie consociate, alcune famose e altre molto meno, è presente Apple ma "spicca" la mancanza di Intel ( forse per "conflitto di interessi" con il PCI expr ? )

Si, mi sono spiegato male: intendevo dire che il parallelismo esiste (ho detto io che è scalabile da 2 a 16 (in realtà fino a 32, ma ancora non si è vista un'applicazione monodirezionale a 32 bit, solo 16 bit per direzione) ma è molto ridotto, che è un fattore necessario per mantenere la coerenza dei segnali a determinate velocità, ed in questo ricalca un pò il PCI-E (o meglio, il viceversa, visto che HT è nato prima) che addirittura si è ridotto ad una trasmissione seriale dei dati (i cui link però possono essere accorpati in insiemi più grandi). D'altra parte appunto HT è più semplice anche perchè NON deve connettere periferiche, ma solo fungere da interconnessione tra chips.

I crossbar switch li puoi utilizzare, ma oltre 2/3 interconnessioni i vantaggi dell'HT tendono a svanire...

D'altra parte appunto HT è più semplice anche perchè NON deve connettere periferiche, ma solo fungere da interconnessione tra chips.
humm... no, non la vedrei in questo modo...
l'HTT è semplice perchè deve permettere velocità elevate e bassi costi, se inizi a fare un bus a pacchetti di dati, più complesso per farlo salire di clock spendi troppo.

I crossbar switch li puoi utilizzare, ma oltre 2/3 interconnessioni i vantaggi dell'HT tendono a svanire...
Non puoi fare 3 interconnessioni, sono sempre punto punto, nel caso dell'opteron 4 vie ad esempio hai che ogni opteron è interconnesso con due delle altre CPU mediante un canale HTT, l'altro canale HTT (nell'opteron sono appunto 3) è dedicato come negli athlon 64 normali all'I/O verso il chipset.

Per darti una idea:
http://www.amdboard.com/quad-opteron-diagram.gif

humm... no, non la vedrei in questo modo...
l'HTT è semplice perchè deve permettere velocità elevate e bassi costi, se inizi a fare un bus a pacchetti di dati, più complesso per farlo salire di clock spendi troppo.


Questo perchè appunto non è nato come bus bensì come link di interconnessione ad alta velocità, è questo che intendo dire, ed infatti HT non mi pare adatto a fare il bus.


Non puoi fare 3 interconnessioni, sono sempre punto punto, nel caso dell'opteron 4 vie ad esempio hai che ogni opteron è interconnesso con due delle altre CPU mediante un canale HTT, l'altro canale HTT (nell'opteron sono appunto 3) è dedicato come negli athlon 64 normali all'I/O verso il chipset.

Per darti una idea:
http://www.amdboard.com/quad-opteron-diagram.gif

(sigh) Lo so che sono link punto/punto, l'ho già detto prima (così come conosco lo schema che mi hai mostrato ;) ). Stavo dicendo (rispondendoti, i crossbar li hai citati tu) che se pensassi di usare dei crossbar switch per delle periferiche (non stavo parlando di interconnessione tra CPU dove si usano link multipli, ma lì è più che giustificato) la complessità salirebbe esponenzialmente senza vantaggi pratici.

Commento # 33 di: leoneazzurro:

- "Ehm... ma anche i programmi Altivec sono composti da istruzioni...
Poi Altivec può essere più flessibile di SSE1/2/3 o 3DNow!, ma sempre di unità SIMD si tratta... " -

in un certo senso si, ma mentre con altivec costruisci un generico programma adatto al tuo scopo che sfrutta il calcolatore vettoriale (o meglio l'algoritmo, visto che, essendo in campo di calcolo vettoriale, sono queste istruzioni ripetitive a giovare di piu' di quest'architetura, pensa ad una matrice composta), con le istruzioni prefissate possono effettivamente essere direttamente i programmi a sfruttarle, ma per ottenere il tuo scopo potresti fare il giro dell'oca..

E' la flessibilita' di altivec alla base del suo intenso sfruttamento su MAC: ti serve un calcolo che puoi assumere in vettori? fai un programma che sfrutta altivec per i tuoi calcoli.
mentre le SIMD non sono state mai intensamente sfruttate proprio a causa della loro rigidita' elaborativa.
Le istruzioni altivec si possono assimilare alle ISA x86, ossia un set completo di programmazione, mentre le SIMD sono solo delle ISA a se stanti, molto complesse, ma in totale limitate nel'elaborazione.

e a mio avviso e' proprio questa una delle piu' grandi pecche al passaggio "intel" di Apple, sempre che Apple non integri su ogni suo "PC" un chip Ageia dedicato a sostituzione dell'altivec (pur, a quanto ho capito, essendo anche questo vincolato a certe sequenze di calcoli).
Era per questo che mi domandavo se Fx aveva "percepito" nell'aria che intel avesse avuto intenzione di integrare una vera unita' di calcolo vettoriale sui merom, alla stregua di una sostituzione per altivec.

Commento # 33 di: leoneazzurro:

- "Ehm... ma anche i programmi Altivec sono composti da istruzioni...
Poi Altivec può essere più flessibile di SSE1/2/3 o 3DNow!, ma sempre di unità SIMD si tratta... " -

in un certo senso si, ma mentre con altivec costruisci un generico programma adatto al tuo scopo che sfrutta il calcolatore vettoriale (o meglio l'algoritmo, visto che, essendo in campo di calcolo vettoriale, sono queste istruzioni ripetitive a giovare di piu' di quest'architetura, pensa ad una matrice composta), con le istruzioni prefissate possono effettivamente essere direttamente i programmi a sfruttarle, ma per ottenere il tuo scopo potresti fare il giro dell'oca..

E' la flessibilita' di altivec alla base del suo intenso sfruttamento su MAC: ti serve un calcolo che puoi assumere in vettori? fai un programma che sfrutta altivec per i tuoi calcoli.
mentre le SMID non sono state mai intensamente sfruttate proprio a causa della loro rigidita' elaborativa.
Le istruzioni altivec si possono assimilare alle ISA x86, ossia un set completo di programmazione, mentre le SMID sono solo delle ISA a se stanti, molto complesse, ma in totale limitate nel'elaborazione.

e a mio avviso e' proprio questa una delle piu' grandi pecche al passaggio "intel" di Apple, sempre che Apple non integri su ogni suo "PC" un chip Ageia dedicato a sostituzione dell'altivec (pur, a quanto ho capito, essendo anche questo vincolato a certe sequenze di calcoli).
Era per questo che mi domandavo se Fx aveva "percepito" nell'aria che intel avesse avuto intenzione di integrare una vera unita' di calcolo vettoriale sui merom, alla stregua di una sostituzione per altivec.
Non è così: Altivec e MMX/3DNow!/SSE, ecc. differiscono quanto a ISA, ma sono tutte estensioni SIMD all'architettura di base.

Puoi dirmi che Altivec è più flessibile, perché introduce il concetto di stream di dati (mentre le altre hanno istruzioni apposite di prefetch), perché ha istruzioni a 3 e anche 4 operandi, tipiche delle famiglie RISC, ma se devo sommare con saturazione 4 interi signed a 32 bit avrò comunque bisogno di eseguire le seguenti istruzioni:
- caricamento del primo registro;
- caricamento del secondo registro;
- somma di interi a 32 bit con saturazione;
- eventuale salvataggio del risultato.

La differenza fra Altivec e le altre SIMD in questo caso sta soltanto negli opcode utilizzati, ma nulla di più.

Altivec è molto flessibile, indubbiamente. Le SSE invece hanno dalla loro una maggior varietà di istruzioni. Ma entrambe sono unità SIMD.

T'invito a scaricarti il manuale di Altivec, quello di Intel sull'architettura x86 (ci sono ovviamente dei capitoli dedicati a MMX, SSE/2/3) e a fare i relativi confronti: ti renderai tu stesso conto di come stanno le cose. ;)

lol non avevo letto questa chicca di cidimauro, perde i colpi ultimamente ;)
Non mi aspetto che uno che non sa nemmeno scrivere una banalissima operazione di somma per un 386 ne capisca qualcosa di architetture degli elaboratori, né tanto meno di unità SIMD.

Vedo che continuano a bruciarti le bastonate che ti ho dato tempo fa: e dire che ne è passato di tempo.
Un consiglio: rosicare e covare odio fa male alla salute. Mettimi in ignore list e vivi felice.

Commento # 40 di: cdimauro:
-..."Altivec è molto flessibile, indubbiamente. Le SSE invece hanno dalla loro una maggior varietà di istruzioni. Ma entrambe sono unità SIMD

T'invito a scaricarti il manuale di Altivec, quello di Intel sull'architettura x86 (ci sono ovviamente dei capitoli dedicati a MMX, SSE/2/3) e a fare i relativi confronti: ti renderai tu stesso conto di come stanno le cose."...-

si, hai ragione, altivec e' un set esteso di SIMD, e certamente non un vero calcolatore vettoriale, come ad esempio un DSP programabile;

pero' la sua flessibilita' lo rende molto piu' sfruttabile rispetto a MMX,SSE,2,3.
Nato poco dopo MMX non ha mai avuto bisogno di aggiornamenti, mentre intel ha dovuto elaborare SSE,2,3 per (non) avvicinarne la qualita'.
logicamente, non essendo un programmatore, non posso addentrarmi oltre nel discorso, pero' devi ammettere che altivec e' di gran lunga piu' efficente delle istruzioni intel, potendo appoggiare un codec multimediale, o meglio il suo algoritmo, tanto efficacemente quanto nel fare calcoli fisici.

sara' comunque una perdita, per i sistemi mac, e non credo che SSE2 potrebbe sostituire in toto l'uso che se ne faceva su OSX.
va bene l'aumentata potenza di calcolo, ma se poi bisogna in parte sprecarla in elaborazioni che prima si facevano fare ad unita' "dedicate"....

Il problema è che qua si palrava di unità DEDICATE al calcolo vettoriale, è arrivato cidimauro a fare la sua solita crociata contro gli utenti mac-isti dicendo che le "mmx/sse/3dnow sono unità vettoriali come altivec" e si è cambiato il discorso sulla "potenza dei vari set di istruzioni".

Ora, sottolineando il fatto che le MMX/SSE non sono mai state unità vettoriali ( :eek: che idiozia :doh:, da uno spantegone come cdimauro uno scivolone simile non me lo sarei mai aspettato... ma forse a furia di "invitare gli altri a leggere manuali" lui si dimentica di fare altrettanto :asd: )
Le SSE/MMX/3dnow sono invece set di istruzioni.

Il fatto è che il discorso non è nemmeno questo.

Ogni G5 ha una sua unità altivec, con una sua pipeline che nello stadio di execute non dipende da altre unità della CPU, anzi le istruzioni per poter tornare nella normale pipeline della CPU devono passare per alcuni stadi aggiuntivi finali e iniziali.
Cito "Hannibal" stokes da Arstechnica (http://arstechnica.com/cpu/03q1/ppc970/ppc970-7.html):
It appears that in the 970 the Altivec unit is sort of "tacked on" to the core. While the vector register file sits alongside the general purpose and floating-point register files for the purpose of keeping LOAD and STORE latencies down, the actual vector execution hardware is off on a different portion of the die, away from the vector register file and away from the rest of the execution core. This necessitates the addition of at least two extra stages to the vector pipeline: one stage at the beginning of the execution phase to actually move the instructions out to the vector execution unit and another stage at the end of the execution phase to move the instructions from the unit back to the group completion queue.

Le istruzioni SSE non hanno una unità dedicata. Nelle architetture x86 (AMD o INTEL) odierne ad esempio le istruzioni SSE sono processate da unità FP o INT che vengono normalmente usate per il codice x87/x86. Sono tutte istruzioni che non hanno una loro pipeline dedicata, con tutti i problemi del caso.
La situazione è chiaramente migliorata nel prescott e nel K8, dove sono state aggiunte unità FP aggiuntive proprio per eseguire le 4 operazioni a 32bit di una istruzione SSE2/3 nel minor tempo possibile. Ma di "unità dedicate" non se ne vede l'ombra.
E così pare che sarà anche nel merom, o almeno questa è l'opinione di uno che le cose le spiega e non le manda a dire (http://arstechnica.com/news.ars/post/20050823-5232.html):
And though there's no word out on the FPU and SIMD units as of yet, I expect that Intel will continue its practice of combining the two types of execution units into a single functional block. The Merom core will probably have two fairly full-featured FPU/SIMD arithmetic units, but we should know more on that front soon.
Pero' il merom è stato progettato from scratch, sfruttando solo il bagaglio di conoscenze di PM e P4, quindi ci si puo' sempre aspettare di tutto. Anche yonah tutti si aspettavano che fosse prodotto con due core separati come il P4-D, ma non così non è stato.

Attenzione... le unità SSE/3DNow! non sono LE STESSE delle operazioni FP X87, sono semplicemente all'interno dello stesso blocco funzionale, mentre le unità AltiVec sono su un blocco funzionale separato dall'unità FP dei PPC (il che significa che gli X86 hanno la limitazione di non poter fare alcuni tipi di operazioni FP e SIMD allo stesso tempo). Questo è quello che è scritto in quegli articoli.
Tra l'altro non è vero che le unità AltiVec hanno una pipeline propria completamente eseparata da quella del core "generico", bensì hanno stadi aggiuntivi per il dispatch delle istruzioni alle unità SIMD (questi stadi aggiuntivi esistono anche nelle architetture X86). Si vede bene qui:

http://arstechnica.com/articles/paedia/cpu/ppc970.ars/2

perchè l'execution core di cui fanno parte le unità ALtiVec fa parte a sua volta della pipeline generale e il decode/fetch delle istruzioni avviene prima.

In sostanza sia AltiVec che SSE1/2/3 sono set aggiuntivi di istruzioni SIMD, che vengono eseguiti da delle unità dedicate all'interno dei processori PPCe X86, rispettivamente, e sicuramente AltiVec è più flessibile, non fosse altro perchè permette di eseguire sempre istruzioni FP contemporaneamente a quelle SIMD

pero' la sua flessibilita' lo rende molto piu' sfruttabile rispetto a MMX,SSE,2,3.
Nato poco dopo MMX non ha mai avuto bisogno di aggiornamenti, mentre intel ha dovuto elaborare SSE,2,3 per (non) avvicinarne la qualita'.
Dipende dal tipo di codice da eseguire. Altivec è strutturato meglio, come già detto, ma le SSE2 (che ormai sono il punto di riferimento per quanto riguarda le SIMD per x86) hanno un set d'istruzioni più ricco. In base alle problematiche da risolvere può andare meglio l'uno o l'altro.
logicamente, non essendo un programmatore, non posso addentrarmi oltre nel discorso, pero' devi ammettere che altivec e' di gran lunga piu' efficente delle istruzioni intel, potendo appoggiare un codec multimediale, o meglio il suo algoritmo, tanto efficacemente quanto nel fare calcoli fisici.
Da questo punto di vista non ci sono differenze non c'è, IMHO. Tra l'altro i compilatori Intel sono particolarmente rinomati nel riconoscere e autovettorizzare il codice.

sara' comunque una perdita, per i sistemi mac, e non credo che SSE2 potrebbe sostituire in toto l'uso che se ne faceva su OSX.
va bene l'aumentata potenza di calcolo, ma se poi bisogna in parte sprecarla in elaborazioni che prima si facevano fare ad unita' "dedicate"....
I programmatori si adegueranno.

Comunque anche le SSE sono unità dedicate (MMX e 3DNow!, invece, si "mappava" sull'FPU, per cui si può usare codice x87 o MMX alternativamente, utilizzando apposite istruzioni).

Il problema è che qua si palrava di unità DEDICATE al calcolo vettoriale, è arrivato cidimauro a fare la sua solita crociata contro gli utenti mac-isti
Le crociate religiose le lascio fare ai fanatici integralisti: io preferisco fare dei chiarimenti su questioni TECNICHE, come in questo caso.
dicendo che le "mmx/sse/3dnow sono unità vettoriali come altivec" e si è cambiato il discorso sulla "potenza dei vari set di istruzioni".
Infatti sono unità vettoriali dedicate.
Ora, sottolineando il fatto che le MMX/SSE non sono mai state unità vettoriali ( :eek: che idiozia :doh:, da uno spantegone come cdimauro uno scivolone simile non me lo sarei mai aspettato... ma forse a furia di "invitare gli altri a leggere manuali" lui si dimentica di fare altrettanto :asd: )
Nessun errore, come ti è stato detto anche da leoneazzurro.

D'altra parte tu un manuale di PowerPC, Altivec o x86 non l'hai mai neppure sfogliato, come hai ampiamente dimostrato.
Le SSE/MMX/3dnow sono invece set di istruzioni.
Sono unità vettoriali dedicate che OFFRONO (ovviamente) un set di istruzioni aggiuntivo all'ISA originale.
Il fatto è che il discorso non è nemmeno questo.
Certo: proviamo a spostarlo da qualche altra parte, visto che qui le acque non sono ben messe.
Ogni G5 ha una sua unità altivec, con una sua pipeline che nello stadio di execute non dipende da altre unità della CPU, anzi le istruzioni per poter tornare nella normale pipeline della CPU devono passare per alcuni stadi aggiuntivi finali e iniziali.
Cito "Hannibal" stokes da Arstechnica (http://arstechnica.com/cpu/03q1/ppc970/ppc970-7.html):
It appears that in the 970 the Altivec unit is sort of "tacked on" to the core. While the vector register file sits alongside the general purpose and floating-point register files for the purpose of keeping LOAD and STORE latencies down, the actual vector execution hardware is off on a different portion of the die, away from the vector register file and away from the rest of the execution core. This necessitates the addition of at least two extra stages to the vector pipeline: one stage at the beginning of the execution phase to actually move the instructions out to the vector execution unit and another stage at the end of the execution phase to move the instructions from the unit back to the group completion queue.
Questo riguarda soltanto l'implementazione di Altivec che ha seguito IBM, che differisce da quella di Motorola. Tutto qui.
Le istruzioni SSE non hanno una unità dedicata. Nelle architetture x86 (AMD o INTEL) odierne ad esempio le istruzioni SSE sono processate da unità FP o INT che vengono normalmente usate per il codice x87/x86. Sono tutte istruzioni che non hanno una loro pipeline dedicata, con tutti i problemi del caso.
Nemmeno le Altivec hanno una pipeline dedicata, come ti è stato spiegato, ma soprattutto come puoi vedere dallo stesso articolo di "Hannibal".
La situazione è chiaramente migliorata nel prescott e nel K8, dove sono state aggiunte unità FP aggiuntive proprio per eseguire le 4 operazioni a 32bit di una istruzione SSE2/3 nel minor tempo possibile. Ma di "unità dedicate" non se ne vede l'ombra.
Ti stai confondendo ancora: il vincolo che hanno le istruzioni SIMD MMX e 3DNow! è che per usare istruzioni x87 e viceversa serve effettuare un "context switch" che serve a sistemare lo stato dell'FPU in base al modello di programmazione scelto.

Con le SSE tutto ciò non è necessario, ed è possibile usare contemporaneamente anche l'FPU per eseguire codice x87 o MMX/3DNow!, rispettando i vincoli delle unità di esecuzione utilizzate dalle varie istruzioni.

Tutto ciò è scritto chiaramente nel manuale di Intel per l'architettura x87, nei capitoli in cui si parla di MMX, SSE, SSE2 ed SSE3: basta leggerli.
E così pare che sarà anche nel merom, o almeno questa è l'opinione di uno che le cose le spiega e non le manda a dire (http://arstechnica.com/news.ars/post/20050823-5232.html):
And though there's no word out on the FPU and SIMD units as of yet, I expect that Intel will continue its practice of combining the two types of execution units into a single functional block. The Merom core will probably have two fairly full-featured FPU/SIMD arithmetic units, but we should know more on that front soon.
Pero' il merom è stato progettato from scratch, sfruttando solo il bagaglio di conoscenze di PM e P4, quindi ci si puo' sempre aspettare di tutto. Anche yonah tutti si aspettavano che fosse prodotto con due core separati come il P4-D, ma non così non è stato.
Anziché andare a girovagare su internet, dovresti provare a leggerti (meglio ancora studiare) i manuali di Intel per capire come stanno effettivamente le cose.

D'altra parte la differenza rispetto ad Altivec è che con le SSE non puoi, ad esempio, contemporaneamente utilizzare la stessa unità di esecuzione se è già impegnata da un'istruzione x87 o MMX, e viceversa.

Per il G5 questo vincolo non esiste, come è stato scritto da leoneazzurro, perchè è dotato di unità di esecuzione apposite per entrambe le sezioni.

Quanto questo possa essere utile, è da vedere, visto che generalmente si esegue codice SIMD o FPU, ma difficilmente tutti e due i tipi.

Infatti questo è il motivo per cui Intel ha arricchito particolarmente il set d'istruzioni con SSE prima, ma specialmente con SSE2 poi: il concetto è quello di usare soltanto l'unità SIMD, possibilmente senza far mai ricorso a quella x87.

Attenzione... le unità SSE/3DNow! non sono LE STESSE delle operazioni FP X87, sono semplicemente all'interno dello stesso blocco funzionale, mentre le unità AltiVec sono su un blocco funzionale separato dall'unità FP dei PPC (il che significa che gli X86 hanno la limitazione di non poter fare operazioni FP generiche e SIMD allo stesso tempo). Questo è quello che è scritto in quegli articoli.

ma no scusami... non è quello che c'è scritto in quegli articoli...
E si che ti ho pure evidenziato in italic, il pezzo in cui stokes dice che intel continuerà sulla sua strada.
And though there's no word out on the FPU and SIMD units as of yet, I expect that Intel will continue its practice of combining the two types of execution units into a single functional block.

Per AMD lo vedi qua.
http://www.chip-architect.com/news/Opteron_FloatPnt_Core.jpg
Nell'Athlon 64 ad esempio abbiamo una unità FP capace di fare 2 MUL a 32bit dove vengono eseguite le normali operazioni FP semplici e complesse e poi una aggiuntiva (semplice) capace di fare 1 MUL a 64 bit. Aggiunta proprio per abbassare la latenza di una evntuale istruzione simd su 4 operandi a 32bit.

Tra l'altro non è vero che le unità AltiVec hanno una pipeline propria completamente eseparata da quella del core "generico", bensì hanno stadi aggiuntivi per il dispatch delle istruzioni alle unità SIMD (questi stadi aggiuntivi esistono anche nelle architetture X86). Si vede bene qui:

http://arstechnica.com/articles/paedia/cpu/ppc970.ars/2

perchè l'execution core di cui fanno parte le unità ALtiVec fa parte a sua volta della pipeline generale e il decode/fetch delle istruzioni avviene prima.
Beh che la pipeline delle altivec sia compresa nella pipeline principale nel G5 mi pare obbligato (ammesso che alla motorola non abbiano inventato un nuovo modo di fare le CPU), ma uno stadio di esecuzione di una ALU FP del G5 non ha nulla a che vedere con uno stadio di esecuzione dell'unità altivec, cosa invece differente nel G4 o nel P4 o nel K8.

In sostanza sia AltiVec che SSE1/2/3 sono set aggiuntivi di istruzioni SIMD, che vengono eseguiti da delle unità dedicate all'interno dei processori PPCe X86, rispettivamente, e sicuramente AltiVec è più flessibile, non fosse altro perchè permette di eseguire istruzioni FP contemporaneamente a quelle SIMD
Tutto corretto, a parte che di dedicato -come ha già spiegato stokes nell'articolo dell'IDF- per ora non si vede l'ombra nelle architetture x86, e dubita che intel cambierà strada.
Per AMD non si sa ancora cosa combinerà nel K9.
Tra l'altro nota che nel G4 le istruzioni altivec non sono processate in una unità isolata come nel G5, o meno così ho appreso da fonti online.

Per ripsondere a cdimauro, la didascalia dell'immagine (da un sito per altro da lui linkatomi tempo fa).

"X87 AND SSE FLOATING POINT MULTIPLIER"

Penso sia abbastanza eloquente (oltre a quanto detto da stokes e dal sito stesso) del fatto che le moltiplicazioni SSE o FP siano fatte con i medesimi transistor, e non mi dilungo nell'insegnargli architettura degli elaboratori un'altra volta :asd:

Effettivamente sarebbe bastato che cidimauro leggesse i siti che linka :rolleyes:
http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

The x87 and SSE2 floating point multiplier handles 64 and 80 extended length multiplications. The large Wallace tree which handle the 64 bit multiplications for 80 bit extended floating point and 64 bit integer multiplications can be split into two independent Wallace trees that handle the dual 32 bit SIMD multiplications used for SSE and 3Dnow functions (US Patent 6,490,607)

Aurevoir :)

Post Scriptum: nessuno vi obbliga a prendere per buono quello che c'è scritto in questi siti, chiaramente se trovate altre fonti più serie che dicano il contrario sono ben contento di essere smentito.

P.P.S:
D'altra parte la differenza rispetto ad Altivec è che con le SSE non puoi, ad esempio, contemporaneamente utilizzare la stessa unità di esecuzione se è già impegnata da un'istruzione x87 o MMX, e viceversa.
Problema che non sussisterebbe se le SSE avessero la loro unità SIMD dedicata.

Per ripsondere a cdimauro, la didascalia dell'immagine (da un sito per altro da lui linkatomi tempo fa).

"X87 AND SSE FLOATING POINT MULTIPLIER"

Penso sia abbastanza eloquente (oltre a quanto detto da stokes e dal sito stesso) del fatto che le moltiplicazioni SSE o FP siano fatte con i medesimi transistor, e non mi dilungo nell'insegnargli architettura degli elaboratori un'altra volta :asd:

Prima di insegnarla a lui dovresti impararla tu, visto che non sta scritto da nessuna parte che due unita' diverse non possano condividere transistor per operazioni comuni. A meno che tu non stia facendo solo una crociata personale nei suoi confronti, in tal caso ti ricorderei che e' vietata dal regolamento del forum (e dalle banali norme di buona educazione e convivenza civile).

A parte le differenze implementative non vedo alcuna differenza concettuale fra l'unita' SSEx all'interno degli Intel e l'unita' Altivec all'interno dei PPC.

Una unità per essere considerata dedicata non puo' condividere transistor con altre, in particolare se le unità con cui condivide i transistor sono generiche come una floating point (Tantovero che le istruzioni SSE2 con 4 operandi a 32bit bit vengono eseguite in due unità di elaborazioni differenti nel caso del K8, ognuna una unità FP a 64 o 2x32 bit)
Altrimenti la conseguenza è che alcune istruzioni non ti permettono di eseguirne altre, conseguenza che viene spiegata nei manuali di programmazione; purtrppo pero' essendo fatti per programmatori e non per progettisti HW, mancano della spiegazione della causa che genera il problema.

Certo queste cose non li trovi mica nei manuali di programmazione, li trovi semmai nei manuali di (V)HDL, Verilog o altri linguaggi di progettazione elettronica.

P.S: il mio "astio" (se così si puo' definire) nei confronti di cdimauro nasce dal fatto che è il tipico utente che sa solo dispensare sentenze senza mai saper le spiegare. Il fatto che insista sul fatto di "invitare a leggere i manuali intel/powerPC/quellochetipare" è l'esempio più evidente di questo comportamento antisociale, che porta a sfottò inutili e a un livello di informazioni contenute nei post tendente allo zero.
La gente normale scrive sui forum per accrescere e condividere le sue conoscenze mediante apporti e scambi di informazioni, se quello che scrivi si limita a "vatti a leggere un manuale" (peraltro nemmeno linkabile) non sei dissimile da quello che posta un ASD o un ROTFL.

ma no scusami... non è quello che c'è scritto in quegli articoli...
E si che ti ho pure evidenziato in italic, il pezzo in cui stokes dice che intel continuerà sulla sua strada.
And though there's no word out on the FPU and SIMD units as of yet, I expect that Intel will continue its practice of combining the two types of execution units into a single functional block.

Per AMD lo vedi qua.
http://www.chip-architect.com/news/Opteron_FloatPnt_Core.jpg
Nell'Athlon 64 ad esempio abbiamo una unità FP capace di fare 2 MUL a 32bit dove vengono eseguite le normali operazioni FP semplici e complesse e poi una aggiuntiva (semplice) capace di fare 1 MUL a 64 bit. Aggiunta proprio per abbassare la latenza di una evntuale istruzione simd su 4 operandi a 32bit.


Beh che la pipeline delle altivec sia compresa nella pipeline principale nel G5 mi pare obbligato (ammesso che alla motorola non abbiano inventato un nuovo modo di fare le CPU), ma uno stadio di esecuzione di una ALU FP del G5 non ha nulla a che vedere con uno stadio di esecuzione dell'unità altivec, cosa invece differente nel G4 o nel P4 o nel K8.


Tutto corretto, a parte che di dedicato -come ha già spiegato stokes nell'articolo dell'IDF- per ora non si vede l'ombra nelle architetture x86, e dubita che intel cambierà strada.
Per AMD non si sa ancora cosa combinerà nel K9.
Tra l'altro nota che nel G4 le istruzioni altivec non sono processate in una unità isolata come nel G5, o meno così ho appreso da fonti online.

Non proprio, le unità FP e SSE negli X86 sono distinte tra loro, ma come ho detto sono nello stesso blocco funzionale (Il blocco indicato come FP/SSE), ossia condividono gli scheduler, ad esempio, ma NON le unità di esecuzione in senso stretto, tra l'altro logica di funzionamento parecchio differente tra di loro nello stadio di esecuzione vero e proprio (ad esempio i registri hanno ampiezze differenti, ecc.). Dipende quindi da quanto in dettaglio scendiamo. Ad esempio a questo punto nemmeno Altivec è completamente dedicata perchè richiede glis tadi di decode/fetch della pipe generale del PPC. Ad ogni modo questa soluzione è stata scelta per due motivi: il primo è risparmiare transistors, il secondo è quello che spiego nel seguito. In Altivec il blocco funzionale è distinto, quindi questa soluzione è più flessibile, ma anche negli X86 le unità di esecuzione vere e proprie sono dedicate solo alle SSE. Questo sta preludendo all'eliminazione dello stadio FPU tradizionale nei processori X86, che verranno sostituite in toto dalle architetture SIMD. Per esempio in Win XP-64 bit questo è già visibile.

PS: una unità può anche essere "dedicata" a più compiti.

Capisco il tuo punto di vista leoneazzurro, ma fino a che nel punto 2.6 del link che ti ho postato (http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html) concorda con quanto ho imparato da altri articoli e datasheets dicendo chiaramente che le unità FP eseguono le istruzioni SSE la vedo difficile dire che siano distinte tra loro.

Nel senso posso anche tenere per buona la tua affermazione, dopotutto non mi cambia la vita. Ma preferisco dare ascolto a chi pubblica un articolo serio linkato e ben supportato da altri siti, non credi?

Se le istruzini SSE2 non fossero boccate da una istruzione x87 avrei tutt'altra opinione, ma visti i fatti, è più che normale pensare che i moltiplicatori 32bit ad albero di wallace usati per una FMUL in un K8 sono i medesimi che si usano per una MULPD, no?

...da qui mi pare logica l'impossibilità di dire che un K8 ha una unità dedicata per le istruzioni SSE/SIMD.

PS: una unità può anche essere "dedicata" a più compiti.
Ma se è così non deve avere conflitti con altre istruzioni, altrimenti ogni concetto di unità dedicata in un DSP o altre ASIC di processori embedded andrebbe a farsi benedire. Non si puo' fare un dizionario a parte per le CPU x86, bisogna andare dal processore della ST a quello della Texas Instruments e così via.
Dedicata vuol dire che ogni volta che una istruzione va in dispatch verso lo stato di execute dell'unità stessa non deve attendere la fine dell'esecuzione di altre istruzioni dipendenti a set differenti (vedi SSE e x87).

Una unit

E questo dove sta scritto? Due core a cache condivisa, condividono, per l'appunto, un'intera cache ma vorrei vedere chi afferma che i due core non sono unita' dedicate e ben separate.

P.S: il mio "astio" (se così si puo' definire) nei confronti di cdimauro nasce dal fatto che è il tipico utente che sa solo dispensare sentenze senza mai saper le spiegare.

Il tuo astio nei confronti di qualunque utente non e' ne' affar mio ne' affare e interesse di nessun altro. Lo diventa quando questo rende un topic illeggibile. C'e' un regolamento al quale anche tu sei pregato di attenerti che te lo vieta.

Per ripsondere a cdimauro, la didascalia dell'immagine (da un sito per altro da lui linkatomi tempo fa).

"X87 AND SSE FLOATING POINT MULTIPLIER"

Penso sia abbastanza eloquente (oltre a quanto detto da stokes e dal sito stesso) del fatto che le moltiplicazioni SSE o FP siano fatte con i medesimi transistor, e non mi dilungo nell'insegnargli architettura degli elaboratori un'altra volta :asd:

Effettivamente sarebbe bastato che cidimauro leggesse i siti che linka :rolleyes:
http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

The x87 and SSE2 floating point multiplier handles 64 and 80 extended length multiplications. The large Wallace tree which handle the 64 bit multiplications for 80 bit extended floating point and 64 bit integer multiplications can be split into two independent Wallace trees that handle the dual 32 bit SIMD multiplications used for SSE and 3Dnow functions (US Patent 6,490,607)

Aurevoir :)

Post Scriptum: nessuno vi obbliga a prendere per buono quello che c'è scritto in questi siti, chiaramente se trovate altre fonti più serie che dicano il contrario sono ben contento di essere smentito.

P.P.S:

Problema che non sussisterebbe se le SSE avessero la loro unità SIMD dedicata.
Ovviamente il mio messaggio nemmeno l'hai letto, visto che riporto le STESSE cose... :mc:

:muro: :muro: :muro:

Il tuo astio nei confronti di qualunque utente non e' ne' affar mio ne' affare e interesse di nessun altro. Lo diventa quando questo rende un topic illeggibile. C'e' un regolamento al quale anche tu sei pregato di attenerti che te lo vieta.
Illeggibile?
Spero tu stia scherzando, ma realmente.

Io quoto il minimo indispensabile e tendo ad evidenziare ogni parte importante delle cose che linko, se ti da fastidio l'immagine troppo grande dimmelo che metto online una thumbnail.
Semmai se un topic è illeggibile devi prendertela con chi fa quote selvaggi che fanno perdere il filo del discorso anche a cicerone.

P.S: il mio "astio" (se così si puo' definire) nei confronti di cdimauro nasce dal fatto che è il tipico utente che sa solo dispensare sentenze senza mai saper le spiegare. Il fatto che insista sul fatto di "invitare a leggere i manuali intel/powerPC/quellochetipare" è l'esempio più evidente di questo comportamento antisociale, che porta a sfottò inutili e a un livello di informazioni contenute nei post tendente allo zero.
La gente normale scrive sui forum per accrescere e condividere le sue conoscenze mediante apporti e scambi di informazioni, se quello che scrivi si limita a "vatti a leggere un manuale" (peraltro nemmeno linkabile) non sei dissimile da quello che posta un ASD o un ROTFL.
Il tuo astio nasce soltanto dalle bastonate che hai ricevuto in passato e che ancora ti fanno male. E ti sono arrivate perché, nonostante le chiarissime spiegazioni, hai cercato di trolleggiare per uscire dalle discussioni con la faccia pulita.

Discussioni in cui hai preteso addirittura di tenere lezioni sulle architetture dei processori, parlando di quella x86 in particolare e in cui ha dimostrato di non sapere neppure scrivere una banalissima e comunissima ADD.

Infine prima ho fatto un esempio DESCRITTIVO, e quindi per rendere più semplice e fruibile i concetti, di come Altivec e le SIMD x86 siano simili, per spiegarne il funzionamento in linea generale, e ho scritto di verificare sugli appositi manuali per verificare l'attendibilità di tutto ciò.

:muro: :muro: :muro:
E' esattamente quel che penso anch'io: sei irrecuperabile.

Capisco il tuo punto di vista leoneazzurro, ma fino a che nel punto 2.6 del link che ti ho postato (http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html) concorda con quanto ho imparato da altri articoli e datasheets dicendo chiaramente che le unità FP eseguono le istruzioni SSE la vedo difficile dire che siano distinte tra loro.

Nel senso posso anche tenere per buona la tua affermazione, dopotutto non mi cambia la vita. Ma preferisco dare ascolto a chi pubblica un articolo serio linkato e ben supportato da altri siti, non credi?

Se le istruzini SSE2 non fossero boccate da una istruzione x87 avrei tutt'altra opinione, ma visti i fatti, è più che normale pensare che i moltiplicatori 32bit ad albero di wallace usati per una FMUL in un K8 sono i medesimi che si usano per una MULPD, no?

...da qui mi pare logica l'impossibilità di dire che un K8 ha una unità dedicata per le istruzioni SSE/SIMD.
Si è parlato chiaramente di unità funzionali e unità di esecuzione, infatti, e della relazione fra le due cose.
Ma se è così non deve avere conflitti con altre istruzioni, altrimenti ogni concetto di unità dedicata in un DSP o altre ASIC di processori embedded andrebbe a farsi benedire. Non si puo' fare un dizionario a parte per le CPU x86, bisogna andare dal processore della ST a quello della Texas Instruments e così via.
Dedicata vuol dire che ogni volta che una istruzione va in dispatch verso lo stato di execute dell'unità stessa non deve attendere la fine dell'esecuzione di altre istruzioni dipendenti a set differenti (vedi SSE e x87).
Quando capirai che NON è un problema di conflitto fra i diversi tipi di istruzioni, ma di conflitto di attribuzione delle unità di esecuzione? Lo stiamo scrivendo da un pezzo!

Infatti è possibilissimo eseguibile istruzioni SSE E (congiunzione) x87/MMX allo stesso tempo, PURCHE' NON UTILIZZINO LE MEDESIME UNITA' DI ESECUZIONE.

Che poi è quello che trovi scritto sui manuali Intel. Ma tu, come ho già detto, ad essi preferisci i link che trovi in giro su google, e che tra l'altro riportano le stesse informazioni. :rolleyes:

Illeggibile?
Spero tu stia scherzando, ma realmente.

Al contrario, sono molto serio. Il tuo astio come ti ho detto non mi interessa e puoi risolverlo in privato.

:muro: :muro: :muro:


Illeggibile?
Spero tu stia scherzando, ma realmente.

Io quoto il minimo indispensabile e tendo ad evidenziare ogni parte importante delle cose che linko, se ti da fastidio l'immagine troppo grande dimmelo che metto online una thumbnail.
Semmai se un topic è illeggibile devi prendertela con chi fa quote selvaggi che fanno perdere il filo del discorso anche a cicerone.
Più che altro dà fastidio il tuo scrivere messaggi, per poi editarli subito dopo aggiungendo altro testo (in questo caso hai aggiunto TUTTE le parole: prima c'erano soltanto le 3 faccine che sbattevano contro un muro).

Capisco il tuo punto di vista leoneazzurro, ma fino a che nel punto 2.6 del link che ti ho postato (http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html) concorda con quanto ho imparato da altri articoli e datasheets dicendo chiaramente che le unità FP eseguono le istruzioni SSE la vedo difficile dire che siano distinte tra loro.

Nel senso posso anche tenere per buona la tua affermazione, dopotutto non mi cambia la vita. Ma preferisco dare ascolto a chi pubblica un articolo serio linkato e ben supportato da altri siti, non credi?

Se le istruzini SSE2 non fossero boccate da una istruzione x87 avrei tutt'altra opinione, ma visti i fatti, è più che normale pensare che i moltiplicatori 32bit ad albero di wallace usati per una FMUL in un K8 sono i medesimi che si usano per una MULPD, no?

...da qui mi pare logica l'impossibilità di dire che un K8 ha una unità dedicata per le istruzioni SSE/SIMD.


Ma se è così non deve avere conflitti con altre istruzioni, altrimenti ogni concetto di unità dedicata in un DSP o altre ASIC di processori embedded andrebbe a farsi benedire. Non si puo' fare un dizionario a parte per le CPU x86, bisogna andare dal processore della ST a quello della Texas Instruments e così via.
Dedicata vuol dire che ogni volta che una istruzione va in dispatch verso lo stato di execute dell'unità stessa non deve attendere la fine dell'esecuzione di altre istruzioni dipendenti a set differenti (vedi SSE e x87).

IMHO è semplicemente una questione di punti di vista. E' chiaro che l'unità non può svolgere determinate operazioni FP e SIMD contemporaneamente, ma a mio parere le unità sono "dedicate" sia ai compiti FP che SIMD.
Però essendo un'interpretazione semantica credo che ognuno rimarrà con il suo punto di vista... ;)

Perfettamente d'accordo. Inoltre la differenza fra unità funzionale e unità di esecuzione è chiarissima: non servono interpretazioni, IMHO.

Più che altro dà fastidio il tuo scrivere messaggi, per poi editarli subito dopo aggiungendo altro testo (in questo caso hai aggiunto TUTTE le parole: prima c'erano soltanto le 3 faccine che sbattevano contro un muro).
"Meglio editare un post che aggiungerne un'altro" è una buona regola che dovresti considerare di più quando posti.
Tanto quello che era riferito a te l'hai capito.

Al contrario, sono molto serio. Il tuo astio come ti ho detto non mi interessa e puoi risolverlo in privato.
Non so se noti, ma dei post di cidimauro non li guardo nemmeno più di tanto, almeno fino a che non porta link seri e ben informati, cosa che tende a non fare mai.

Io sto seguendo una normalissima discussione con normalissimi scambi di opinione, come ad esempio ho fatto nella recente thread sui server CELL.
Che poi sia restio a cambiare la mia opinione è solamente dato dal fatto che chi ne ha di differenti non trova abbastanza argomentazioni con i dovuti riferimenti per convincermi.

IMHO è semplicemente una questione di punti di vista. E' chiaro che l'unità non può svolgere determinate operazioni FP e SIMD contemporaneamente, ma a mio parere le unità sono "dedicate" sia ai compiti FP che SIMD.
Però essendo un'interpretazione semantica credo che ognuno rimarrà con il suo punto di vista...
Vero anche questo, dipende pero' che tipologia di conoscenza hai alle spalle: dal mio punto di vista se prendo un chip embedded con cui ho fatto alcune esperienze, un DSP TI che convertiva stream audio-video mpeg2 in filmati RGB + audio wave, se l'unità di decodifica audio fosse stata la stessa usata per decodificare il video (come in altri DSP) alcuni formati non sarebbero mai potuti essere riprodotti in real time (esempio stupido, ma spero renda l'idea)

Rimane il fatto che se si è parlato di unità vettoriale dedicata nel merom, sicuramente sottointendeva il fatto che le SSE di dedicato hanno ben poco, vuoi perchè come ha detto cdimauro la tendenza è usare le SSE al posto delle FP, o vuoi perchè una unità dedicata costa di più produrla.
Pero' se l'hanno messa nel G5 per le altivec vuol dire che ne valeva la pena, no? Vuoi perchè così hanno potuto implementare lo stream di dati, vuoi per altri motivi, ma l'han fatto.

Non so se noti, ma dei post di cidimauro non li guardo nemmeno più di tanto,

Non faccio fatica a crederti.

Vero anche questo, dipende pero' che tipologia di conoscenza hai alle spalle: dal mio punto di vista se prendo un chip embedded con cui ho fatto alcune esperienze, un DSP TI che convertiva stream audio-video mpeg2 in filmati RGB + audio wave, se l'unità di decodifica audio fosse stata la stessa usata per decodificare il video (come in altri DSP) alcuni formati non sarebbero mai potuti essere riprodotti in real time (esempio stupido, ma spero renda l'idea)


Beh, qui c'entra anche la potenza elaborativa dell DSP in questione, del resto nei sistemi PC fino a qualche tempo fa i flussi MPEG-2 dei DVD venivano decodificati dalla CPU (principalmente nell unità FP/MMX/SSE) sia dal punto di vista audio che video ;)
Chiaramente la soluzione AltiVec è più efficiente.


Pero' se l'hanno messa nel G5 per le altivec vuol dire che ne valeva la pena, no? Vuoi perchè così hanno potuto implementare lo stream di dati, vuoi per altri motivi, ma l'han fatto.

Per l'efficienza e per la possibilità di inviare stream alle unità SIMD, lo svantaggio è che ovviamente queste unità occupano più transistor.

"Meglio editare un post che aggiungerne un'altro" è una buona regola che dovresti considerare di più quando posti.
La regola migliore è non postare finché non si ha chiaro in mente ciò che si vuole scrivere.
Tanto quello che era riferito a te l'hai capito.
Idem.
Non so se noti, ma dei post di cidimauro non li guardo nemmeno più di tanto, almeno fino a che non porta link seri e ben informati, cosa che tende a non fare mai.

Io sto seguendo una normalissima discussione con normalissimi scambi di opinione, come ad esempio ho fatto nella recente thread sui server CELL.
Che poi sia restio a cambiare la mia opinione è solamente dato dal fatto che chi ne ha di differenti non trova abbastanza argomentazioni con i dovuti riferimenti per convincermi.
Tutto qui? Non ci vuole molto: ftp://download.intel.com/design/Pentium4/manuals/25366518.pdf

10.2.4 Compatibility of SSE Extensions with SSE2/SSE3/MMX
and the x87 FPU

The state (XMM registers and MXCSR register) introduced into the IA-32 execution environment with the SSE extensions is shared with SSE2 and SSE3 extensions. SSE/SSE2/SSE3 instructions are fully compatible; they can be executed together in the same instruction stream with no need to save state when switching between instruction sets.

XMM registers are independent of the x87 FPU and MMX registers, so SSE/SSE2/SSE3 operations performed on the XMM registers can be performed in parallel with operations on the x87 FPU and MMX registers (see Section 11.6.7, “Interaction of SSE/SSE2 Instructions with x87 FPU and MMX Instructions”).

The FXSAVE and FXRSTOR instructions save and restore the SSE/SSE2/SSE3 states along with the x87 FPU and MMX state.
E per finire, ecco i dettagli precisi di tutto ciò:
11.6.7 Interaction of SSE/SSE2 Instructions with x87 FPU and
MMX Instructions

The XMM registers and the x87 FPU and MMX registers represent separate execution environments, which has certain ramifications when executing SSE, SSE2, MMX, and x87 FPU instructions in the same code module or when mixing code modules that contain these instructions:

• Those SSE and SSE2 instructions that operate only on XMM registers (such as the packed and scalar floating-point instructions and the 128-bit SIMD integer instructions) in the same instruction stream with 64-bit SIMD integer or x87 FPU instructions without any restrictions. For example, an application can perform the majority of its floating-point computations in the XMM registers, using the packed and scalar floating-point instructions, and at the same time use the x87 FPU to perform trigonometric and other transcendental
computations. Likewise, an application can perform packed 64-bit and 128-bit
SIMD integer operations together without restrictions.

• Those SSE and SSE2 instructions that operate on MMX registers (such as the CVTPS2PI, CVTTPS2PI, CVTPI2PS, CVTPD2PI, CVTTPD2PI, CVTPI2PD, MOVDQ2Q, MOVQ2DQ, PADDQ, and PSUBQ instructions) can also be executed in the same instruction stream as 64-bit SIMD integer or x87 FPU instructions, however, here they are subject to the restrictions on the simultaneous use of MMX technology and x87 FPU instructions, which include:

— Transition from x87 FPU to MMX technology instructions or to SSE or SSE2 instructions that operate on MMX registers should be preceded by saving the state of the x87 FPU.
— Transition from MMX technology instructions or from SSE or SSE2 instructions that operate on MMX registers to x87 FPU instructions should be preceded by execution of the EMMS instruction.
Cioé ESATTAMENTE ciò che avevo detto io.

Come vedi "basta" studiarsi i manuali Intel per capire come funziona l'architettura x86, anziché andare in giro a caccia di informazioni sul web che lasciano il tempo che trovano.
Rimane il fatto che se si è parlato di unità vettoriale dedicata nel merom, sicuramente sottointendeva il fatto che le SSE di dedicato hanno ben poco, vuoi perchè come ha detto cdimauro la tendenza è usare le SSE al posto delle FP, o vuoi perchè una unità dedicata costa di più produrla.
Pero' se l'hanno messa nel G5 per le altivec vuol dire che ne valeva la pena, no? Vuoi perchè così hanno potuto implementare lo stream di dati, vuoi per altri motivi, ma l'han fatto.
Il motivo è da ricercare, IMHO, nel modo in cui è arrivato il G5: per castrazione del POWER4 di IBM e aggiunta dell'unità Altivec. Infatti anche nelle parti del documento che hai riportato Hannibal lo fa notare.

Questa scelta mi sembra normale e condivisibile, perché IBM altrimenti avrebbe dovuto riprogettare il processore per buona parte, se avesse voluto risparmiare i transistor della sezione Altivec, "riciclando" quelli già presenti nella FPU.

D'altra parte, come ho già detto, è molto difficile che un algoritmo possa avvantaggiarsi dell'uso contemporaneo dell'FPU e della sezione Altivec.

Tutto qui? Non ci vuole molto: ftp://download.intel.com/design/Pentium4/manuals/25366518.pdf
Appunto... non ci vuole molto, pensa a quanti post hai fatto in cui potevi mettere questo link.

Come vedi "basta" studiarsi i manuali Intel per capire come funziona l'architettura x86, anziché andare in giro a caccia di informazioni sul web che lasciano il tempo che trovano.
In realtà anche spulciandoselo bene, non vengono nemmeno nominate, ma neanche in lontananza le possibili "unità vettoriali SSE", l'unica unità che viene nominata nel contesto delle SSE è la FPU, e soprattutto non c'è l'ombra di come siano organizzate le pipeline, come reagiscano ad ogni istruzione nè quanti cicli si perdano in determinate condizioni.
Il tuo link dice che sono perfettamente compatibili (sempre che si usino i registri XMM, perchè se usano registri MMX il discorso è diverso), pero' non vedo nessun riferimento ad unità discrete dedicate alle istruzioni SSE.

Ma come c'era da aspettarselo, è un manuale per programmatori: spiega solo un aspetto, tralasciandone molti altri.

Quindi affermare che le istruzioni Altivec sono alla stregua delle SIMD negli x86 è un po' un azzardo ;). Infatti il divario prestazionale (image editing, editing video...) tra le due architetture è evidente, ancor di più se si considera la mediocrità prestazionale del resto delle unità logiche di un G5.

P.S: le informazioni che trovi sul web spesso sono riportate da gente che puo' anche avere in bagaglio di conoscenze diverso dal tuo, magari invece di dire "lasciano il tempo che trovano" potresti dargli più peso che non fa male, è sempre un modo per arricchire la propria cultura.

D'altra parte, come ho già detto, è molto difficile che un algoritmo possa avvantaggiarsi dell'uso contemporaneo dell'FPU e della sezione Altivec.
In una situazione single thread si, non hai considerato una situazione multi thread, magari sfruttando l'SMT. In quel caso il codice puo' essere molto più vario e molto più difficile da controllare, e se è vero che l'SMT esegue il codice in modo trasparente al programmatore non considera l'eventuale perdita di prestazioni che puo' avere un certo mix di istruzioni.

Il vantaggio, come ho scritto rispondendo a leoneazzurro, sta nel fatto che una unità dedicata la puoi sviluppare in futuro ampliandone le funzioni, magari secondo le necessità degli algoritmi più usati al momento. Sfruttando altre unità della CPU, sei molto più vincolato. Rischi che ti costi di più in transistor la logica che fa il dispatch delle istruzioni e prepara il context di registri per questa unità, rispetto a creare una unità di esecuzione separata.

Comunque a sto punto conviene veramente aspettare Windows Vista per comprare un PC nuovo... :asd:

Comunque a sto punto conviene veramente aspettare Windows Vista per comprare un PC nuovo... :asd:

io aspetterei il sp1 prima di passare a windows vista (esperienza con 95(95A),98(98SE)XP (Sp1/2) insegna che con MS al primo colpo si fa da betaTester e ciò non è bello :mad: :mad: :mad: )

io aspetterei il sp1 prima di passare a windows vista (esperienza con 95(95A),98(98SE)XP (Sp1/2) insegna che con MS al primo colpo si fa da betaTester e ciò non è bello :mad: :mad: :mad: )

Stai fresco allora ti conviene aspettare direttamente i computer quantici :asd:
Io comunque non ho mai avuto problemi di alcuna sorta da Windows 3.1 ...

Ho capito il problema tra Dreadnought e CDmauro:

Altivec e SSEx sono comparabili a livello di ISA (come dice cdmauro): cioè possono fare più o meno le stesse cose.

Altivec ha il supporto agli stream e a 3 o 4 operandi, SSEx ha un set di istruzioni più ricco (menziono solo le varie combinazioni di packing/unpacking ecc). Anche se c'è il non temporal move, che non inquina la cache L2 e L1 (a seconda della scelta del programmatore... C'è anche una fantomatica cache L0, forse per implementazioni future... ) e può essere usato come una sorta di stream multipli...

Il problema è che Dreadnought si riferisce all'IMPLEMENTAZIONE sulle due architetture:

Altivec (sul G5) può fare contemporaneamente una istruzione con una FPU NELLO STESSO CICLO DI CLOCK, perchè le unità funzionali sono separate (io non lo so: prendo per buono quello che ha detto).

Dice che con gli intel ciò non si può fare. Ha ragione: il P4 può fare solo una istruzione FP per ciclo, sia essa FP o SSE.

Ma l'A64 no!

E' questo a cui si riferisce cdmauro: è possibile fare una addizione FP e CONTEMPORANEAMENTE NELLO STESSO CICLO una moltiplicazione SSE, perchè l'A64 può fare FINO a 3 operazioni FP e/o SSE per ciclo di clock...

Ma questo riguarda l'implementazione e non l'ISA!

Tanto è vero che il G4 è un po' come il P4 (anche qui non lo so e mi affido a quanto precedentemente detto), non potendo fare FP e altivec contemporaneamente...

In sostanza, se Dread si riferiva all'implementazione e cdmauro alle "specifiche" ... hanno ragione entrambi!

E' questo a cui si riferisce cdmauro: è possibile fare una addizione FP e CONTEMPORANEAMENTE NELLO STESSO CICLO una moltiplicazione SSE, perchè l'A64 può fare FINO a 3 operazioni FP e/o SSE per ciclo di clock...
sicuro che l'A64 puo' fare una MULPD a 128 bit su 4 operandi a 32bit e in contemporanea eseguire una FMUL, mantenendo il massimo di 4 cicli di clock?

Il problema, sia nel P4 che nel K8 sta nei bit dell'istruzione, se usi 64bit puoi mixare SSE e FP (con alcune piccole restrizioni sui registri), ma se le SSE sono a 128bit entrano in gioco le ALU/MUL per le SSE2 assieme a quelle FP, questo per garantire che vengano eseguite le 4 operazioni a 32bit con la latenza minima (es una MULPD dovrebbe impiegare 6 cicli per i P4 e 4 cicli per i K8)

Infatti ho detto che può fare una ADD FP e una MUL SSE (o viceversa) in contemporanea se rileggi bene... :D

Questo perchè l'A64 ha UNA unità FP ADD (anche SSE, ma con un ciclo in più di latenza) e una FP MUL (anche SSE, non so i cicli in pù di latenza)... Non può fare 2 Addizioni o due moltiplicazioni contemporanee...

Mi fido della seconda parte del post... :D

E' chiaro che ci sono limitazioni, non essendo le unità distinte, ma:

1) E' raro che si usi codice FP e SSE mixato, anche perchè è complicato e comunque inefficiente passare i dati dai registri x87 ai registri SSE: o usi SSE, o usi FP x87.
2) Anche se lo si fa, in alcuni casi si può andare in parallelo (come ho detto prima).
3) A meno che non ti servono i long double (80 bit) o le eccezioni, o la stretta conformanza allo standard IEEE 754 (o 854, quello nuovo), solo un pazzo non userebbe le SSE che ti consentono, sulla carta, fino al quadruplo delle prestazioni (che poi negli A64 solo il doppio, va beh, ma se in un futuro sarà implementata una FPU che eseque 4 calcoli in parallelo...)

Se ti interessa qua ci sono le latenze per P4 ;)
http://srl.cs.jhu.edu/~swaroop/ia32/Intel0.pdf (Le tabelle della sezione C)

Appunto... non ci vuole molto, pensa a quanti post hai fatto in cui potevi mettere questo link.
Se l'avessi chiesto prima, t'avrei accontentato.
In realtà anche spulciandoselo bene, non vengono nemmeno nominate, ma neanche in lontananza le possibili "unità vettoriali SSE", l'unica unità che viene nominata nel contesto delle SSE è la FPU,
Infatti, e lo ripetiamo nuovamente, si tratta di un'unità funzionale che gestisce le "unità" FPU x87, MMX e SSE, con le dipendenze del caso.
e soprattutto non c'è l'ombra di come siano organizzate le pipeline, come reagiscano ad ogni istruzione nè quanti cicli si perdano in determinate condizioni.
Non c'è la struttura della pipeline dell'unità SIMD di quella "comune", ma soltanto quella intera. Comunque serve a poco all'atto pratico: bastano le tabelle che riportano le latenze e il throughput delle varie istruzioni, e che si trovano nel documento di cui hai fornito il link dopo (sul sito della Intel c'è quello più aggiornato), e che riporta tra l'altro quali unità di esecuzione vengono impegnate dalle varie istruzioni.
Il tuo link dice che sono perfettamente compatibili (sempre che si usino i registri XMM, perchè se usano registri MMX il discorso è diverso), pero' non vedo nessun riferimento ad unità discrete dedicate alle istruzioni SSE.
Infatti non ce ne sono, e il discorso ormai dovrebbe essere chiaro.
Ma come c'era da aspettarselo, è un manuale per programmatori: spiega solo un aspetto, tralasciandone molti altri.
Quello è il manuale di riferimento "base" dell'architettura: poi ci sono quelli (sono due) per ogni singola istruzione, e quello delle ottimizzazioni che contengono i dati che servono per capire in che modo funzionano le istruzioni FPU, MMX e SSE.
Quindi affermare che le istruzioni Altivec sono alla stregua delle SIMD negli x86 è un po' un azzardo ;). Infatti il divario prestazionale (image editing, editing video...) tra le due architetture è evidente, ancor di più se si considera la mediocrità prestazionale del resto delle unità logiche di un G5.
Mi stai dicendo di valutare un set d'istruzioni (ti ricordo che si parlava di unità vettoriali) soltanto dal punto di vista prestazionale (che comunque è tutt'altro che disastroso, come vorresti far credere)?
P.S: le informazioni che trovi sul web spesso sono riportate da gente che puo' anche avere in bagaglio di conoscenze diverso dal tuo, magari invece di dire "lasciano il tempo che trovano" potresti dargli più peso che non fa male, è sempre un modo per arricchire la propria cultura.
Leggo anch'io quei siti per conoscere l'opinione di altre persone in materia, ma il punto di riferimento per quanto mi riguarda rimane sempre la documentazione tecnica che la casa madre mette a disposizione.
In una situazione single thread si, non hai considerato una situazione multi thread, magari sfruttando l'SMT. In quel caso il codice puo' essere molto più vario e molto più difficile da controllare, e se è vero che l'SMT esegue il codice in modo trasparente al programmatore non considera l'eventuale perdita di prestazioni che puo' avere un certo mix di istruzioni.
Non vedo particolari differenze rispetto al modello single thread: anche con le istruzioni intere ci sono sempre problemi di attribuzione delle risorse. Se, ad esempio, devo eseguire due istruzioni di shift e c'è solamente un'unità deputata a tale compito, non posso farci niente: la seconda dovrà aspettare che la prima abbia finito per poterla usare.

Inoltre dimentichi che i sistemi SMT (soltanto i P4 HT, comunque: AMD coi K7/K8 e Intel stessa coi P3/Pentium-M non implementano questa tecnologia) sono nati per cercare di sfruttare meglio le unità di esecuzione presenti sul chip, per cui se è vero che i "contenziosi" per l'attribuzione delle unità di esecuzione aumentano, è anche vero che meno unità di esecuzione rimangono inutilizzate, migliorando globalmente (anche se non sempre) le prestazioni.

Altra cosa, nei sistemi SMT il limite delle 3 micro-op inviate dalla Trace Cache 3 alle code rimane per tutti e due i thread (3 micro-op in tutto, e non 3 per ogni thread).
Il vantaggio, come ho scritto rispondendo a leoneazzurro, sta nel fatto che una unità dedicata la puoi sviluppare in futuro ampliandone le funzioni, magari secondo le necessità degli algoritmi più usati al momento. Sfruttando altre unità della CPU, sei molto più vincolato. Rischi che ti costi di più in transistor la logica che fa il dispatch delle istruzioni e prepara il context di registri per questa unità, rispetto a creare una unità di esecuzione separata.
Questa logica comunque c'è già, e viene usata tanto per le istruzioni intere quanto per quelle di FPU x87/MMX ed SSE.

Inoltre, come ti ho già detto, è molto difficile che un algoritmo possa far uso di FPU e unità SIMD (e nonostante tutto, è possibile farlo anche con l'FPU x87/MMX e le SSE).

Tra l'altro è molto più conveniente, invece, avere un'unità funzionale che si gestisca tutte le risorse disponibili (le unità di esecuzione), piuttosto che due unità separate con le proprie unità di esecuzione (che possono tranquillamente rimanere inutilizzate).

Infatti è possibilissimo che vengano aggiunte altre unità di esecuzione all'unità funzionale, migliorando le capacità di elaborazione per un certo tipo di codice. Guarda caso è quello che Intel ha fatto col Prescott.

Infatti, e lo ripetiamo nuovamente, si tratta di un'unità funzionale che gestisce le "unità" FPU x87, MMX e SSE, con le dipendenze del caso.
La semantica non cambia l'architettura di una CPU, le SSE sono processate dall'unità FP, diversamente da come accade nel G5.
Onde per cui ->
- x86 non ha unità dedicata per le SSE, chiamalo come ti pare, fatto sta che per avere prestazioni del G5 in questo campo devi alzare il clock e pompare cache e BUS.
- G5 ha unità dedicata alle istruzioni altivec, onde per cui ha prestazioni superiori, nonostante il resto di un sistema G5 sia mediocre

Infatti non ce ne sono, e il discorso ormai dovrebbe essere chiaro.
Si ma il discorso della compatibilità è ininfluente in questo caso, come vedi ad esempio nel K8 se ci sono 2 MUL-FP a 32bit e 1 MUL-FP a 64 bit, per svolgere una MULPD con la latenza della FMUL (e non il doppio) o ci si inventano i transistor oppure devi usare sia l'unità FP che quella SSE.

La compatibilità indica solo quali istruzioni puoi inserire in un tuo codice mica quali istruzioni sono processate e in che modo nella pipeline.

Mi stai dicendo di valutare un set d'istruzioni (ti ricordo che si parlava di unità vettoriali) soltanto dal punto di vista prestazionale (che comunque è tutt'altro che disastroso, come vorresti far credere)?
Guarda che nessuno sta valutando un set di istruzioni, quello è ciò che hai fatto tu perchè chiaramente è il tuo campo (da quanto ho capito), da un po' di post sto cercando di spiegare che il fatto di avere una unità dedicata ha prestazioni superiori a quando l'unità dedicata non c'è. Sto parlando di architettura di una CPU non di manuali intel.
Che poi per riuscire a farti comprendere un concetto faccio lo sforzo di entrare nel tuo campo (non completamente pertinente tra l'altro) è un altro discorso.

Secondo te tutti si chiedevano se nel Merom ci fosse una unità SIMD dedicata solo per poterla vedere nello schemino del DIE e "dire OOOOOOOOh che bello, una unità dedicataaaaaaaa figoooo" :asd:
O forse per il fatto che avrebbe portato interessanti prospettive di prestazioni in più e magari anche consumi minori?

Leggo anch'io quei siti per conoscere l'opinione di altre persone in materia, ma il punto di riferimento per quanto mi riguarda rimane sempre la documentazione tecnica che la casa madre mette a disposizione.
Ogni difetto ti passerà quindi inosservato in questo modo ;)

Dimenticavo: latenze AMD (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF)

La semantica non cambia l'architettura di una CPU, le SSE sono processate dall'unità FP, diversamente da come accade nel G5.
Onde per cui ->
- x86 non ha unità dedicata per le SSE, chiamalo come ti pare, fatto sta che per avere prestazioni del G5 in questo campo devi alzare il clock e pompare cache e BUS.
Se poi ci spieghi anche il collegamento logico

mancanza di unità dedicata SIMD -> prestazioni scarse -> necessità di aumentare clock, cache e bus

ci fai un favore, visto che non è affatto chiaro.
- G5 ha unità dedicata alle istruzioni altivec, onde per cui ha prestazioni superiori, nonostante il resto di un sistema G5 sia mediocre
Le prestazioni non dipendono dal fatto che l'unità Altivec del G5 sia "dedicata".

Sono molti i fattori che incidono, fra cui quello sicuramente molto importante è la mancanza di sommatori e moltiplicatori aggiuntivi per le implementazioni SIMD x86 ATTUALI.
Si ma il discorso della compatibilità è ininfluente in questo caso, come vedi ad esempio nel K8 se ci sono 2 MUL-FP a 32bit e 1 MUL-FP a 64 bit, per svolgere una MULPD con la latenza della FMUL (e non il doppio) o ci si inventano i transistor oppure devi usare sia l'unità FP che quella SSE.
Io non ho mai parlato di compatibilità, ma di UNITA' DI ESECUZIONE CONDIVISE dalle tre sezioni (FPU x87/MMX e SSE).
La compatibilità indica solo quali istruzioni puoi inserire in un tuo codice mica quali istruzioni sono processate e in che modo nella pipeline.
Infatti.
Guarda che nessuno sta valutando un set di istruzioni, quello è ciò che hai fatto tu perchè chiaramente è il tuo campo (da quanto ho capito), da un po' di post sto cercando di spiegare che il fatto di avere una unità dedicata ha prestazioni superiori a quando l'unità dedicata non c'è. Sto parlando di architettura di una CPU non di manuali intel.
E stai continuando a confondere le prestazioni con la presenza o meno di unità dedicate, quando il nocciolo della questione verte invece sulla MANCANZA DI UNITA' DI ESECUZIONE nell'unità funzionale che inglobale FPU x87/MMX e SSE).
Che poi per riuscire a farti comprendere un concetto faccio lo sforzo di entrare nel tuo campo (non completamente pertinente tra l'altro) è un altro discorso.
Guarda che non sono io ad avere problemi di comprensione: te lo stiamo ripetendo in tanti come stanno le cose, ma continui a non voler vedere o a spostare il discorso su un altro piano. :rolleyes:
Secondo te tutti si chiedevano se nel Merom ci fosse una unità SIMD dedicata solo per poterla vedere nello schemino del DIE e "dire OOOOOOOOh che bello, una unità dedicataaaaaaaa figoooo" :asd:
O forse per il fatto che avrebbe portato interessanti prospettive di prestazioni in più e magari anche consumi minori?
Le prestazioni arrivano dall'aumento delle unità di esecuzione a cui è possibile smistare le operazioni da svolgere, non dal fatto che un'unità sia indipendente o meno.
Ogni difetto ti passerà quindi inosservato in questo modo ;)
Non ho mai detto che butto a mare ciò che dicono gli altri: ho detto, invece, che leggo i pareri degli altri, ma tengo come riferimento la documentazione di Intel. Se il parere degli altri non mi interessasse, non sprecherei il mio tempo a leggerlo.

Che poi, a dirla tutta, e come ha già detto cdmauro, ma voglio ribadirlo più esplicitamente:

Il fatto che per eseguire una istruzione SSEx uso moltiplicatori e addizionatori dell'unita FP, posto che siano sufficienti, è un bene. Se non ho istruzioni SIMD da processare (sul G5) (ed anche se ho solo istruzioni SIMD e non FPU classiche), ci sono dei moltiplicatori e addizionatori che stanno a girarsi i pollici, sull'A64 no! Che spreco di transistors e di energia! (P.S.: forse è anche per questo che il G5 consuma di più del G4 ;) )

E poi dalla teoria delle code, due "serventi" con coda unica sono più efficienti di due "serventi" con coda separata...

Perfettamente d'accordo, ma non so quante volte lo dovrò ripetere ancora... :muro:

Se poi ci spieghi anche il collegamento logico

mancanza di unità dedicata SIMD -> prestazioni scarse -> necessità di aumentare clock, cache e bus
ci fai un favore, visto che non è affatto chiaro.
Perchè parli al plurale?

Le prestazioni non dipendono dal fatto che l'unità Altivec del G5 sia "dedicata".

Sono molti i fattori che incidono, fra cui quello sicuramente molto importante è la mancanza di sommatori e moltiplicatori aggiuntivi per le implementazioni SIMD x86 ATTUALI.
Chissà perchè non sono riusciti ad integrarli nella FP... forse lo skew e le incoerenze erao già abbastanza elevate con le normali unità, figurati aggiungendo altra roba :rolleyes:
In genere la soluzione a questi problemi è isolare l'unità (così si accorciano gli alberi di clock) invece di metterla "in un unico blocco funzionale".

Io non ho mai parlato di compatibilità, ma di UNITA' DI ESECUZIONE CONDIVISE dalle tre sezioni (FPU x87/MMX e SSE).
In realtà in questo thread si stava parlando delle due possibili soluzioni sul merom:
1) che possa integrare una nuova unità multimediale
2) se invece avrà il solito potenziamento delle unità esistenti

Mi pare che oltre al fatto che stai girando la frittata un po' come vuoi tu, non hai affatto discusso su questo, ma come sempre cerchi di divagare nel discorso tirando fuori altri argomenti...

Guarda che non sono io ad avere problemi di comprensione: te lo stiamo ripetendo in tanti come stanno le cose, ma continui a non voler vedere o a spostare il discorso su un altro piano. :rolleyes:
In tanti?
Cos'è una messa ai voti? :asd:

Le prestazioni arrivano dall'aumento delle unità di esecuzione a cui è possibile smistare le operazioni da svolgere, non dal fatto che un'unità sia indipendente o meno.
altra volta... (la seconda non te la quoto nemmeno) forse non hai capito che in una unica FP se vuoi impacchettare tutto in un unica unità di esecuzione o aumenti gli stadi oppure la tua CPU avrà evidenti problemi di salita di clock.

L'unità dedicata ti evita questo problema, perchè aggiungendo un percorso diverso nella pipeline (vedi unità altivec del G5) puoi suddividere come ti pare gli stadi di esecuzione, anche rendendo la pipe lunga in stile netburst. Questo ti permette di poter salire di clock facilmente pur aggiungendo unità di esecuzione (tanti transistor in più), tanto le istruzini multimediali soffrono poco di bolle essendo quasi tutte gestite in modo lineare.

Perchè parli al plurale?
Sui generis.
Chissà perchè non sono riusciti ad integrarli nella FP... forse lo skew e le incoerenze erao già abbastanza elevate con le normali unità, figurati aggiungendo altra roba :rolleyes:
In genere la soluzione a questi problemi è isolare l'unità (così si accorciano gli alberi di clock) invece di metterla "in un unico blocco funzionale".
Il perché è semplice e l'abbiamo già detto (questa volta parlo anche degli altri): si risparmiano transistor e si utilizzano meglio le unità di esecuzione.
In realtà in questo thread si stava parlando delle due possibili soluzioni sul merom:
1) che possa integrare una nuova unità multimediale
2) se invece avrà il solito potenziamento delle unità esistenti

Mi pare che oltre al fatto che stai girando la frittata un po' come vuoi tu, non hai affatto discusso su questo, ma come sempre cerchi di divagare nel discorso tirando fuori altri argomenti...
Su questo preferisco parlare quando ci saranno dei dettagli più precisi su Merom.

Per il resto, anche si stava parlando di come sarà Merom, sono stati tirati fuori altri discorsi, sui quali mi sono espresso.
In tanti?
Cos'è una messa ai voti? :asd:
Visto che sei l'unico che continua a sostenere le stesse cose... :rolleyes:
altra volta... (la seconda non te la quoto nemmeno) forse non hai capito che in una unica FP se vuoi impacchettare tutto in un unica unità di esecuzione o aumenti gli stadi oppure la tua CPU avrà evidenti problemi di salita di clock.
Da sempre FPU e codice SIMD presentano numerosi stadi di pipeline rispetto all'unità intera: non è certo questo il problema.
L'unità dedicata ti evita questo problema, perchè aggiungendo un percorso diverso nella pipeline (vedi unità altivec del G5) puoi suddividere come ti pare gli stadi di esecuzione, anche rendendo la pipe lunga in stile netburst. Questo ti permette di poter salire di clock facilmente pur aggiungendo unità di esecuzione (tanti transistor in più), tanto le istruzini multimediali soffrono poco di bolle essendo quasi tutte gestite in modo lineare.
Appunto. Ed è il motivo per cui mettere assieme FPU x87/MMX e SSE ha perfettamente senso, specialmente se consideriamo il miglior uso delle unità di esecuzione che si farà.

Vabeh ci rinuncio, spiegare l'elettronica digitale ad un informatico è una causa persa.

Come volevasi dimostrare: il discorso si è fatto troppo pesante per te. ;)

D'altra parte se te esci fuori con un sillogismo come questo:

"mancanza di unità dedicata SIMD -> prestazioni scarse -> necessità di aumentare clock, cache e bus"

si capisce già qual è la tua competenza in materia.

Perchè parli al plurale?

Perche' anch'io vorrei quella spiegazione visto che sono d'accordo con Cesare :)

Perche' anch'io vorrei quella spiegazione visto che sono d'accordo con Cesare :)
E lo scrivi ora?
Non è che il fatto che sei d'accordo con uno che non conosce nemmeno le problematiche dello skew e della progettazione di una pipeline puo' dar peso alle tue o alle sue argomentazioni in discorsi sull'architettura di una CPU.
Poi cos'è, parla lui per te? Vi linkate le discussioni tramite IM perchè da soli non siete capaci di reggerle e vi serve supporto a vicenda? :D

Sottolineiamo questa cosa: non sapete stare in topic perchè il discorso è un po' oltre le vostre conoscenze: basate solo sulla programmazione e non sulla progettazione. Per rimediare vi tocca andare a salvarvi in corner tirando fuori argomenti non completamente inerenti alla discussione e insistete solo su quelli.

Ti stai arrampicando sugli specchi.
E' inutile continuare a spostare la discussione su altri lidi: ti è stato anche detto che Altivec è stato implementato nei G4 come le SSE sugli x86, per cui c'è una sola unità funzionale che provvede ad eseguire entrambi i tipi di istruzione, e non c'è pipeline che tenga, visto che quella dei G4 è cortissima paragonata a quella del G5.

Inoltre non hai ancora risposto a quella domanda che t'ho fatto, ed è inutile tirare fuori la progettazione della pipeline, perché non c'entra niente (vedi, ancora una volta, differenze fra G4 e G5).

E lo scrivi ora?
Non è che il fatto che sei d'accordo con uno che non conosce nemmeno le problematiche dello skew e della progettazione di una pipeline puo' dar peso alle tue o alle sue argomentazioni in discorsi sull'architettura di una CPU.
Poi cos'è, parla lui per te? Vi linkate le discussioni tramite IM perchè da soli non siete capaci di reggerle e vi serve supporto a vicenda? :D

No, sono semplicemente d'accordo con quello che ha scritto su SSE e AltiVec. E non sono il solo a quanto sembra. Ma se vuoi darmi addosso perche' penso che il tuo punto di vista sia errato fai pure eh...

PS. Il fatto che sono un Ingegnere Informatico significa che ho una preparazione piuttosto estesa anche sull'hardware e sono in grado reggere una discussione, soprattutto al basso livello al quale tu la stai tenendo. Se questo e' la tua linea per dimostrare quello che affermi, buttandola anche sul personale, hai scelto una linea perdente ;)

PS. Il fatto che sono un Ingegnere Informatico significa che ho una preparazione piuttosto estesa anche sull'hardware e sono in grado reggere una discussione, soprattutto al basso livello al quale tu la stai tenendo. Se questo e' la tua linea per dimostrare quello che affermi, buttandola anche sul personale, hai scelto una linea perdente ;)
Non ho buttato la discussione da nessuna parte, vedo solo che non essendo capaci di stare in topic mi viene da pesnare che non conosciate bene l'argomento. Il fatto che cdimauro insiste continuamente su alcuni punti inutili mi pare dimostrazione del fatto.

Vedo che sei un ingegnere... spero tu sia del vecchio ordinamento almeno :asd: sennò non me ne vanterei troppo ;)

A parte che il piano di studi di ing. info V.O. è molto vario (visto che gli ultimi 7 esami sono a completa scelta dello studente e a parte info2 gli esami obbligatori di architettura insegnano poco) quindi la tua preparazione non è affatto detto che sia rivolta all'hardware, comunque non lo escludo.

Rimane il fatto che una persona con conoscenze di progettazione di CPU ritiene la scelta di AMD e intel di eseguire le istruzioni SSE nell'unità FP più un compromesso tra costi e prestazioni invece che una soluzione performante.
E non avrebbe affatto tirato fuori il discorso del set di istruzioni, in quanto è poco inerente.
Chi ritiene questi concetti ininfulenti, dimostra di non conoscere il problema sotto l'aspetto della progettazione, e chi ritiene ininfluente il fatto che le SSE sia o no integrata nella FP? Io no di certo.

Quindi sventolare titoli di studio serve a ben poco, se foste state persone che comprendono bene le problematiche dei CMOS nelle CPU avreste dato una risposta precisa senza girare attorno per N post ai set di istruzioni :)

x cdimauro: certo, nelle cpu la pipeline non conta niente... :rolleyes: si vede bene la capacità di salita di clock del G4 rispetto al G5 *considerando i differenti processi produttivi* (te lo sottolineo altrimenti sei capace di dire "il G5 0.9SOI mentre il G4 a 0.13SOI").

Non ho buttato la discussione da nessuna parte, vedo solo che non essendo capaci di stare in topic mi viene da pesnare che non conosciate bene l'argomento. Il fatto che cdimauro insiste continuamente su alcuni punti inutili mi pare dimostrazione del fatto.

Vedo che sei un ingegnere... spero tu sia del vecchio ordinamento almeno :asd: sennò non me ne vanterei troppo ;)


Si', sono vecchio ordinamento, ma questo che cosa c'entra col discorso del topic? Stando a quanto hai detto sopra, il tuo continuare a spostare la discussione sugl'informatici che non capirebbero l'hardware e sul fatto che io sia vecchio o nuovo argomento dovrebbe farci pensare che non conosci bene l'argomento.

Come ho detto, sono perfettamente in grado di seguire un discorso sull'hardware al basso livello al quale lo stai proponendo, ora possiamo proseguire senza che la butti di nuovo sul personale?

Quindi sventolare titoli di studio serve a ben poco, se foste state persone che comprendono bene le problematiche dei CMOS nelle CPU avreste dato una risposta precisa senza girare attorno per N post ai set di istruzioni :)

Nessuno sta sventolando titoli, ti si sta facendo notare che il tuo "E' inutile spiegare l'hardware ad un informatico che non lo capisce" non e' altro che un poco elegante modo per uscire da una discussione che non riesci a reggere con agl'argomenti.

Piuttosto, Cesare ti ha fatto delle domande precise e anch'io sarei curioso di leggere una tua risposta, piuttosto che vederti disquisire sul mio titolo di studio :)

E perchè dovrei rispondere visto che è poco pertinente? Per continuare a girovagare offtopic? Poi per me è chiara non vedo che cosa ci sia da spiegare, magari se spiegate bene cosa non avete capito...

Di tutto quello che ho scritto poi l'unica cosa a cui hai avuto da dire è sul tuo titolo di studio, argomento che hai tirato fuori tutto tu... mah...

Secondo me siete solo qua a farvi vedere, non ve ne frega niente di discutere.

Vedo che sei un ingegnere... spero tu sia del vecchio ordinamento almeno :asd: sennò non me ne vanterei troppo ;)

Questo mi sembra infantile... credi che la durata del corso di studi sia determinante per la preparazione di un soggetto? E poi mai sentito parlare di gente che senza laurea ha datto una svolta alla vita delle persone?

A parte che il piano di studi di ing. info V.O. è molto vario (visto che gli ultimi 7 esami sono a completa scelta dello studente e a parte info2 gli esami obbligatori di architettura insegnano poco) quindi la tua preparazione non è affatto detto che sia rivolta all'hardware, comunque non lo escludo.

Mai sentito parlare di autonomia degli atenei/politecnici nella scelta e formazione dei corsi di laurea?

Rimane il fatto che una persona con conoscenze di progettazione di CPU ritiene la scelta di AMD e intel di eseguire le istruzioni SSE nell'unità FP più un compromesso tra costi e prestazioni invece che una soluzione performante.
E non avrebbe affatto tirato fuori il discorso del set di istruzioni, in quanto è poco inerente.
Chi ritiene questi concetti ininfulenti, dimostra di non conoscere il problema sotto l'aspetto della progettazione, e chi ritiene ininfluente il fatto che le SSE sia o no integrata nella FP? Io no di certo.

Strano, ma alla Apple la pensano diversamente, sarà che anche quelli saranno ingegneri informatici triennali.

Quindi sventolare titoli di studio serve a ben poco, se foste state persone che comprendono bene le problematiche dei CMOS nelle CPU avreste dato una risposta precisa senza girare attorno per N post ai set di istruzioni :)

x cdimauro: certo, nelle cpu la pipeline non conta niente... :rolleyes: si vede bene la capacità di salita di clock del G4 rispetto al G5 *considerando i differenti processi produttivi* (te lo sottolineo altrimenti sei capace di dire "il G5 0.9SOI mentre il G4 a 0.13SOI").

Ti rendi conto che tutto quello che hai detto finora è stato smentito dalle scelte di Apple che pubblicizza in grande sul proprio sito

4 volte più veloci rispetto al passato.

Vedo che sei un ingegnere... spero tu sia del vecchio ordinamento almeno :asd: sennò non me ne vanterei troppo ;)

:rolleyes:
Grazie! meno male ke ci sei tu a illuminare il mondo!
Ci sono ingegneri del Nuovo Ordinamento che valgono MOLTO piu' di te.
Ma come al solito va di moda generalizzare..............
Ovviamente tu ti sarai laureato in 5 anni esatti esatti e con una votazione di 110 e lode per ritenere TUTTI gli ingegneri del Nuovo Ordinamento indegni del titolo "Ingegnere" da come si evince kiaramente dal tuo post.......:rolleyes:

Rimane il fatto che una persona con conoscenze di progettazione di CPU ritiene la scelta di AMD e intel di eseguire le istruzioni SSE nell'unità FP più un compromesso tra costi e prestazioni invece che una soluzione performante.

E altrettanto ovviamente TU pensi di poter valutare il rapporto costi/benefici meglio di TUTTI gli ingegneri sia di Intel ke di AMD...:rolleyes:
immagino ke saprai bene dall'alto della tua preparazione ke quasi sempre si tende a risparmiare transistor impegnati in operazioni che comportano statisticamente piccoli incrementi prestazionali per impiegarne altri dove servono realmente o meglio dove le migliorie apportate saranno maggiori.

Quindi sventolare titoli di studio serve a ben poco, se foste state persone che comprendono bene le problematiche dei CMOS nelle CPU avreste dato una risposta precisa senza girare attorno per N post ai set di istruzioni :)

appunto....EVITA di considerare con sufficienza una certa categoria di persone, perchè potresti scoprire ke non tutti sono idioti e solo tu sei il privilegiato....:rolleyes:

E perchè dovrei rispondere visto che è poco pertinente? Per continuare a girovagare offtopic? Poi per me è chiara non vedo che cosa ci sia da spiegare, magari se spiegate bene cosa non avete capito...

Registro il fatto che non vuoi o non sai rispondere. Io personalmente ho capito tutto quello che ha scritto Cesare e mi e' chiaro anche il tuo errore.

Di tutto quello che ho scritto poi l'unica cosa a cui hai avuto da dire è sul tuo titolo di studio, argomento che hai tirato fuori tutto tu... mah...

No, hai tirato tu fuori la storia che agli informatici non puoi abbassarti a spiegare l'hardware.

Secondo me siete solo qua a farvi vedere, non ve ne frega niente di discutere.

Secondo me a te non frega nulla di discutere, infatti hai detto proprio ora che non vuoi rispondere alle domande di Cesare. Bella li', a me le tue risposte sarebbero interessate ma vedo che preferisci parlare del mio titolo di studio :)

Il fatto che per eseguire una istruzione SSEx uso moltiplicatori e addizionatori dell'unita FP, posto che siano sufficienti, è un bene. Se non ho istruzioni SIMD da processare (sul G5) (ed anche se ho solo istruzioni SIMD e non FPU classiche), ci sono dei moltiplicatori e addizionatori che stanno a girarsi i pollici, sull'A64 no! Che spreco di transistors e di energia! (P.S.: forse è anche per questo che il G5 consuma di più del G4 ;) )
Vedendolo dal punto di vista del K8, del P4, del PM o del G5 sono d'accordo.

Ma questo discorso cade con il merom, visto che girano voci sulla possibilità nel Merom di poter spegnere ogni unità non utilizzata con un semplice segnale e poi accesa solo quando serve, con una latenza di pochi cicli (meno di 10).
Quindi mentre nel banias, dothan e yonah la cache era accesa o spenta quando occorreva nello merom intel ha fatto un passo avanti.
Ok che la fonte è the inquirer (http://www.theinquirer.net/?article=25619), ma non mi pare assurda la cosa.

Esempio assurdo:
Ammettendo che uno stream H.264 sia elaborato solo da una possibile unità multimediale integrata nel merom tutte le altre unità sarebbero spente, e consumerebbe sicuramente meno che lasciare attiva una intera unità FP per poter eseguirci codice SSE2 dentro ;)

Parentesi sul consumo del G5 e del G4.
Ti rammento che il G5 a 2.5GHz consuma 10W in più del G4 a 1333, (55W contro 45W) non mi pare questo gran consumo in più considerando che il G5 alla frequenza del G4 consumerebbe 29W, e il G5 (di norma funzionante a 1.32V) al voltaggio e alla frequenza del del G4 (1.6V) consumerebbe 43W ;)
http://www.xlr8yourmac.com/G5/xserveG5.html

Se non ci credi ti metto giù i conti:
55W/2500MHz*1333MHz = 29.3W
29.3*(1.6V^2)/(1.32V^2)=29.3*2.56/1.74=43.18

G4 e G5 sono tutti con tech SOI, cambiano processo produttivo (130nm contro 90nm che permettono al G5 di avere voltaggio inferiore) il numero di transistor (molti di più nel G5.) e l'architettura.
Come vedi il G5 consuma meno del G4 se consideriamo tutto quanto ;)

E poi dalla teoria delle code, due "serventi" con coda unica sono più efficienti di due "serventi" con coda separata...
No dai, non riassumermi il Lazowska con queste frasi fatte :asd:
Non hai nemmeno specificato se i serventi sono in parallelo o serie (spero tu intenda in parallelo).
Pero' un dual core (2 serventi in coda unica) è più o meno efficente di un dual processor (2 serventi con 2 code)? La risposta non è certo una, dipende da che applicazioni ci girano sopra.

Cque: dopo queste inesattezze non mi sorprende che cesare abbia detto che è perfettamente d'accordo :), e immagino che Fek comprenda cosa intendo con la frase "è inutile spiegare l'hw a un informatico che non lo capisce".

Cque: dopo queste inesattezze non mi sorprende che cesare abbia detto che è perfettamente d'accordo :), e immagino che Fek comprenda cosa intendo con la frase "è inutile spiegare l'hw a un informatico che non lo capisce".

Si', comprendo che e' un modo poco elegante e poco educato di svignarsela ;)

Fortuna che poi ero io che rendevo i topic illegibili :rolleyes:

Bah... fate un po' quel cavolo che vi pare...

Sul discorso del G4 e del G5:

Beh, come l'hai messa tu, hai ragione... Non è che mi ero documentato più di tanto... :D Mi ero solo basato sul fatto che portatili con il G5 non erano usciti... (o si???)

Sul discorso della teoria delle code... Ovviamente in parallelo... ;)

Per il dual core/dual processor... Oddio... Sia con architettua UMA che NUMA nel dual processor comunque si può assumere coda unica, perchè comunque i due processori possono accedere alla RAM nativamente (anche se con latenze diverse nel NUMA... Per chi legge: UMA -> Xeon, NUMA -> Opteron)... Forse volevi dire sistemi separati, ma in rete, in cui il passaggio dei dati avviene con scambio di messaggi e quindi si può presumere che ogni sistema si esegua i suoi processi per fatti suoi...

io spero che mettano qualche bestia nel powermac :stordita:

Per il dual core/dual processor... Oddio... Sia con architettua UMA che NUMA nel dual processor comunque si può assumere coda unica, perchè comunque i due processori possono accedere alla RAM nativamente (anche se con latenze diverse nel NUMA... Per chi legge: UMA -> Xeon, NUMA -> Opteron)... Forse volevi dire sistemi separati, ma in rete, in cui il passaggio dei dati avviene con scambio di messaggi e quindi si può presumere che ogni sistema si esegua i suoi processi per fatti suoi...
No, niente di così complicato, non è sbagliato quello che hai detto, ma intendevo dire che il discorso non è semplice, e non puo' essere ridotto ad una sola frasetta, quando le due code non sono uguali, e i due serventi non processano alla stessa velocità o soprattutto non processano la medesima quantità di dati.

Poi sinceramente la teoria delle code è meglio applicata ad un sistema intero, dove ci sono code che hanno molte variazioni nel tempo, non in una pipeline dove le code hanno varianza minima o sono completamente nulle, perchè avresti risultati banali.

In generale un dual core è sempre più efficente e prestante di un dual processor, difficile trovare un bench che indichi il contrario (http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=4) (e ne ho discusso con overclock79 sul forum di processori per un bel pezzo, ma non snoo riuscito a convincerlo :asd: )
Pero' secondo me l'esempio non calza con il discorso dell'architettura interna, proprio perchè due core sono uguali, due unità di esecuzione non è detto.

Vedendolo dal punto di vista del K8, del P4, del PM o del G5 sono d'accordo.
Ma questo discorso cade con il merom, visto che girano voci sulla possibilità nel Merom di poter spegnere ogni unità non utilizzata con un semplice segnale e poi accesa solo quando serve, con una latenza di pochi cicli (meno di 10).
Quindi mentre nel banias, dothan e yonah la cache era accesa o spenta quando occorreva nello merom intel ha fatto un passo avanti.
Ok che la fonte è the inquirer (http://www.theinquirer.net/?article=25619), ma non mi pare assurda la cosa.

Esempio assurdo:
Ammettendo che uno stream H.264 sia elaborato solo da una possibile unità multimediale integrata nel merom tutte le altre unità sarebbero spente, e consumerebbe sicuramente meno che lasciare attiva una intera unità FP per poter eseguirci codice SSE2 dentro ;)


Sarebbe molto interessante, anche se poi ci sarebbero dei quesiti non proprio banali a cui rispondere (ma per far funzionare questa unità multimediale, se serve comunque tenere attiva la pipeline per la decodifica delle istruzioni, quanto risparmio energetico ho in realtà? Oppure le sitruzioni vengono dirottate su un vero e proprio coprocessore a parte? E questo, cosa comporterebeb a livello di compatibilità di applicazioni? Ecc.)



Parentesi sul consumo del G5 e del G4.
Ti rammento che il G5 a 2.5GHz consuma 10W in più del G4 a 1333, (55W contro 45W) non mi pare questo gran consumo in più considerando che il G5 alla frequenza del G4 consumerebbe 29W, e il G5 (di norma funzionante a 1.32V) al voltaggio e alla frequenza del del G4 (1.6V) consumerebbe 43W ;)
http://www.xlr8yourmac.com/G5/xserveG5.html

Se non ci credi ti metto giù i conti:
55W/2500MHz*1333MHz = 29.3W
29.3*(1.6V^2)/(1.32V^2)=29.3*2.56/1.74=43.18

G4 e G5 sono tutti con tech SOI, cambiano processo produttivo (130nm contro 90nm che permettono al G5 di avere voltaggio inferiore) il numero di transistor (molti di più nel G5.) e l'architettura.
Come vedi il G5 consuma meno del G4 se consideriamo tutto quanto ;)


Magari, quelle specifiche sono state disattese. Diciamo che il G5 consuma di più (IBM dichiara 48W in burn a 1.25V per la versione da 2 GHz, che salgono a 68 per la versione a 2,2 GHz e a 2,5 Ghz il consumo è salito esponenzialmente, tanto da costringere Apple a presentare le sue macchine con raffreddamento ad acqua. Sto parlando delle parti standard, ci sono anche quelle low voltage per cui il discorso migliora, ma non di molto), e la piccola superficie del die (66mm^2) non aiuta (le temperature sono alte e c'è bisogno di sistemi di raffreddamento apparentemente sovradimensionati a causa della densità di potenza termica dissipata).
Questo è il motivo per il quale non si sono visti notebook con G5.

Beh nel dothan la cache si spegne a blocchi, ma non penso che si spenga tutta la circuiteria di addressing della cache stessa, altrimenti (la butto lì) come farebbe a capire quando riaccendersi velocemente senza dover mantenere centralizzato il controllo? (che richiederebbe sicuramente alcune riprogettazioni)

Idem si potrebbe pensare nel merom. Certo i transistor che governano la pipeline non sono pochi, se consideri poi che i registri sono spesso inclusi.
Pero' spegnere le unità inutilizzate ha sempre il suo perchè, nelle unità, come i divisori e i moltiplicatori, sono concentrati il maggiro numero di transistor. Se li spegni risparmi molto in potenza statica dissipata più che altro, e a 0.65 non sarà pochissima visti i dati del presler.

Sui consumi devo dire che ho trovato ora, delle specifiche diverse:
Il die è 121mm^2 nel G5 a 130nmSOI e 66mm^2 nel G5 a 90nmSOI.
http://www-128.ibm.com/developerworks/library/pa-powerenv/
Parla di consumi del G5 a 90nm tra 80W e 60W (anche se buona parte sono di leakage), se è così allora è un discorso diverso, il G5 a 90nm effettivamente ha ragione bjt2: consuma un botto più del G4, almeno la versione 970Fx, sarà per il die shrink ma consuma e i 66mm^2 non lo fanno stare basso di temperature.

Pero' quello a 130nm (970 liscio) è bassino, si parla di 42W a 1.8Ghz, e 1.3V, non tantissimo, certo non è poco, siamo ai livelli di un Thoroughbred.
http://arstechnica.com/articles/paedia/cpu/ppc970.ars/1

Edit: avevo invertito i die size

Non ho buttato la discussione da nessuna parte, vedo solo che non essendo capaci di stare in topic mi viene da pesnare che non conosciate bene l'argomento. Il fatto che cdimauro insiste continuamente su alcuni punti inutili mi pare dimostrazione del fatto.
Sei stato anche tu a fare delle affermazioni off-topic, o sbaglio? Io ti ho chiesto delle giustificazioni a delle tue affermazioni (OT: non stavi mica parlando di Merom), che non sono ancora arrivate.
Rimane il fatto che una persona con conoscenze di progettazione di CPU ritiene la scelta di AMD e intel di eseguire le istruzioni SSE nell'unità FP più un compromesso tra costi e prestazioni invece che una soluzione performante.
Una persona che ha conoscenza di progettazione di CPU non fa affermazioni come queste:
Quindi affermare che le istruzioni Altivec sono alla stregua delle SIMD negli x86 è un po' un azzardo . Infatti il divario prestazionale (image editing, editing video...) tra le due architetture è evidente, ancor di più se si considera la mediocrità prestazionale del resto delle unità logiche di un G5.

La semantica non cambia l'architettura di una CPU, le SSE sono processate dall'unità FP, diversamente da come accade nel G5.
Onde per cui ->
- x86 non ha unità dedicata per le SSE, chiamalo come ti pare, fatto sta che per avere prestazioni del G5 in questo campo devi alzare il clock e pompare cache e BUS.
- G5 ha unità dedicata alle istruzioni altivec, onde per cui ha prestazioni superiori, nonostante il resto di un sistema G5 sia mediocre
Senza alcuna giustificazione tecnica.
E non avrebbe affatto tirato fuori il discorso del set di istruzioni, in quanto è poco inerente.
Non sono stato io ad aprire il discorso su unità vettoriali e istruzioni (vatti a rivedere l'inizio della discussione).

Inoltre anche tu ne parli, o sbaglio? Vedi quote.
Chi ritiene questi concetti ininfulenti, dimostra di non conoscere il problema sotto l'aspetto della progettazione, e chi ritiene ininfluente il fatto che le SSE sia o no integrata nella FP? Io no di certo.
Infatti è influente, come ti è stato ripetuto più volte.
Quindi sventolare titoli di studio serve a ben poco,
L'hai fatto anche tu in passato, nelle discussioni che abbiamo avuto. Solo che alle mie precise domande su materie che dicevi di aver studiato, non hai mai fornito risposta (esempio: sui moltiplicatori).
se foste state persone che comprendono bene le problematiche dei CMOS nelle CPU avreste dato una risposta precisa senza girare attorno per N post ai set di istruzioni :)
Infatti le problematiche dei CMOS con i discorsi che sono stati fatti (set di istruzioni, unità dedicate/funzionali) non c'entrano niente.
x cdimauro: certo, nelle cpu la pipeline non conta niente... :rolleyes: si vede bene la capacità di salita di clock del G4 rispetto al G5 *considerando i differenti processi produttivi* (te lo sottolineo altrimenti sei capace di dire "il G5 0.9SOI mentre il G4 a 0.13SOI").
Ho detto chiaramente che la pipeline non c'entra niente coi discorsi che sono stati fatti.

Quello che riporti è UN ALTRO DISCORSO.

E perchè dovrei rispondere visto che è poco pertinente?
Perché sono affermazioni piuttosto "leggere" che hai detto tu e non hai assolutamente giustificato (e vorrei ben vedere come potresti farlo).
Per continuare a girovagare offtopic?
Lo stiamo facendo da un pezzo, e tu hai dato un notevole contributo. Strano che ti lamenti di questo proprio ora, e per di più quando continui a parlare di altre cose OT: vedi consumo dei G4 e G5: non sono anche questi OT?
Poi per me è chiara non vedo che cosa ci sia da spiegare, magari se spiegate bene cosa non avete capito...
Te l'ho già chiesto più volte, ma continui a lasciar cadere l'argomento. E' chiaro, almeno questo, che non sei in grado di argomentare le tue affermazioni.
Secondo me siete solo qua a farvi vedere, non ve ne frega niente di discutere.
No, siamo qui a discutere di cose tecniche, non di affermazioni campate in aria e lasciate svolazzare senza alcuna giustificazione, come hai fatto finora tu.

Vedendolo dal punto di vista del K8, del P4, del PM o del G5 sono d'accordo.
Ottimo. Quindi smentisci quello che hai affermato prima.
Ma questo discorso cade con il merom, visto che girano voci sulla possibilità nel Merom di poter spegnere ogni unità non utilizzata con un semplice segnale e poi accesa solo quando serve, con una latenza di pochi cicli (meno di 10).
Quindi mentre nel banias, dothan e yonah la cache era accesa o spenta quando occorreva nello merom intel ha fatto un passo avanti.
Ok che la fonte è the inquirer (http://www.theinquirer.net/?article=25619), ma non mi pare assurda la cosa.

Esempio assurdo:
Ammettendo che uno stream H.264 sia elaborato solo da una possibile unità multimediale integrata nel merom tutte le altre unità sarebbero spente, e consumerebbe sicuramente meno che lasciare attiva una intera unità FP per poter eseguirci codice SSE2 dentro ;)
Non si sa ancora di preciso di quali unità si parla: unità di esecuzione o unità funzionali. E' presto per parlarne, e per di più citando The Inquirer.
No dai, non riassumermi il Lazowska con queste frasi fatte :asd:
Non hai nemmeno specificato se i serventi sono in parallelo o serie (spero tu intenda in parallelo).
Pero' un dual core (2 serventi in coda unica) è più o meno efficente di un dual processor (2 serventi con 2 code)? La risposta non è certo una, dipende da che applicazioni ci girano sopra.
E' un esempio che non calza: i due serventi non sono esattamente gli stessi in questo caso.
Cque: dopo queste inesattezze non mi sorprende che cesare abbia detto che è perfettamente d'accordo :),
Infatti si parlava chiaramente delle differenze fra l'approccio con un'unità funzionale che ingloba tutto e quello con due unità funzionali diverse. Le operazioni da fare sono le stesse.

Ti è stato spiegato che è più conveniente il primo approccio (nelle stesse condizioni, ovviamente. Non si sa mai: è meglio specificarlo), e io sono perfettamente d'accordo con ciò.
e immagino che Fek comprenda cosa intendo con la frase "è inutile spiegare l'hw a un informatico che non lo capisce".
Io direi che è inutile spiegare come funzionano le architetture degli elaboratori a un ingegnere elettronico che si ostina a vedere soltanto transistor e tecnologia CMOS.

In generale un dual core è sempre più efficente e prestante di un dual processor, difficile trovare un bench che indichi il contrario (http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=4) (e ne ho discusso con overclock79 sul forum di processori per un bel pezzo, ma non snoo riuscito a convincerlo :asd: )
Io voglio vedere i test fra un singolo Opteron dual core e due Opteron single core, prima di fare certe affermazioni.

Allora...

x Dreadnought:

Io non scenderei al livello di pipeline, ma al livello di processi.

Mi spiego:

Se hai un multi processor (sia esso multicore o "multichip"), dal punto di vista del SO essi sono equivalenti, tanto è vero che ameno che non imposti l'affinità, un task viene sballottolato tra un processore e l'altro, per non caricarne uno solo. Questo è evidente se lanci un solo processo e guardi il task manager dicendo di dare il carico separato per le CPU (per un esempio, guarda qualunque test di HWupgrade sul multicore: in alcuni test vedrai un riquadro con una parte dello screenshot del task manager. Per processi single thread, vedrai che il carico si ripartisce più o meno al 50% per core) ma succede anche per più processi contemporaneamente: non è garantito che usino lo stesso core. L'assunzione di core identici è vera con gli INTEL, perchè hanno una architettura UMA: ogni locazione di memoria ha la stessa latenza. Quindi qui possiamo assumere il modello di coda unica e due serventi. PEr gli Opteron, che sono NUMA, la latenza dipende da dove sta la RAM, ma per i sistemi non NUMA aware, i processi sono trattati come prima (quindi coda unica), per i sistemi NUMA aware (mi pare che win server 2003 lo sia), è data preferenza al processore che è connessa alla ram usata (e tutti i dati sono messi vicino), ma comunque non è escluso l'uso dell'altro processore, nel caso... Quindi ancora coda unica...

xCDmauro:

mi pare che ci fosse qualche bench... Le differenze sono minime e dipende dall'applicazione: applicazioni multithreaded che si scambiano molti dati beneficiano del collegamento diretto delle due CPU (nel multicore), che può bilanciare la banda dimezzata della RAM, applicazioni indipendenti beneficiano della maggiore banda di RAM del dual processor e vanno meglio...

Il link che ho postato mostra molti bench con un opteron 175 e un sistema dual opteron 248.
Non ho trovato un equivalente intel con uno xeon DP e un dual xeon pari frequenza e pari cache, sempre che possano esistere, se ne avete uno sarebbe interessante vedere una architettura differente come si comporta.

Quindi qui possiamo assumere il modello di coda unica e due serventi. PEr gli Opteron, che sono NUMA, la latenza dipende da dove sta la RAM, ma per i sistemi non NUMA aware, i processi sono trattati come prima (quindi coda unica), per i sistemi NUMA aware (mi pare che win server 2003 lo sia), è data preferenza al processore che è connessa alla ram usata (e tutti i dati sono messi vicino), ma comunque non è escluso l'uso dell'altro processore, nel caso... Quindi ancora coda unica...

Il ragionamento è interessante, soprattutto perchè quando ho fatto l'esame di impianti sulla teoria delle code i dual core non sapevo nemmeno cos'erano :asd:
Pero' se non ho capito male questo discorso era partito dal fatto che i due serventi erano una unità vettoriale e la FP a parte, o mi sbaglio? (se mi sbaglio non leggere nemmeno sotto :p )

Quindi come modellizzeresti ad esempio la pipe del G5? Anche semplificando e considerando solo VPU e FPU.
http://arstechnica.com/cpu/02q2/ppc970/images/ppc-970-large-diagram.png

Pensa a quanti fattori devi tenere in conto:
- bit di ampiezza dei bus dati
- tempi di attesa per l'esecuzione delle varie istruzioni
- cache miss e hit
Non sono un po' troppi?

Io voglio vedere i test fra un singolo Opteron dual core e due Opteron single core, prima di fare certe affermazioni.
Ma ci sei o ci fai, quoti un link e nemmeno lo clicchi? :doh:
Non ho parole...

Allora. La questione coda unica / separata nel G5 e nell'A64 è giusta guardando dal punto di vista dei moltiplicatori/addizionatori...

Mi spiego:

Nell'A64 le istruzioni SSEx competono con le istruzioni FPU per i moltiplicatori o gli addizionatori. Coda unica in cui ci sono istruzioni x87 e SSEx, tutte eseguite dagli stessi moltiplicatori o addizionatori fisici. CIoè, se ho in coda una mul, di qualunque tipo (x87, 3dNOW o SSEx) e una add di qualunque tipo (idem), le posso iniziare assieme, senza vincoli.

Nel G5 ho 2 code separate per le istruzioni vettoriali e le classiche scalari. Ho 2 moltiplicatori (uno scalare e uno vettoriale) e due addizionatori (idem). Il doppio delle risorse, ma se uso solo fpu o solo altivec, il 50% è sprecato!

Poi l'A64 ha un moltiplicatore a 64 bit che si splitta in 2 a 32 bit (per fare in 2 passate una ssex 2x64 o 4x32 bit o in una passata una 3dnow 2x32 bit), che è brevettato.

Nell'A64 le istruzioni SSEx competono con le istruzioni FPU per i moltiplicatori o gli addizionatori. Coda unica in cui ci sono istruzioni x87 e SSEx, tutte eseguite dagli stessi moltiplicatori o addizionatori fisici. CIoè, se ho in coda una mul, di qualunque tipo (x87, 3dNOW o SSEx) e una add di qualunque tipo (idem), le posso iniziare assieme, senza vincoli.

Nel G5 ho 2 code separate per le istruzioni vettoriali e le classiche scalari. Ho 2 moltiplicatori (uno scalare e uno vettoriale) e due addizionatori (idem). Il doppio delle risorse, ma se uso solo fpu o solo altivec, il 50% è sprecato!

Ok, ma implica che la soluzione sia meno performante. Non è che il 50% è sprecato, è inutilizzato, male che vada ti consuma come leakage.


Poi scusa se ci sono 4 istruzioni in coda:

1 FADD FP
1 FDIV FP
1 ADD Vett
1 MUL Vett

Sono sfruttate tutte e 4 le unità.

E il pipelining ti permette un trhoughput per ognuna di queste in 1/2 ciclo di clock.
EDIT: corretto da 1 a mezzo.

Il link che ho postato mostra molti bench con un opteron 175 e un sistema dual opteron 248.
Non ho trovato un equivalente intel con uno xeon DP e un dual xeon pari frequenza e pari cache, sempre che possano esistere, se ne avete uno sarebbe interessante vedere una architettura differente come si comporta.

Ma ci sei o ci fai, quoti un link e nemmeno lo clicchi? :doh:
Non ho parole...
Ho semplicemente quotato tutto: era così difficile arrivarci? :rolleyes:

Comunque ho letto la recensione. Molto interessante. A naso direi che la soluzione dual opteron non solo non faccia adeguato uso dell'architettura NUMA, ma che addirittura ne risulti penalizzata (uno dei due processori accederà tramite link HT alla memoria dell'altro).

mi pare che ci fosse qualche bench... Le differenze sono minime e dipende dall'applicazione: applicazioni multithreaded che si scambiano molti dati beneficiano del collegamento diretto delle due CPU (nel multicore), che può bilanciare la banda dimezzata della RAM, applicazioni indipendenti beneficiano della maggiore banda di RAM del dual processor e vanno meglio...
Come dicevo prima, l'impressione che ho avuto guardando i test, è che l'architettura NUMA penalizzi la soluzione dual opteron.

Ok, ma implica che la soluzione sia meno performante. Non è che il 50% è sprecato, è inutilizzato, male che vada ti consuma come leakage.
Hai detto niente. Tant'è che i G5 dai 2,5Ghz in poi fanno uso di un raffreddamento a liquido.
Poi scusa se ci sono 4 istruzioni in coda:

1 FADD FP
1 FDIV FP
1 ADD Vett
1 MUL Vett

Sono sfruttate tutte e 4 le unità.

E il pipelining ti permette un trhoughput per ognuna di queste in 1/2 ciclo di clock.
EDIT: corretto da 1 a mezzo.
Non c'è che dire: un tipo di codice MOLTO diffuso, vero? ;)

Allora...

Male che vada si consuma solo il leakage... Non è proprio così... BENE CHE VADA, si consuma solo il leakage, ma è così solo se si usa il clock gating, e mi pare che solo il Merom lo userà (ergo il G5 non ce l'ha), quindi si consuma energia nei gate che ricevono il clock e per portare il clock fino a quelle unità in più. Poi c'è il discorso dei transistors in più: maggior costo, minor resa, maggiore probabilità di guasto, minore salita in frequenza data anche dal maggior consumo e dalla maggiore densità di potenza...

Tutto questo per avere il doppio del throughput nel raro caso in cui si mixino altivec e FP e comunque nell'ipotesi che il bus ce la faccia a fornire i dati o che siano già in cache: per sostenere 4 istruzioni per ciclo di clock si richiedono 128+128+32+32 (sono buono, ti concedo che siano istruzioni FP a 32 bit... :D ) bit per ciclo di clock a 2,5 GHz... Neanche le memorie della GTX512 arrivano a tanto...

[1]Come dicevo prima, l'impressione che ho avuto guardando i test, è che l'architettura NUMA penalizzi la soluzione dual opteron.

[2]Non c'è che dire: un tipo di codice MOLTO diffuso, vero?
[1]Quello che ho pensato quando discutevamo su dual core e dual processor: il K8 ha lo svantaggio che ogni processore nel dual core ha banda dedicata verso la ram, pero' questo è un vantaggio solo con 2 thread indipendenti e con un sistema operativo NUMA aware (bjt ha detto che XP non è numa aware era il pezzo del puzzle che mi mancava). Con XP è una penalità, perchè se cpu0 ha bisogno di un dato che sta nella ram di cpu1 deve pagare la latenza di SRQ+Crossbar+linkHTT per avere il dato, invece che solo la latenza del suo MCH.
Dall'altra parte il dual core ha il vantaggio che i core comunicano con le cache opposte con latenze più basse di un cache miss.

[2]Sicuramente no, pero' considera che questo lo puo' fare un G5, non un P4 che ha una FSTORE SIMD e una FP.
Nel G5 con l'issue queue hai la possibilità per ogni istruzione di avere cpi di almeno 2, proprio perchè anche le 2 load/store da 64bit unit sono unità indipendenti e a parte. Nel P4 e anche il K8 la Fstore è una e ha una granularità di 64bit, che riduce il throughput di una SSE2 a 128bit a 1/2 per ciclo di clock.

Quindi mentre il G5 paga sulle istruzioni generiche con un throughput di 2 e il P4 e il K8 hanno throughput penalizzanti sulle SSE rispetto alle altivec.
Elencando i CPI:
P4: CPI-I 3, CPI-FP 1, CPI-SSE2_Double[128b] 1/2.
K8: CPI-I 3, CPI-FP 3, CPI-SSE2_Double[128b] 1/2.
G5: CPI 2 su tutte, CPI-Altivec-"Double" 1.
Il [Double] che ho messo sta per il datapath allineato a 64bit usato per le SSE2 con 4 operazioni a 32bit, che se non mi sto sbagliando è il più usato nell'encoding e nel decoding.

Da qui il fatto che all'uscita dei primi G5 2GHz in encoding video davano la paga agli xeon 3Ghz e stavano dietro agli opteron 2.4Ghz, ma come server i G5 sono sempre stati rottami.

Male che vada si consuma solo il leakage... Non è proprio così... BENE CHE VADA, si consuma solo il leakage, ma è così solo se si usa il clock gating, e mi pare che solo il Merom lo userà (ergo il G5 non ce l'ha), quindi si consuma energia nei gate che ricevono il clock e per portare il clock fino a quelle unità in più. Poi c'è il discorso dei transistors in più: maggior costo, minor resa, maggiore probabilità di guasto, minore salita in frequenza data anche dal maggior consumo e dalla maggiore densità di potenza...
Beh scusa, se una unità è [enabled] ma non in [execute] il suo consumo sarà solo il leakage.
Quando mandi in esecuzione una istruzione allora consumi anche lo switching power: infatti il G5 a 130nm consuma come un G4 nonostante 600Mhz in piu, proprio perchè a 130nm lo strato SOI ti basta per ridurre tutti i leaking pesantemente, a 90nm non basta, ci vuole la DSL dei core dal venice in avanti.

Poi rispetto al K8/P4 il G5 solo con la VPU dedicata risparmia in transistor:
- register renaming
- stack renaming
- molti datapath che nel P4 e nel K8 sono doppi per garantire il perfetto funzionamento dei 2-3 path che possono coinvolgere una istruzione FP

Quindi non è così grigia la situazione.
Ogni soluzione ha il suo perchè e i suoi compromessi, dipende che strada vuoi prendere.

Tutto questo per avere il doppio del throughput nel raro caso in cui si mixino altivec e FP e comunque nell'ipotesi che il bus ce la faccia a fornire i dati o che siano già in cache: per sostenere 4 istruzioni per ciclo di clock si richiedono 128+128+32+32 (sono buono, ti concedo che siano istruzioni FP a 32 bit... :D ) bit per ciclo di clock a 2,5 GHz... Neanche le memorie della GTX512 arrivano a tanto...
Scusa non mi ero accorto di questo.

Considera che di istruzioni a 128bit il G5 ne esegue una alla volta (ogni LSU dovrebbe avere 64bit di ampiezza).
E che i 128bit di dati provenienti ad esempio da uno streaming mpeg-2/divx non vengono sottoposti ad una operazione, ma a molte, quindi il dato ritorna in cahce, passa tra i registri prima di tornare a destinazione. 6.4GB di banda dalla RAM non sono certo tanti, ma nemmeno limitanti, il FSB del G5 è sovradimensionato rispetto alla ram quindi non fa collo di bottiglia.

Per quanto riguarda il consumo in più: oltre al leakage, ci deve arrivare l'alimentazione ed almeno una linea di clock, con le sue correnti parassite, che sono anche solo nelle porte che abilitano o meno il circuito. Poi, se l'unità è distante ci vorranno dei ripetitori per tutti i segnali, ecc...

Per il register renaming ecc... Nel G5 sono duplicate! Un set di registri ed una unità di register renaming per la parte intera+FPU ed una SEPARATA per altivec... Non è che manca!!! Duplicare quando si può condividere non è mai conveniente! Anche i datapath... Sono doppi anche nel G5 (anzi ammaggior ragione nel G5), ma in questo ci sono anche il doppio dei registri per il renaming, invece, almeno nell'A64, i registri per il renaming sono condivisi: a 90 bit (non so perchè non 80) e quelli SSEx ne occupano 2... Invece nel G5 un set per gli interi + FPU (a 64 bit perchè il G5 non ha i long double) + un set SEPARATO per le Altivec. E questo vale per tutto: datapath ecc...

Per quanto riguarda il throughput... 6,4GB/s vuol dire 400 milioni di word a 128 bit... Quindi il rateo massimo sostenuto di operazioni sostenibili (ricordo che questi set multimediali sono appunto per dati in streaming...) sono 400 milioni al secondo. Quindi un ipotetico G5 a 1,6GHz, che fa due mezze operazioni altivec per ciclo, avrà delle unità che si girano i pollici se il calcolo da fare richiede meno di 4 operazioni, se non ci sono operazioni FPU o intere da fare in contemporanea... La situazione peggiora se ci aggiungi la banda per le istruzioni, per altre istruzioni FP (ricordiamo che tu hai detto che il vantaggio è di poter fare contemporaneamente anche istruzioni fp), la banda che non è 6,4GB/s... In pratica conti che richiedono più di 5-6 operazioni per ogni dato sono vantaggiosi... Altrimenti si è bandwidth limited...

Peggio ancora per un G5 a 2,5Ghz... Almeno 8-10 operazioni per dato, altrimenti delle unità si gireranno i pollici...

Per quanto riguarda il consumo in più: oltre al leakage, ci deve arrivare l'alimentazione ed almeno una linea di clock, con le sue correnti parassite, che sono anche solo nelle porte che abilitano o meno il circuito. Poi, se l'unità è distante ci vorranno dei ripetitori per tutti i segnali, ecc...
...se consumassero così tanto una cpu che di leakage ha poco -un venice 3000+ ad esempio- non avrebbe differenza di consumo così marcata da 35W a 11W tra full e idle.
Considerando che parte di questi consumi sono fissi e sono della cache.
Vuol dire che tutti gli alberi di clock e le unità inattive non consumano più di 4-5W.
Figurati cosa puo' consumare solo una parte di questi.

Per il register renaming ecc... Nel G5 sono duplicate! Un set di registri ed una unità di register renaming per la parte intera+FPU ed una SEPARATA per altivec... Non è che manca!!! Duplicare quando si può condividere non è mai conveniente! Anche i datapath... Sono doppi anche nel G5 (anzi ammaggior ragione nel G5), ma in questo ci sono anche il doppio dei registri per il renaming, invece, almeno nell'A64, i registri per il renaming sono condivisi: a 90 bit (non so perchè non 80) e quelli SSEx ne occupano 2... Invece nel G5 un set per gli interi + FPU (a 64 bit perchè il G5 non ha i long double) + un set SEPARATO per le Altivec. E questo vale per tutto: datapath ecc...
...va che è tutto il contrario, la complessità dei datapath aumenta con l'aumentare delle unità funzionali che devi gestire contemporaneamente.

...sul register ranaming mi sa che non hai capito cosa intendo, in quanto capisci bene che se devo interscambiare il contenuto dei registri per una unità sola (8, 16 registri totali?) il discorso relativamente semplice, se lo devo fare per 3 unità diverse (32? 40 registri totali?) con altrettanti registri differenti diventa un gran casino e la complessità sale più in fretta.

Nel G5 c'è una issue queue comune a tutte le unità posta nel centro di esse, il risparmio in transistor è evidente anche solo guardando il die del G5, per di più hanno risparmiato di dover fare uno scheduler per ogni unità, creando la issue queue per tutti che si pensa da sola a gestire le istruzioni e ad ordinarle come più si hanno vantaggi.

Die del G5:
http://images.anandtech.com/reviews/cpu/mac_compared/IBM_powerpc970fx_die.jpg

Per quanto riguarda il throughput... 6,4GB/s vuol dire 400 milioni di word a 128 bit... Quindi il rateo massimo sostenuto di operazioni sostenibili (ricordo che questi set multimediali sono appunto per dati in streaming...) sono 400 milioni al secondo. Quindi un ipotetico G5 a 1,6GHz, che fa due mezze operazioni altivec per ciclo, avrà delle unità che si girano i pollici se il calcolo da fare richiede meno di 4 operazioni, se non ci sono operazioni FPU o intere da fare in contemporanea... La situazione peggiora se ci aggiungi la banda per le istruzioni, per altre istruzioni FP (ricordiamo che tu hai detto che il vantaggio è di poter fare contemporaneamente anche istruzioni fp), la banda che non è 6,4GB/s... In pratica conti che richiedono più di 5-6 operazioni per ogni dato sono vantaggiosi... Altrimenti si è bandwidth limited...

In realtà sarà un po' difficile processare 400milioni di word a 128bit in un secondo, visto che un filmato o qualsiasi blocco dati di quelle dimensioni arriva da:
- HD (che se fa 60-70MB/s son tanti)
- Firewire (30-40 o 70-80MB/s)
- Rete (max 80-90MB/s con una Gigabit ethernet)
- USB2 (30-40MB/s)
Ci sono tante operazioni da fare in uno streaming dove entrano in gioco istruzioni multimediali e poi la cache mica è sempre piena, anzi...

Per quuanto riguarda l'albero di clock: avevo affermato che consumava di più... ma non ho specificato quanto :D Penso che siano al max 0,5 - 1 W sprecati...

Per la complessità dei datapath, hai ragione se sono crossbar switch, ma mi pare che siano dei bus e quindi la complessità sia lineare, solo che nel G5 i bus sono più corti (meno unità collegate) e di più (perchè altivec ed fpu hanno unità e registri separati)...

Per i registri: nell'A64 hai un banco di n registri a 90 bit (sorry, non ricordo quanti) con 9 porte e quindi 9 bus, perchè hai 3 ALU + 3 AGU + 3 FPU... Sul G5 hai due banchi di n e m registri (sorry... non conosco n ed m), ognuno con più porte, una per ogni unità (quello dell'altivec sarà monoporta???). Il numero di porte superiore implica solo un numero maggiore di bus e decoder (tra l'altro di pochi bit) e dei transistors dei registri più "robusti"... Però potresti aver ragione sulla maggiore dimensione occupata sul die (ma non della complessità)...

Per il discorso banda... Mica ci sono solo i filmati... ;) Proprio ora sto testando un algoritmo di riduzione rumore su files audio (di mia invenzione)... La richiesta di banda è mostruosa!

[2]Sicuramente no, pero' considera che questo lo puo' fare un G5, non un P4 che ha una FSTORE SIMD e una FP.
Nessuno nega che il G5 lo possa fare, ma ripeto: MOLTO difficilmente troverai degli algoritmi in grado di sfruttare FPU e Altivec allo stesso tempo (fermo restando che queste unità di calcolo vanno comunque "sfamate", com'è stato poi detto).
Il [Double] che ho messo sta per il datapath allineato a 64bit usato per le SSE2 con 4 operazioni a 32bit, che se non mi sto sbagliando è il più usato nell'encoding e nel decoding.
Le SSE richiedono dati allineati a 128 bit (le SSE3 hanno però introdotto delle apposite istruzioni di caricamento di dati disallineati), se era a questo che ti riferivi.

... Scusate ... :D Mi sono accorto di avere scritto una caxxata al messaggio 121... :D Ho scritto che i registri a 90 bit sono acceduti dalle 3 ALU + 3 AGU + 3 FPU... Ho sbagliato! I registri interi ed FPU/SSEx sono separati... A quei registri ci accede solo la FPU... Quindi solo 3 unità... Nessun aumento di complessità... Anzi, sul G5 ci sono doppi data path, doppi banchi registri, doppi riordinatori, doppi schedulatori (anche se quelli dell'altivec avranno una sola porta...)

Ragazzi ma il chipset che gestirà merom è questo che c'è ora per yonah o cisarà uno nuovo ?

... Scusate ... :D Mi sono accorto di avere scritto una caxxata al messaggio 121... :D Ho scritto che i registri a 90 bit sono acceduti dalle 3 ALU + 3 AGU + 3 FPU... Ho sbagliato! I registri interi ed FPU/SSEx sono separati... A quei registri ci accede solo la FPU... Quindi solo 3 unità... Nessun aumento di complessità... Anzi, sul G5 ci sono doppi data path, doppi banchi registri, doppi riordinatori, doppi schedulatori (anche se quelli dell'altivec avranno una sola porta...)
Però dentro la FPU i registri x87/MMX e quelli della SSE sono completamente separati: in teoria in futuro potremmo benissimo vedere le unità x87/MMX ed SSE totalmente indipendenti (a parte le istruzioni di save e restore ).

Non credo che ciò avverrà, comunque, per quanto detto prima (è più conveniente condividere tutto dentro una sola unità funzionale).

cdimauro, pensavo fossero alineata le SSE fossero allineate a 64bit, mentre a 128 le SSE2, tuttavia con la dicitura [Double] intendevo dire che in un P4/K8 le unità SSE nella FPU sono a 64bit, e di conseguenza i dati di un registro xmm128 sono processati 64bit alla volta.
Da lì nelle specifiche del K8 ho visto appunto un path di decode apposito chiamato "Double" (oltre agli altri, VectorPath e DirectPath), suppongo perchè l'allineamento all'interno della FPU dei dati è a 64bit.

Supposizione supportata dalle latenze nel K8 di una FMUL (4 cicli e thruoghput 1) e di una MULPD (5 cicli e throughput 1/2) che dovrebbe implicare o l'utilizzo della unità SIMD x 2 istruzioni (4 cicli per 4 stadi di exec della prima metà della operazione a 64bit e l'altro ciclo per completare la seconda operazione) oppure della SIMD+FMUL con l'aggiunta di un ciclo per impacchettare di nuovo i dati in un unico registro.
Nel P4 è meno ovvia la cosa perchè le latenze e i throughput sono meno comparabili.

... Scusate ... Mi sono accorto di avere scritto una caxxata al messaggio 121... Ho scritto che i registri a 90 bit sono acceduti dalle 3 ALU + 3 AGU + 3 FPU... Ho sbagliato! I registri interi ed FPU/SSEx sono separati... A quei registri ci accede solo la FPU... Quindi solo 3 unità... Nessun aumento di complessità... Anzi, sul G5 ci sono doppi data path, doppi banchi registri, doppi riordinatori, doppi schedulatori (anche se quelli dell'altivec avranno una sola porta...)
Non penso che nel G5 vengano usati multiplexer a iosa come nei K8/P4, in quanto c'è l'issue queue, che è una struttura completamente diversa e tende a funzionare come un buffer collegato ad un bus dati che collega le varie unità.
Ma più che altro questo lo vedi confrontando i core: con le misure dei DIE che hai in mm2 puoi fare una proporzione e vedi quanti mm^2 occupa l'issue queue di un G5, rispetto a tutte le altre sezioni di scheduling/register renaming di K8 e P4.

Ma nei K8 non sono usati multiplexer a iosa... Per rispondere a tutti e due... Qualcuno, qualche giorno fa, su questo sito ha postato un link ad una analisi approfondita della microarchitettura del K8 (e per quello che ci riguarda, cioè la FPU / SSEx, è lo stesso anche nel K7, come riportato in quello stesso articolo), dove è spiegato che i registri temporanei (per il register renaming) della FPU sono a 90 bit (io credevo che bastassero 80 bit, ma forse sono decodificati), più due bit per dire se è infinito, nan ecc. Questi registri sono condivisi e ne sono usati due (usandone solo 64 bit) per memorizzare un registro a 128 bit SSEx... Quindi nel K8 non ci dovrebbero essere multiplexer a iosa... Neanche nel G5, perchè i data path e le issue queue sono separate... Due serventi e due code, contro un servente e una coda...

x Dreadnought: l'allineamento dei dati con le SSE è sempre a 128 bit, così come l'ampiezza dei registri di questa unità SIMD.

Durante l'esecuzione il discorso è diverso, perché le istruzioni (e i registri su cui lavorare) vengono spezzate in due ed eseguite soltanto per "comodità".
Questo per sfruttare molta della logica già utilizzata per implementare le MMX (se ci fai caso tante istruzioni SSE sono l'esatto equivalente delle MMX, ma che agiscono sul doppio dei dati) e le risorse a disposizione (esempio: c'è un solo moltiplicatore e un solo sommatore a doppia precisione), come pure la logica di reordering già presente.

Ma avviene tutto nella sola fase di esecuzione, appunto.

Il PCI-express non è che sia sto gran bus, ha le sue limitazioni, ne parlava un tecnico creative che affermava quanto fosse inadatto ad esempio per le schede sonore.


Si,ma non è che quanto detto da un tecnico Creative abbia tutto questo gran peso.Mica ha parlato un'ingegnere della Motu o della M-Audio.
Le schede audio della Creative sono feccia,buone soltanto per giocarci.Lontane anni luce dalle schede audio professionali per Computer Music.