Chipset AMD serie 7, la base dei sistemi Spider

[MiKeLezZ]

Originariamente inviato da ThePunisher

Scusate ma dov'è il 20% in più che dichiarano? LOL!

"Colpa del bug", così dicono......... Si aspettano driver più agg.. ehm.. step produttivi più aggiornati.........

[xeal]

Ripensandoci, quello delle ottimizzazioni del compilatore potrebbe anche essere un problema (entro certi limiti). Un compilatore che supportasse le SSE per i K8 potrebbe forse, ove applicabile, spezzare automaticamente una operazione su dati a 128bit in due con vettori a 64bit (lo farebbe comunque il processore da sè, ma non so se questo potrebbe influire sullo scheduling delle pipepline - es: l'operazione spezzata rimane vincolata alla pipeline di origine, mentre due separate dall'origine potrebbero occupare le due unità, non ne ho idea), e in questo modo software già compilati non sfrutterebbero le migliorie architetturali dei k10.

E' vero che una cpu deve far girare bene il software senza richiederne la ricompilazione, ma è anche vero che le variazioni nell'architettura devono essere supportate dal compilatore, altrimenti è come se non ci fossero (comunque, questo non varia la natura di "handicap" se la ricompilazione dovesse essere necessaria per sfruttare appieno le potenzialità dei k10). Sarebbe forse interessante vedere cosa accadrebbe facendo riconoscere a un bench il processore amd come se fosse un intel, ma bisognerebbe patcharlo, oppure usare un emulatore x86 modificato per fornire una stringa identificativa modificata e poi dirottare l'esecuzione verso il processore vero (o usare un meccanismo equivalente per intercettare e alterare il riconoscimento della cpu)... insomma sarebbe complicato, in alcuni casi forse non troppo lecito, e comunque il gioco temo che non varrebbe la candela...

[bjt2]

Originariamente inviato da xeal

