[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

Originariamente inviato da the_joe

Scusa commerciante, come li fai i conti? se il 6900K costa mediamente in ITALIA compresa IVA circa 1100Euro, il Top Ryzen 8/16 a 800Euro (probabilmente senza IVA ma diciamo che c'è anche l'IVA dentro) è un MISERO come diresti tu -27% circa

Buona fine anno e buon inizio 2017 a tutti.

Se leggi meglio, lui mette da 650$ a 800$, ed io ho fatto 1170$ -50% = 585$, = quasi il -50%.

Tu hai preso 800$, senza valutare che lui per 800$ intende con il kit di raffreddamento a liquido compreso, cosa che il 6900K non ha, in quanto la confezione non ha proprio il dissi, quello te lo devi comparare a parte. L'ho messo evidenziato nel mio post successivo

Buon anno anche a te.

[Mister D]

Originariamente inviato da george_p

Ricordami per favore, la cpu Broadwell è quella con il più alto ipc?
Cioè mi sembra di aver letto che le successive non lo aumentino di niente o quasi.
Perché un tempo si ipotizzava un ipc vicino ad Haswell.
E, soprattutto, parliamo di ST... o no?

Quasi.
tra skylake(=kabylake) e broadwell c'è circa il 3% (fonte anandtech).
Io, personalmente quando parlo di IPC, intendo le istruzioni per clock ergo la capacità di un processore di elaborare un tot di istruzioni a parità di frequenza, ergo tra ST e MT cambia solo il numero di core, la frequenza e lo scaling tra ST ed MT in un software.
Partendo dall'IPC in ST si potrebbe dire che in MT l'IPC_MT = IPC_ST * # core (thread)*k (coefficiente di scaling). Ovviamente prendendo tutto a parità di frequenza ma per via dei pstate in turbo delle cpu moderne questo deve essere indicato chiaramente che il confronto è fatto a parità di frequenza oppure introdurre nella formula sopra un fattore correttivo per la diminuzione di frequenza quando sono caricati tutti i core rispetto alla frequenza quando è caricato un solo core (* freq multi/freq sing).

Per cui sì intendo in ST. Chiaramente essendo a parità di frequenza per me ZEN potrebbe dire la sua con le cpu 2011 solo se avrà livelli di frequenza comparabili o un po' più alti. Se avrà frequenze pari in MT e più basse in ST allora le cpu intel risulteranno più veloci in ST e pari o poco sopra in MT.

[george_p]

Originariamente inviato da Mister D

Quasi.
tra skylake(=kabylake) e broadwell c'è circa il 3% (fonte anandtech).
Io, personalmente quando parlo di IPC, intendo le istruzioni per clock ergo la capacità di un processore di elaborare un tot di istruzioni a parità di frequenza, ergo tra ST e MT cambia solo il numero di core, la frequenza e lo scaling tra ST ed MT in un software.
Partendo dall'IPC in ST si potrebbe dire che in MT l'IPC_MT = IPC_ST * # core (thread)*k (coefficiente di scaling). Ovviamente prendendo tutto a parità di frequenza ma per via dei pstate in turbo delle cpu moderne questo deve essere indicato chiaramente che il confronto è fatto a parità di frequenza oppure introdurre nella formula sopra un fattore correttivo per la diminuzione di frequenza quando sono caricati tutti i core rispetto alla frequenza quando è caricato un solo core (* freq multi/freq sing).

Per cui sì intendo in ST. Chiaramente essendo a parità di frequenza per me ZEN potrebbe dire la sua con le cpu 2011 solo se avrà livelli di frequenza comparabili o un po' più alti. Se avrà frequenze pari in MT e più basse in ST allora le cpu intel risulteranno più veloci in ST e pari o poco sopra in MT.

Si, anche per me l'ipc è sempre riferito come lo intendi tu. Non per tutti è riferito a pari frequenza, per quello specifico.
Grazie

[digieffe]

capitano riesci a leggere qualcosa in questo numero 2D3151A2M88E4 ?

buon 2017 a tutti

[cdimauro]

Originariamente inviato da tuttodigitale

lo sai meglio di me, che BD ha un quantitativo di cache assolutamente abnorme per l'utilizzo desktop....

Scusami, ma se AMD ha deciso di usare il suo transistor budget in un modo anziché un altro, saranno anche problemi suoi, che dovrà piangersi lei?

La generosa cache L2 le serve per compensare le scelte che ha fatto riguardo alle cache L1.

16KB di L1 dati esclusive, per giunta a sole 4 vie, per thread hardware sono pochini, non credi? E la cache L1 istruzioni, sebbene di ben 64KB (SB ne ha la metà), ma con associatività a sole 2 vie.

Il che si traduce in un maggior sforamento delle cache, che dev'essere compensato ovviamente dalla cache L2. Quest'ultima è ben dimensionata, ed è pure a 16 vie, ma ha una latenza molto elevata (probabilmente avranno scelto un design per ridurre i costi, in termini di transistor).

Come vedi sono scelte progettuali che si pagano, a caro prezzo in questo caso.

non mi pare che ci siano differenze significative con Richland, (neppure lato consumi)

?

OK, ma il discorso che fai dopo è privo di senso, imho.

Non mi pare, ma ne parliamo dopo.

a parte che il livello di integrazione di Intel è superiore, quindi i numeri andrebbero rapportati anche al silicio usato, per capire quanti sono i transistor in gioco...

Cosa vorresti fare nello specifico? I dati sono lì, a tua disposizione, come pure il fattore densità che trovi riportato nel pezzo di AnandTech.

metti nella quotazione la l3, trascurando il fatto che la l3 è fondamentale in SB, per le ridotte dimensioni della velocissima l2,mentre in BD/K10 ci sarebbe comunque 1MB/core.

In BD ci sono 2MB/modulo di cache L3, che è esattamente la stessa quantità per SB.

Per le cache L1 & L2 vedi sopra: scelte di design.

E poi facciamo finta di non sapere che quei 10mmq, tra modulo BD e SB, è contenuta una differenza enorme di cache....4MB vs 2MB....è chiaro che la prima è una cpu maggiormente votata ai carichi server.

E non sarà forse un problem di AMD? Che colpa ne avrebbe Intel, se AMD ha usato il suo transistor budget in quel modo?

Poi, se permetti, Intel ha deciso di impiegare più transistor nell'FPU, dotandola di ben 3 porte a 256 bit. AMD ha scelto di avere 4 porte a 128 bit (sebbene 2 dotate di FMAC). Perché di questo non ti lamenti?

Noi dobbiamo soltanto prendere atto dei prodotti finiti, e vedere come vanno. Lamentarsi a giochi ormai ampiamente fatti, non ha più alcun senso.

quindi perchè quando ti fa comodo metti in ballo le cache...

Veramente ho messo sul piatto tutte le informazioni: core, core + L2, e core + L2 + L3.

In questo modo è possibile valutare anche il singolo core, sebbene nel computo di SB sia già inclusa la (veloce) cache L2.

In ogni caso hai dimenticato perché siamo arrivati a questo punto? Perché si parlava di dimensioni dei core/moduli, che a tuo avviso sarebbero sovrapponibili. Non mi pare proprio che lo siano, dati alla mano.

che FX sia un prodotto costoso è cosa assodata, come lo è il fatto che AMD mai avrebbe voluto paragonarlo ad un i7 quad-core o peggio ancora ad un i5...

Ma anche no: un FX da 4 moduli / 8 thread hardware è perfettamente comparabile a un i7, che ha 4 core / 8 thread.

Perché non dovrebbe esserlo?

jaguar è un progetto completamente differente, se non altro le dimensioni minimali (3,1mmq vs 9,7mmq), il maggior numero di stadi (12 vs 15) fa pensare a questo

Nulla da dire su questo. E infatti di Jaguar ne hai parlato tu, non io, in relazione a FO4, frequenze, e consumi.

ma guarda ho detto che BD ha prestazioni ST superiori a k10, nonostante l'ipc inferiore, in virtù della maggior frequenza. Anche i test sotto azoto liquido ci dice che il FO4 di BD(zambesi) è decisamente più basso rispetto a k10 (llano).

Vabbé, adesso anche l'azoto liquido. Da quando la bontà di un processore si misura avendogli tirato il collo con l'azoto? Io preferisco attenermi a quello che arriva nelle mani dei consumatori, che normalmente usano il prodotto così com'è. E con ciò mi riferisco anche alle aziende e ai loro server.

Ciò precisato, avevi scritto questo:

"perchè il parallelo con k10, vede quest'ultimo prevalere non solo con BD, ma anche con SB, quando si parla di throughput per mmq a parità di clock (i core k10 sono grandi circa 9,6mmq)..."

E comunque ti ho portato dei benchmark in cui il Phenom-II X4, a parità di clock (e non per forzature: BD e Phenom-II con le loro frequenze stock), mostrava prestazioni superiori. E a maggior ragione per l'X4 a frequenze superiori. Quindi non è strettamente una questione di IPC, ma di prestazioni.

ma resta l'incognita del processo.....il fatto che k10@45nm viaggi a frequenze simili a BD@32nm è una anomalia.

Prendendo anche i prodotti di IBM, sappiamo che i 32nm SOI non hanno offerto frequenze elevate rispetto ai 45nm: +5% per la soluzione CISC.

3,7GHz su una architettura da 12 stadi e con i 45nm lisci....
con il low-K, invece è riuscita ad ottenere 3,8GHz su 3 core, con un turbo core primitivo (i 6 core venivano alimentati alla stessa tensione)....meglio di Intel che si era fermata a 3,2GHz.

Sui 95W e con 4 core, non mi pare che K10 / Phenom-II (X4) abbia frequenze così elevate rispetto a Intel: 3.2Ghz vs 3.06 (Nehalem)

Quindi, almeno per i 45nm, non mi pare ci sia una forbice così elevata: appena 140Mhz a favore di AMD.

PS da 12 a 19/22 stadi, considerando le architetture ad alte prestazioni di AMD, non mi sembra un salto piccolo...

Senz'altro.

Originariamente inviato da tuttodigitale

Premesso che i consumi più ampi potrebbe essere dovuto al vcore, ad una implementazione sul silicio perfettibile, o un altra diavoleria come al controllo dinamico della tensione ancora non messo a punto, o addirittura al BIOS (elemento alquanto indispensabile per la gestione della potenza).
Siamo all'oscuro del motivo per cui quel ES consumi così tanto.

il mio discorso era più di carattere filosofico
Imho non ha senso dire che quelle era un ES che lavorava fuori specifica, quando queste sono tutt'altro che determinate.

SE le voci dell'overvolt fossero confermate, almeno per QUEL sample si può dire che lavorasse fuori specifica.

E fai bene a sottolineare i consumi, perché sono sembrati abbastanza elevati (mi riferisco al delta idle - full load).

Originariamente inviato da bjt2

Se ho capito bene la traduzione (non conosco il francese e ho provato google translate sia in italiano che in inglese), loro considerano BD/BD un quadcore e 8 thread.

Beh, E' così.

Non hanno pubblicato i dati grezzi per non sputtanare la loro fonte, ma 4c/8t vs 4c/8t c'è un +35% in MT. Quindi 8c/16t hanno ottenuto 2.7 volte le prestazioni di PD, aggiustati per la frequenza. Ovviamente sia lo scaling in frequenza che di core è da prendersi con le pinze (non hanno disabilitato i core zen per fare 4c/8t ne undercloccato PD... Sarebbe da provare), ma è una indicazione di quanto buono è Zen.
Solo +35% rispetto a PD con il doppio di FP, il doppio di core e il doppio di thread e tutte le migliorie architetturali mi pare poco...

Aspetta: se il +35% è riferito, come pensiamo, all'IPC, perché lo ritieni poco? A me sembra un buon risultato.

Originariamente inviato da Piedone1113

Quando nomina i calcoli bruti.
In genere in territorio francese il colcolo bruto è riferito ad applicazioni ST (chi più ne ha più ne metta).
Potrei aver interpretato male, ma conoscenti d'oltrarpe usavano locuzioni simili per il super pi (per esempio)

OK, capito.

Originariamente inviato da Mister D

Prima di tutto:

Buone feste e buon anno a tutti! Che sia un 2017 pieno di concorrenza

Poi vorrei portare alla luce questa questione:
http://www.agner.org/optimize/optimizing_cpp.pdf
da pag 133:
13.7 CPU dispatching in Intel compiler
[...]
Ma la FTC (Federal Trade Commission) non aveva preteso da Intel nel 2010 se ben ricordo di mettere a posto il proprio compilatore per evitare ciò?

No. Ha preteso che Intel DOCUMENTASSE il comportamento del compilatore, in modo che gli acquirenti ne fossero preventivamente informati. E' per questo che è stata condannata: mancanza di adeguata informazione.

Per il resto il compilatore poteva, e può, benissimo funzionare come descritto, perché è così che devi operare se vuoi generare codice altamente ottimizzato (per determinate micro-architetture, ovviamente).

Chiedo ai più esperti perché a leggere, se ho ben interpretato, sembra che delle penalità ci siano cmq usando senza correzioni l'intel c++ compilier con cpu non-intel. Ho capito male? Perché se fosse così saremmo da capo e non capisco perché, visto che intel con tutto il vantaggio che ha per me non avrebbe bisogno di tali pratiche.

Non sono pratiche, infatti: è così che deve funzionare un compilatore che vuol spremere il più possibile da una micro-architettura.

In ogni caso bisogna vedere SE/CHI usa il compilatore Intel, e quale sarebbe poi il vantaggio per le specifiche applicazioni (visto che il codice generato è diverso, e ci possono essere più o meno ottimizzazioni).

[bjt2]

Originariamente inviato da cdimauro

Aspetta: se il +35% è riferito, come pensiamo, all'IPC, perché lo ritieni poco? A me sembra un buon risultato.

+35% sarebbe stato poco se fosse di throughput, ossia 4m/8t vs 8c/16t, perchè AMD ha sempre considerato BD un octacore, ma leggendo meglio si capisce che intendono +35% a parità di thread e quindi 4m/8t vs 4c/8t, ossia quindi Zen andrebbe 2,7 volte PD come throughput medio (correggendo per il clock, ovviamente). Essendoci circa un 25% (4 vs 3 GHz) di differenza di clock, questo combacia perfettamente con il doppio del throughput promesso in quel grafico senza numeri, che tanto scatenò gli animi... Ma oggi sappiamo che il clock finale sarà un po' più di 3GHz...

P.S.: BUON ANNO A TUTTI!

[Mister D]

Originariamente inviato da cdimauro

cut...
No. Ha preteso che Intel DOCUMENTASSE il comportamento del compilatore, in modo che gli acquirenti ne fossero preventivamente informati. E' per questo che è stata condannata: mancanza di adeguata informazione.

Per il resto il compilatore poteva, e può, benissimo funzionare come descritto, perché è così che devi operare se vuoi generare codice altamente ottimizzato (per determinate micro-architetture, ovviamente).

Non sono pratiche, infatti: è così che deve funzionare un compilatore che vuol spremere il più possibile da una micro-architettura.

In ogni caso bisogna vedere SE/CHI usa il compilatore Intel, e quale sarebbe poi il vantaggio per le specifiche applicazioni (visto che il codice generato è diverso, e ci possono essere più o meno ottimizzazioni).

Ok, ricordavo o avevo capito male. Grazie. Ma a sto punto intel documenta queste penalità in caso di uso di cpu diverse dalle sue con il suo compilatore? Te lo chiedo per sicurazza e perché so che ci lavoravi proprio nella programmazione ma do già per scontato che lo faccia

[cdimauro]

@bjt2: sai cosa ne penso sull'IPC, e l'ho scritto pure su AnandTech: sono TUTTE le istruzioni mediamente eseguite per ciclo di clock (quindi tengo conto di tutte le istruzioni processate da un core, anche se provengono da due thread).

Dunque parliamo di MT, se l'applicazione è MT, ed ST se il codice è ST.

Grazie, e auguri di buon anno a tutti.

[cdimauro]

Originariamente inviato da Mister D

Ok, ricordavo o avevo capito male. Grazie. Ma a sto punto intel documenta queste penalità in caso di uso di cpu diverse dalle sue con il suo compilatore? Te lo chiedo per sicurazza e perché so che ci lavoravi proprio nella programmazione ma do già per scontato che lo faccia

No, non può documentarle anche volendo, visto che escono nuovi processori.

Intel documenta per quali micro-architetture ottimizza. Anche perché i code-path non possono essere molti, altrimenti le dimensione del codice esploderebbero.

[Mister D]

Originariamente inviato da cdimauro

No, non può documentarle anche volendo, visto che escono nuovi processori.

Intel documenta per quali micro-architetture ottimizza. Anche perché i code-path non possono essere molti, altrimenti le dimensione del codice esploderebbero.

No scusami, ho scritto male la domanda. Mi correggo: se è stata condannata per mancanza di adeguata informazione, ora mi aspetto invece che documenti circa la possibilità di penalità (non su quanto ovviamente che dipende da caso a caso) in caso di utilizzo di quei code-path su cpu non intel. Corretto?

[Grizlod®]

In effetti lo documenta:
http://www.polyhedron.com/web_images...fs/3a_SIMD.pdf



Felice 2017 a tutti!

[Mister D]

Originariamente inviato da Grizlod®

In effetti lo documenta:
http://www.polyhedron.com/web_images...fs/3a_SIMD.pdf



Felice 2017 a tutti!

Grazie mille. Lo documenta eccome ergo è tutto nero su bianco

[digieffe]

Originariamente inviato da paolo.oliva2

http://cpugrade.com/amd-ryzen-thoughts/

Non ho capito una cosa....

Nella tabella dei consumi, hanno scritto che un Zen X8+8 @4,1GHz consumerebbe MENO di un 8370 a def, cioè 116W vs 118W di un 8370.

In basso c'è la nota che i dati sarebbero teorici... ma teorici fino ad un certo punto, perchè se non sai quanto scala il silicio in frequenza rispetto al TDP, non si potrebbe scrivere nulla, se lo hanno scritto, era su qualche dato?

Non è che voglia sollevare un bollirone, ma messo così sembra quasi che Zen X8+8 abbia frequenze/TDP alla Piledriver... perchè QUEL dato concorda con il rumors dei 5GHz ad aria...

NO!!!

premetto che non ho letto i post oltre questo, devo leggere anche la parte sul consumo.

detto ciò quelli degli over/under-clocked sono calcoli LINEARI errati, il tipo non ha calcolato neanche il QUADRATICO chè è il caso più favorevole: quindi zen oc 4 ghz consuma ALMENO 143w. ciao

[paolo.oliva2]

Se mi chiarite un punto.

Per quello che sapevo, una volta, si era bacchettata Intel perchè i compilatori avevano una specie di "if genuine Intel allora fai questo, else, quest'altro.
Ricordo che Intel si era giustificata perchè non poteva ottimizzare proci non suoi, però c'era un punto in cui sembrava che volutamente non si eseguiano delle istruzioni ma altre meno efficienti.

Però io devo capire... se i ruoli fossero invertiti, e quindi AMD facesse i compilatori, Intel potrebbe obbligare AMD a fare i compilatori per lei? Cioè... io direi che sono cacchi tuoi. Quindi mi chiedo... perchè AMD non si fa dei compilatori in proprio per i suoi proci e librerie idonee a C++ & C.?

Cioè... se Intel paga ad AMD le features dell'interfacciamento X86/iGPU, AMD paga Intel per i compilatori, e tutti vivono felici e contenti.

[Gioz]

Originariamente inviato da digieffe

NO!!!

premetto che non ho letto i post oltre questo, devo leggere anche la parte sul consumo.

detto ciò quelli degli over/under-clocked sono calcoli LINEARI errati, il tipo non ha calcolato neanche il QUADRATICO chè è il caso più favorevole: quindi zen oc 4 ghz consuma ALMENO 143w. ciao

io mi sono fermato con la lettura al "prendiamo il punteggio cinebench più alto..." linkando un *8370 sotto LN2 a oltre 7GHz

EDIT: * 8350

[paolo.oliva2]

Originariamente inviato da digieffe

NO!!!

premetto che non ho letto i post oltre questo, devo leggere anche la parte sul consumo.

detto ciò quelli degli over/under-clocked sono calcoli LINEARI errati, il tipo non ha calcolato neanche il QUADRATICO chè è il caso più favorevole: quindi zen oc 4 ghz consuma ALMENO 143w. ciao

Infatti l'ho scritto perchè guardando le performances in OC di Zen, non solo non perdeva una mazza ma era anche più efficiente, poi ho visto la riga sotto e ho visto che ha arrotondato lo 0,89 a 0,9.

Ma scusate... come dici tu, e mi sembra esatta l'interpretazione di come ha fatto klui, ci sono errori grossolani mastodontici... praticamente è esatta l'interpretazione di MisterD, nel senso che lui ha scritto i bench per come sono stati fatti da AMD, e fa le varie previsioni a varie frequenze e vari consumi, ma le prestazioni non possono essere le medesime perchè (A0 avevano dei bug/bios non a puntino, frequenze inferiori ai prox proci commerciali), consumi idem, perchè se Zen 95W A0 era 3GHz, e Zen commerciale 3,7GHz sempre 95W, sballa ineramente il consumo/prestazioni perchè le prestazioni aumenterebbero ed il consumo no. Idem per i prezzi, avevo già postato prima.

E poi, se vogliamo mettere i puntini sulle i, l'8370 di certo non ha quel consumo, perchè io 1,28V 4,5GHz consumo meno del def (dissi stock, scalda meno per come l'ho settato io che a parametri def).
E poi bisogna anche vedere le frequenze finali di Zen in relazione ai 95W TDP... una cosa sarebbero 3,5GHz 95W con +500MHz di OC, tutt'altro 3,8GHz 95W, con +200MHz OC e magari procio fortunello.