Se non ho frainteso, credo che il primo bug, quello più lieve, possa esserlo in realtà meno di quanto non sembri, non tanto per le occorrenze, ma per le penalizzazioni introdotte quando si verifica: in pratica, quando si deve effettuare uno store, può capitare che il processore non abbia immediatamente a disposizione i dati per calcolare l'indirizzo reale (ovvero non trova i dati della page table nella cache tlb), quindi deve accedere alla ram una prima volta per trovare quei dati, calcolare l'indirizzo, e accedere la seconda volta per scrivere il dato. Questo comporta una prima penalizzazione per via del doppio accesso che diventa più frequente rispetto ad una cpu senza il bug, ma credo anche una seconda, più subdola, perchè può far saltare il riordino delle operazioni di load/store per privilegiare le prime (e quindi, potenzialmente, far saltare un po' di operazioni in sospeso per un solo indirizzo), poichè il riordino avviene dopo il calcolo degli indirizzi per evitare errori. Sbaglio?

Dunque. Senza bug, mi pare di aver capito che funziona così:

Per tradurre qualsiasi indirizzo virtuale (il kernel può usare anche quelli fisici e se ne frega del bug) deve avere una entry di page table. Se non si trova nella cache L1 (divisa per dati e istruzioni come la cache normale), va alla L2 (stavolta unificata). Se non si trova nella L2, supponendo che non abbia una cache L3 anche per i TLB (come probabile, ma non ho informazioni in merito), allora fa un normale accesso in RAM che comprende anche uno snoop nelle varie caches (ed eventualmente in quelle di altri processori per sistemi MP). Se anche in cache normale non c'è, allora va in RAM.

Con il BUG, si deve applicare il workaround che disabilita il caching della page table in cache normale: se non c'è nella L1 TLB e nella L2 TLB, va direttamente in RAM perchè essendo il caching in cache normale delle page table disabilitato, non c'è modo di trovare i dati in cache...

L'altro bug abbiamo già chiarito...

Per quanto riguarda la questione dei 2.4GHz... IMHO per CPU inferiori a 2.4GHz, il workaround garantisce il non blocco anche ad alti carichi, invece per frequenze superiori o uguali a 2.4GHz anche con il workaround si verificano i blocchi... Oppure è solo una questione di TDP...

[bjt2]

Originariamente inviato da schwalbe

Ma non sono neanche sposi di Intel...
Poi vedi sotto il mio pensiero.




È da tempo che i compilatori hanno opzioni di compilazione per specifiche CPU, oltre al supporto delle istruzioni aggiuntive. Ma il problema è a monte: in un mondo dove spesso i programmi non escono quando sono pronti ma quando l'ufficio commerciale dice "è ora di portar quattrini in cassa" porta ad un software in gran parte standarizzato e non ottimizzato, dove deve andar mediamente bene con tutto e romper poco le scatole. Fare eseguibili in base alla piattaforma vuol già dire un doppio/triplo/quadruplo/... lavoro, e già per i produttori è seccante i 32 e 64 bit.
Su queste cose son pessimista (almeno per il software commerciale, quello verticale ha dinamiche diverse di mercato)...
Felice di esser smentito, pero.

Non ci vuole molto a settare delle opzioni del compilatore per dire di generare n code path separati (ed eventualmente anche la versione a 64 bit)... Si tratta di abilitare dei flag e aspettare un po' di più per compilare...

Per build non definitive sono daccordo che il processo di compilazione deve essere il più veloce possibile (quindi probabilmente ci sarà solo una versione, magari non ottimizzata), ma la release dovrebbe avere tutti i codepath, IMHO...

[Crystal1988]

Originariamente inviato da leoneazzurro

In realtà l'impatto prestazionale di questi bug non è facilmente quantificabile a priori. Chiaro che risolvendoli si guadagnerà in prestazioni. Di quanto dipende dal resto dell'architettura del processore e dal codice utilizzato. Ad esempio, se il controller di memoria dei K10 fosse più ottimizzato per quanto riguarda il "nascondere" le latenze il comportamento riguardo al timing del command rate potrebbe essere diverso rispetto al K8. Quindi anche se in teoria è possibilissimo un miglioramento del 5-10% (ma anche di più, a seconda della frequenza di apparizione dei bug e dal loro impatto "a catena" ad esempio sul prefetching e sul riordino dei load/store) la cosa va verificata prima di stilare una conclusione definitiva.
L'altro problema grosso è che bug di questa entità non sarebbero dovuti esserci a aquesto stadio.



Purtroppo questo è il problema. E non solo la CPU, ma anche l'utilizzo di un SB "anziano" sui chipset 790 mostra che l'acquisizione di ATI abbia creato più di un problema nelle roadmap.



Questa è una delle ipotesi possibili, fatto sta che comunque una data architettura deve "lavorare" bene con quello che c'è in giro, anche perchè se così fosse (se si dovesse ricompilare il SW), AMD avrebbe già perso in partenza: nessun sviluppatore dovrebbe essere costretto a ricompilare il proprio SW a causa di una nuova CPU.

Ma infatti non dico che siano fasulli i test e le applicazioni che usiamo sempre... mi sembra strano che in AMD abbiano fatto questo errore colossale... cambiando compilatore le differenze sono enormi... ciò significa che in AMD hanno fatto qualche errata previsione di grave conto.

[Crystal1988]

Francamente, non darei troppo troppo peso ai test SPEC: da un lato sono orientati prevalentemente alla valutazione delle prestazioni pure (ovvero, cercano di raggiungere il picco teorico massimo di operazioni di cui la cpu è capace sulla carta), e quindi non si può traslare con semplicità il risultato negli scenari d'uso reali (almeno per quanto riguarda spec_int e spec_fpu); dall'altro, proprio per ricercare il picco delle prestazioni, si concede una notevole libertà nelle ottimizzazioni di compilazione, che vengono scelte di conseguenza. Nei programmi d'uso "reale", invece, questo non ha senso, perchè lo stesso codice deve girare decentemente su tutte le macchine compatibili, quindi si cercherà un'ottimizzazione "media" o "standard" e/o ci si baserà principalmente su una macchina target scelta come riferimento di mercato. Diciamo che possiamo aspettarci, in molti casi, del codice che sia ottimizzato prevalentemente per intel e giri pressochè uguale su amd: siccome l'implementazione corrente dei k10 sui vettori a 128 bit è equivalente a quella intel, le ottimizzazioni "di base" dovrebbero andare più che bene (al resto ci pensa la logica out-of-order). Quindi, se ci saranno miglioramenti, aspettiamoci che provengano dalla correzione dei bug

Ma infatti il mio discorso non è che siano più affidibali... nel senso:
è chiaro che nel scenario comune, questi test siano inutili, tuttavia sono semplicemente applicazioni comuni che vengono ricompilate, non viene fatto nulla di trascendentale; ciò esplica il fatto che cambiando solo il compiler i risultati siano estremamente differenti.

Se si fa il conto che la potenza in FP del K10 è il doppio del K8 come risorse, non avrebbe senso che esso vada solo mediamente un 10 o 20 % in più rispetto al vecchio processore... infatti cambiando compiler, lo scenario cambia drasticamente. Ciò non vuol dire che ci sia un errore da parte dei programmatori (tuttavia, essendo le istruzioni fra Intel e Amd differenti, è chiaro che l'utilizzo di diversi compiler porti ad una differente ottimizzazione) (e cmq se i programmato usassero vari compiler potrebbero migliorare le prestazioni per processore e famiglia), ma vuol dire semplicemente che, per i compiler più comuni, Amd ha sbagliato approcio.

Ripeto, non voglio assolutamente dire che per le applicazioni comuni bisogna prendere in considerazione Spec. Anzi, non serve a nulla, Spec però ci fa vedere come cambiare compiler cambi le cose (e poi, se uno vuole, può anche decompilare, e compilare con un compilatore appropriato, per esempio sotto linu un per PathClass o PGI, e i risultati in FP cambiano...).

In aggiunta, i compilatori hanno opzioni di compilazione al proprio interno, quindi non dovrebbe esserci nessuna ottimizzazione in questo senso per una famiglia o l'altra, ma a loro volta ci sono COMPILATORI (con opzioni all'interno) che sono più affini ad alcuni o ad altri processori.. i PGI ed i PathClass sotto linux hanno al proprio interno delle opzioni di compilazione, ma vanno a nozze con i phenom.

[Crystal1988]

Originariamente inviato da bjt2

Non ci vuole molto a settare delle opzioni del compilatore per dire di generare n code path separati (ed eventualmente anche la versione a 64 bit)... Si tratta di abilitare dei flag e aspettare un po' di più per compilare...

Per build non definitive sono daccordo che il processo di compilazione deve essere il più veloce possibile (quindi probabilmente ci sarà solo una versione, magari non ottimizzata), ma la release dovrebbe avere tutti i codepath, IMHO...

è vero, ci sono le opzioni di compilazione per architettura, tuttavia i compiler di varie case sono molto differenti fra loro.. quindi la differenza prestazionale di compilazione è più da giocarsi sul differente compilatore più che per le opzioni.

[Crystal1988]

Originariamente inviato da schwalbe

Ma non sono neanche sposi di Intel...
Poi vedi sotto il mio pensiero.




È da tempo che i compilatori hanno opzioni di compilazione per specifiche CPU, oltre al supporto delle istruzioni aggiuntive. Ma il problema è a monte: in un mondo dove spesso i programmi non escono quando sono pronti ma quando l'ufficio commerciale dice "è ora di portar quattrini in cassa" porta ad un software in gran parte standarizzato e non ottimizzato, dove deve andar mediamente bene con tutto e romper poco le scatole. Fare eseguibili in base alla piattaforma vuol già dire un doppio/triplo/quadruplo/... lavoro, e già per i produttori è seccante i 32 e 64 bit.
Su queste cose son pessimista (almeno per il software commerciale, quello verticale ha dinamiche diverse di mercato)...
Felice di esser smentito, pero.

ma infatti, non credo che il problema sia nelle opzioni di ricompilazione, ma nelle affinità fra compilatore ( e da compilatore a compilatore varia moltissimo) e processore.

In fin dei conti, credo che giri tutto intorno al fatto che Intel è MOOOOOLTO più presente sul mercato... quindi è chiaro che si utilizzino i compiler magari più adatti ad Intel... inoltre, sarebbe forse una rottura utilizzare più compiler.. un conto è compilare con opzioni... un altro conto è utilizzare più compiler. Rimane il fatto che questa cosa penalizza AMD (e lei si penalizza da sola)

[leoneazzurro]

Originariamente inviato da Crystal1988

Ma infatti non dico che siano fasulli i test e le applicazioni che usiamo sempre... mi sembra strano che in AMD abbiano fatto questo errore colossale... cambiando compilatore le differenze sono enormi... ciò significa che in AMD hanno fatto qualche errata previsione di grave conto.

Dipende anche moltissimo dalle applicazioni utilizzate e dal mix di istruzioni che esse utilizzano. Abbastanza illuminante la recensione di Anandtech nel confronto Xeon-Barcelona:

http://www.anandtech.com/IT/showdoc.aspx?i=3162

Il problema principale è che nei test sintetici il Barcelona è sullo stesso livello del Core2 (per clock) nei calcoli FP, a volte vincendo, a volte perdendo (a parità di clock) e meno prestante sugli interi (anche se sembra avere un 10% per clock rispetto al K8). In genere K10 in ambito interi paga soprattutto la minore quantità di cache e la latenza della cache L3 che può penalizzare in caso di branch misprediction. In Ambito FP K10 sembra essere sullo stesso piano del Core2, in questo caso paga invece la differenza di clock con la concorrenza. In ambito multisocket invece si vede il problema di scalabilità di Intel e viceversa il vantaggio delle connessioni HTT degli Opteron.

In un ambito desktop, purtroppo, molti dei vantaggi visti in ambito server si perdono, tuttavia:

1) K10 sembra scalare meglio le prestazioni all'aumentare della frequenza rispetto ai Core2
2) Sicuramente una volta corretti i bug, le prestazioni ne risentiranno in maniera positiva

Quindi il discorso è che se AMD riuscirà a coreggere i bachi e a salire in frequenza fino ai promessi 3 GHz e oltre, avrà in mano un prodotto competitivo, magari non un "C2 killer", ma sicuramente valido, anche in ambito desktop. Al momento attuale, tuttavia, a di fuori del segmento server non sembra esserci molta storia dal punto di vista delle prestazioni assolute.

[K7-500]

Stavo pensando, ma si possono organizzare visite guidate alla redazione di HWU?
Forse ci fanno la riduzione comitiva...

Vedo già delle scene alla Futurama: "...ecco i nostri umpa lumpa che eseguono test estenuanti in cicli di 24 ore senza pausa..."



Certo che questo articolo ha dato grande soddisfazione, anche nei commenti c'è dell'interessante.

[Crystal1988]

Originariamente inviato da leoneazzurro

Dipende anche moltissimo dalle applicazioni utilizzate e dal mix di istruzioni che esse utilizzano. Abbastanza illuminante la recensione di Anandtech nel confronto Xeon-Barcelona:

http://www.anandtech.com/IT/showdoc.aspx?i=3162

Il problema principale è che nei test sintetici il Barcelona è sullo stesso livello del Core2 (per clock) nei calcoli FP, a volte vincendo, a volte perdendo (a parità di clock) e meno prestante sugli interi (anche se sembra avere un 10% per clock rispetto al K8). In genere K10 in ambito interi paga soprattutto la minore quantità di cache e la latenza della cache L3 che può penalizzare in caso di branch misprediction. In Ambito FP K10 sembra essere sullo stesso piano del Core2, in questo caso paga invece la differenza di clock con la concorrenza. In ambito multisocket invece si vede il problema di scalabilità di Intel e viceversa il vantaggio delle connessioni HTT degli Opteron.