Resta comunque il fatto che ho molti dubbi in proposito... perchè un X8 con il doppio dei TH, sotto carico (e non intendo il carico di 1 bench, ma di più programmi), a me sembra fantascientifico 95W a prossimi 4GHz con IPC simile a BW. Cacchio, sarebbe già ottimo se al posto del 14nm Samsung fosse a 7nm...

[paolo.oliva2]

Originariamente inviato da Gioz

io mi sono fermato con la lettura al "prendiamo il punteggio cinebench più alto..." linkando un *8370 sotto LN2 a oltre 7GHz

EDIT: * 8350

7,649GHz per la precisione... una signora frequenza OC, ed i risultati si vedono.

Non so come sarà Zen sotto azoto... però, viste le frequenze, sicuramente Zen ha più in comune con BD che con Intel a livello di FO4.. Dubito i quasi 9GHz in screen e quasi 8GHz in bench, ma anche ipotizzando una via di mezzo tra Intel e BD, cacchio, i numero si che verrebbero fuori.

[bjt2]

Originariamente inviato da cdimauro

@bjt2: sai cosa ne penso sull'IPC, e l'ho scritto pure su AnandTech: sono TUTTE le istruzioni mediamente eseguite per ciclo di clock (quindi tengo conto di tutte le istruzioni processate da un core, anche se provengono da due thread).