In un ambito desktop, purtroppo, molti dei vantaggi visti in ambito server si perdono, tuttavia:

1) K10 sembra scalare meglio le prestazioni all'aumentare della frequenza rispetto ai Core2
2) Sicuramente una volta corretti i bug, le prestazioni ne risentiranno in maniera positiva

Quindi il discorso è che se AMD riuscirà a coreggere i bachi e a salire in frequenza fino ai promessi 3 GHz e oltre, avrà in mano un prodotto competitivo, magari non un "C2 killer", ma sicuramente valido, anche in ambito desktop. Al momento attuale, tuttavia, a di fuori del segmento server non sembra esserci molta storia dal punto di vista delle prestazioni assolute.

Hai decisamente ragione per il mix... non c'è alcun dubbio che questo influisca particolarmente...
Tuttavia, come si è visto per LINPACK, hanno utilizzato un compilatore per K10... ok che il LINPACK è da sempre improntato per INTEL... tuttavia non mi dispiacerebbe vedere OGNI benchmark ricompilato, così anche solo per osservare i cambiamenti... visto che cmq sia... è vero ciò che dici per i mix... ma è anche vero che gli stessi identici benchmark di spec, SE NON RICOMPIALTI danno differenze mica da sottovalutare.. quindi rimango dell'idea che influenzino non poco le prestazioni... (senza nulla togliere ai mix).

Per l'INTEGER credo che i bug, soprattutto il secondo (ma anche il primo) aumenti non poco la latenza delle cache.... visto che per la scrittura su cache bisogna sempre riscrivere tutto.

Cmq sia c'è anche scritto che per alcuni programmi non sono riusciti neppure a compilare... questo a mio parere la dice lunga per quanto riguarda i K10... ci voglio nuovi e differenti compiler per sfruttarli bene.

[Crystal1988]

Cmq sia osservando quella recensione.. dal punto di vista server e workstation gli Opteron sono messi non male, facendo il conto che dispongono anch'essi dei famosi bug (non credo proprio sia uno step B3).. sono messi bene... anche se cmq rimangono preferibili gli Xeon

[Free Gordon]

Originariamente inviato da bjt2

Questione compilatori:
Tempo fa mi incavolai molto con MS. Scaricai la libreria jpeg 6.0 (mi pare). Sorgente, più DLL precompilata con compilatore MS. La ricompilai con compilatore Borland C++ 3.0 (un IDE piuttosto vecchio) e la DLL venne 64 KB. La DLL precompilata con Visual studio era 480 KB... Pensai: maledetta MS!!! Ma poi mi venne in mente: e se ci fossero varie versioni compilate e ottimizzate per le varie CPU e all'atto della inizializzazione della DLL venga determinata la CPU e scelta la più veloce?
Non siate così pessimisti...

Originariamente inviato da xeal

Diciamo che così finiamo a cavallo tra sorgente e compilatore. In parte quello che dici è vero se si deve programmare direttamente in assembly, ma se il tuo ide ti fornisce delle estensioni al linguaggio/delle librerie con le istruzioni astratte in funzioni di alto livello (che fanno da wrapper per una singola istruzione o per una sequenza funzionale: tu scegli la funzione e passi come argomenti le variabili che fungeranno da operandi, poi il compilatore deciderà come collocare quelle variabili tra cache e registri), allora la palla balza proprio al compilatore. Del resto, il compilatore qualcosa deve fare comunque: se si scrive codice basandosi sulle estensioni dell'isa di una sola (famiglia di) cpu, allora non appena il programma girerà su una cpu diversa produrrà una bella eccezione per istruzione non valida, se non un crash. Per ovviare a questo, un buon compilatore (diciamo tutti: è il minimo che devono fare da quando esistono le simd proprietarie) deve produrre dei moduli che traducano con istruzioni diverse (e tipicamente più generiche, a meno di saper fare la stessa cosa con istruzioni proprietarie equivalenti, ammesso che ce ne siano) i costrutti di alto livello del linguaggio usato. A runtime verrà identificata la macchina e si sceglierà cosa eseguire.

Grazie a xeal, bjt2 e Leone per il solito e gradito contributo tecnico.

Un pò di luce sull'argomento, al di fuori dei soliti toni da forum.

[M3thos]

mah... io quoto il primo intervento: ki usa 4 gpu???Secondo me con due 8800 gtx o gt in sli sei apposto per i prossimi mille anni!!! senza fare lo sborone con 4 schede ke neanke usi -.- per i gioki ke ci sono tutt'ora!

[Lunar Wolf]

certo ke i chipset della serie 7 sono favolosi. La AMD si dà da fare. Anke perke direi ke 4 skede grafike sn un po esagerate. Ne basterebbero soltanto 2 x ki vuole avere delle performance buone su una ris 1280x1024. Cmq meglio aspettare un nuovo chip della ATI e nn + la SB600.

[xeal]

@ bjt2