Dunque parliamo di MT, se l'applicazione è MT, ed ST se il codice è ST.

Grazie, e auguri di buon anno a tutti.

Si, ricordavo cosa intendevi... E' sempre meglio specificare per chi non lo sa...

P.S.: di la tra bimbi piccoli e altro c'è un casino... Mi sono rifugiato in stanza dopo l'aperitivo... Le feste...

[bjt2]

Originariamente inviato da digieffe

NO!!!

premetto che non ho letto i post oltre questo, devo leggere anche la parte sul consumo.

detto ciò quelli degli over/under-clocked sono calcoli LINEARI errati, il tipo non ha calcolato neanche il QUADRATICO chè è il caso più favorevole: quindi zen oc 4 ghz consuma ALMENO 143w. ciao

Ma forse loro ipotizzano che scali come la serie FX 83xx... E l'8370E è 95W e 3.3GHz di base e l'8370 è 4GHz base e 125W...

[bjt2]

Originariamente inviato da paolo.oliva2

Se mi chiarite un punto.

Per quello che sapevo, una volta, si era bacchettata Intel perchè i compilatori avevano una specie di "if genuine Intel allora fai questo, else, quest'altro.
Ricordo che Intel si era giustificata perchè non poteva ottimizzare proci non suoi, però c'era un punto in cui sembrava che volutamente non si eseguiano delle istruzioni ma altre meno efficienti.

Però io devo capire... se i ruoli fossero invertiti, e quindi AMD facesse i compilatori, Intel potrebbe obbligare AMD a fare i compilatori per lei? Cioè... io direi che sono cacchi tuoi. Quindi mi chiedo... perchè AMD non si fa dei compilatori in proprio per i suoi proci e librerie idonee a C++ & C.?

Cioè... se Intel paga ad AMD le features dell'interfacciamento X86/iGPU, AMD paga Intel per i compilatori, e tutti vivono felici e contenti.

Se ti leggi i manuali di ottimizzazione AMD, è scritto che la pratica ottimale sarebbe: se la CPU supporta X, allora usa le istruzioni X e così via.
Invece i compilatori INTEL facevano (? Secondo quel PDF di Agner lo fanno ancora) così: Se la CPU è INTEL e supporta X, allora usa X, altrimenti usa Y (meno efficiente)...