Allora è come pensavo: in pratica il bug (o meglio, il workaround) rende più probabile un accesso frequente alla ram per caricare la page table. Di per sè non è una penalizzazione critica (non quanto l'altro bug), però potrebbe influenzare negativamente l'ottimizzazione dei load/store, che si basa, se ho ben compreso questa caratteristica, su un approccio conservativo che prevede proprio il calcolo dell'indirizzo effettivo. Cioè, il processore ordina gli accessi in ram, privilegiando le letture, e per farlo calcola gli indirizzi effettivi prima di un burst di accessi mixati opportunamente; ma questo vuol dire che il processore calcolerà più indirizzi prima di ogni accesso, o meglio, calcolerà tutti quelli che gli servono, in base all'algoritmo implementato, e per farlo in fretta avrà bisogno di avere le page table in cache -> più indirizzi verranno calcolati contemporaneamente e, in conseguenza al (workaround per il) bug, può aumentare la frequenza degli accessi in ram a caccia dei dati mancanti, oppure (o comunque) un solo indirizzo mancante può rallentare il riordino e l'esecuzione del burst e le operazioni da esso dipendenti (specialmente dai load). Certo, non incide come il secondo, però in alcune circostanze può essere come non avere affatto l'ottimizzazione sugli accessi (o peggio, subire una penalizzazione maggiore che non avendola).

P.S. Era venuto anche a me il dubbio che il vero problema fossero le rese e/o il tdp, e che il bug (comunque presente, ma influente più sulle prestazioni che sulla stabilità) fosse una "scusa" per rinviare i modelli superiori. In ogni caso, speriamo che risolvano e in fretta, perchè i k10 avrebbero dovuto essere a posto giù da un pezzo...

[xeal]

@Crystal1988

è chiaro che l'utilizzo di diversi compiler porti ad una differente ottimizzazione

Be', certo, i compilatori sono scritti da programmtori, che sceglieranno strade diverse e riusciranno a fare alcune cose meglio di altre (e i compilatori, come tutti i programmi, vengono migliorati, ottimizzati e vanno aggiornati).

e cmq se i programmato usassero vari compiler potrebbero migliorare le prestazioni per processore e famiglia

Si, ma è un lavoraccio Così si arriva davvero ad una versione per ogni processore, con strade separate per il testing, le release e la manutenzione... a meno di sobbarcarsi un lavoraccio a basso livello per creare un selettore unico per i codepath e fondere i vari moduli in un unico eseguibile... in verità si potrebbero organizzare opportunamente i sorgenti per dare in pasto al singolo compiler dei moduli da linkare, senza produrre eseguibili/librerie completi, per poi darli in pasto ad un linker unico (modificato ad arte, e qui viene il brutto) per fondere insieme i vari moduli (e differenziarli quanto basta per renderli riconoscibili al selettore dei codepath, che comunque bisognerà scrivere, insomma, si migliora rispetto all'esempio di prima, ma non tanto).

L'ideale, da questo punto di vista, sarebbe avere un compiler modulare, con un front-end che si occupi di costruire l'eseguibile, creare i selettori in base al riconoscimento della cpu, eventualmente produrre i codepath generici, e linkare i moduli prodotti dai diversi back-end, cioè i compilatori scelti per produrre il codice specifico (che potrebbe limitarsi alle parti relativa a fpu/sse, ma in questo schema forse sarebbe più semplice produrre tutto il codice, con le conseguenze prevedibili sulle dimensioni del programma), che dovrebbero comportarsi come dei plug-in, cioè assolvere a particolari richieste e produrre moduli da linkare che rispondano alle convenzioni del front-end (e quindi, senza standardizzazione e supporto dai singoli compilatori, non si va da nessuna parte). Inoltre, il compilatore dovrebbe sapere cosa fare con le istruzioni non supportate (e qui viene il brutto: per fare un esempio stupido, gli Intel Compiler non supporteranno mai le 3DNow ), altrimenti bisogna risolvere a livello dei sorgenti (e torna ad essere un lavoraccio), a meno di avere dei supercompilatori megagalattici che sappiano prendere un codice ad alto livello che se ne frega delle estensioni specifiche, e lo compili traducendolo in istruzioni superotiimizzate per la macchina target (quindi introducendo le istruzioni estese quando e se necessario), ma non mi pare che ci siano ancora compilatori miracolosi, anche per una sola macchina. Se invece si cerca di privilegiare le istruzioni comuni, allora da un lato il compilatore scelto dovrà saper introdurre all'occorrenza quelle "mancanti" (torniamo al caso precedente), dall'altro la cpu deve saper eseguire bene quel codice così com'è. E così arriviamo al punto:

ma vuol dire semplicemente che, per i compiler più comuni, Amd ha sbagliato approcio.

E' proprio questo il problema, o meglio, se fosse così lo diventerebbe, e in maniera catastrofica, perchè se per sfruttare appieno un K10 bisogna attendersi una ricompilazione di tutti i programmi, anche solo con una versione aggiornata del proprio compilatore preferito (senza quindi cambiarlo), allora il progetto è nato morto... Considera che il più grande vantaggio di una cpu x86 (e quindi cisc) è la dipendenza bassissima dal grado di ottimizzazione del compilatore, perchè tutta la logica di gestione delle istruzioni (out-of-order, branch prediction, ma in un certo senso anche la decodifica in istruzioni interne risc-like, e la loro scelta in fase di progettazione), non fa altro che ottimizzare al volo il codice macchina prodotto dal compilatore.

Certo, se le istruzioni scelte a compile-time sono le più lente per una cpu, miracoli non se ne possono fare, però considera che i compilatori che "baravano" di più (nel senso che producevano volutamente codice ottimo, il migliore in circolazione, per cpu intel e mooolto meno valido per cpu amd - fino al punto di ignorare del tutto il supporto alle sse) sono gli Intel, che però costano molto e non sono diffusissimi; in generale, i compilatori più usati a livello commerciale produrranno codice con ottimizzazioni mediamente valide per tutte le cpu (ormai amd è abbastanza diffusa, specialmente in ambito server, per cui dubito che ci siano in circolazione molti compilatori che la "snobbano" ), quindi la singola cpu deve cavarsela con quelle (e in questo concordo in toto con leoneazzurro).

Ma io temo di più ottimizzazioni per k8 anche valide, prodotte da compilatori non aggiornati per il supporto ai k10 (quindi quelli usati per i vari bench disponibili ad oggi), e fatte girare su k10 senza sfruttarne le potenzialità in più rispetto ai k8: come dicevo in un post precedente, ormai l'implementazione delle sse (supportate) nei k10 è grossomodo equivalente a quella degli intel, quindi se un certo mix di istruzioni sse (supportate da amd) va bene per intel allora deve andar bene anche per amd. Avevo fatto l'esempio banale di istruzioni su vettori a 128bit spezzate in coppie di istruzioni su vettori a 64bit dal compilatore, in modo da essere già pronte per lo schema di esecuzione di un k8, che se eseguite allo stesso modo su un k10 non sfrutterebbero il raddoppio (teorico, massimo) delle prestazioni dell'unità sse. In questo senso, ricompilare con un compiler che sa che i k10 eseguono le istruzioni complete può aiutare, ma se così fosse indicherebbe un errore di valutazione da parte dei progettisti di amd (e anche un errore banale, per questo lo è l'esempio, cioè mi aspetto che questo non succeda), perchè vorrebbe dire che un k10 non è in grado di riconoscere e accorpare istruzioni uguali su vettori più piccoli, presumibilmente frutto di una compilazione/scelta operata a vantaggio di un k8.

Insomma, i risultati di spec con ricompilazione sono notevoli, ma auguriamoci che arrivino benefici maggiori dalla risoluzione dei bug. D'altra parte, se i problemi venissero risolti bene, scalabilità in primis, e il marketing di amd avesse successo, allora qualche produttore potrebbe pensare di creare una nuova versione semplicemente aggiornando il compilatore e ricompilando, spacciandola per una release che sfrutta le innovazioni dei k10; però avrebbe più senso se ci fossero vantaggi anche per le cpu intel, quindi è più probabile che avvenga in concomitanza con l'introduzione del supporto alle sse4 - sempre che i compilatori vengano aggiornati, e questo dipenderà da quanto amd dimostrerà di saper scalare e le prestazioni, risolvendo i bug, e la frequenza, affinando il processo produttivo.

[xeal]

@ Free Gordon

Ma figurati, siamo qui per questo

In fondo, abbiamo tutti imparato qualcosa sul forum, ci siamo tolti dei dubbi o fatti venire delle idee, arrivando ad un livello di comprensione che solo con la discussione si può raggiungere. Il forum serve a questo, il trucco è saper filtrare i thread e i commenti validi (e magari ogni tanto concedersi qualche battutina e qualche battibecco, ma senza esagerare)

[K7-500]

In effetti per la prima volta ho letto con piacere 10 pagine di commenti.

[Hyunkel01]

AMD + ATI siamo sempre sotto a INTEL + GEFORCE