Chipset AMD serie 7, la base dei sistemi Spider

[7stars]

quindi la cosa + interessante a mio avviso,cioè le prestazioni con 4 schede video usate in contemporanea, non si è potuta testare per mancanza dei drivers?? e ci fate guardare le foto delle schede collegate! e quindi!? e allora!? ma come fanno ad arrivare i prodotti e poi i drivers!? io non lo capisco...cioè le cose secondo loro funzionano a livello teorico ma non pratico!? ma cosa rilasciano a fare questi prodotti per fare test!?!? veramente io sono molto confuso su questa metodologia...alquanto anomala direi ma assolutamente non è una critica alla redazione...qui il problema è alla fonte purtroppo
scusate allora quando entrano in commercio chipset e schede madri? inizio 2008??

[xeal]

@ Paolo Corsini

Ho iniziato poco fa i test; ho in previsione almeno un paio di articoli uno incentrato sul processore nudo e crudo e il secondo sulla piattaforma Spider confrontata a parità di prezzo con un'alternativa Intel.

Immagino farete anche una bella analisi comparata tra le modalita ganged e unganged del MCH per i diversi scenari applicativi Azz, un bel po' di lavoro

Sarà interessante vedere (al di là dei bug) se la modalità unganged da vantaggi con applicazioni multithread e in che misura (comunque, l'implementazione attuale non mi ispira troppo, l'avrei preferita un po' diversa, ma forse quello che ho in mente io potrebbe creare parecchi grattacapi al livello delle piste e dei segnali, quindi accontentiamoci).



@ capitan_crasy

Azz, il problema coi bug è più serio di quanto pensassi... Sul momento avevo ipotizzato un qualche clock skew mal "calcolato" che al di sopra di certe frequenze faceva saltare la sincronia in alcuni scenari di calcolo. Però, dal punto di vista delle prestazioni, forse è meglio così (fermo restando la magrissima figura di amd)



@ Mikelezz

AM2+ vs 939: potresti aver ragione, però il problema dovrebbe essere minore, visto che le cpu AM3 saranno compatibili con le MB AM2+, almeno finchè i produttori si degneranno di aggiornare i bios (ma almeno non si dovrà degnare anche amd di produrre cpu differenti per socket differenti, e date le dimensioni del produttore in questione, così le possibilità di upgrade parziale saranno teoricamente più dilatate nel tempo). Inoltre, direi che lo stesso quesito possono porselo, OGGI, gli acquirenti di un nuovo sistema Intel, visto che l'introduzione di Nehalem (con il MCH integrato, e quindi giocoforza incompatibile con le MB di adesso) avverrà in un lasso di tempo confrontabile con l'arrivo di AM3. Naturalmente, in entrambi i casi non ha senso per chi non fa upgrade parziali, ma aspetta un po' di più e cambia tutto il sistema.

Discorso prestazioni "post-bug" vs prestazioni da cache: occhio che i sistemi AMD (in questo k8 e k10 dovrebbero assomigliarsi decisamente) tendono ad essere più sensibili, per scelte architetturali (tra cui proprio il memory controller integrato) alla banda e alla latenza della ram che alla dimensione della cache, e quei due bug, nel complesso, non fanno altro che "complicare", ovvero rallentare, lo scambio di dati tra ram e cpu. Inoltre, il commento di leoneazzurro fa riferimento a una impostazione dei timing, utilizzata nei test dei Phenom, che da sola basterebbe (con un k8) a ridurre le prestazioni di un 5%... Cosa cambierà con il B3, naturalmente, resta tutto da dimostrare.



@ 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

[gr@z!]

[OT]

Paoloo mi trovo negli states e ci restero' ad libitum (ho un visto H di lavoro qui)..

Lo vuoi un benedetto Phenom 9500 e lo testi per bene????

[/OT]

Non vedo l'ora che si testi per bene la piattaforma Spider cosi' comee' stata concepita dalla signora AMD.

Ottimo lavoro Paolo, come sempre. Grazie per la professionalita'.

PS:
Sono davvero a Los Angeles. Se hai bisogno chiedi

Ciauu

[xeal]

Dimenticavo:

Originariamente inviato da Crystal1988

Il discorso delle SSE4 e 4a è un discorso a parte che esula dalla compilazione ma riguarda le istruzioni vere e proprie ed il codice sorgente.

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.

Originariamente inviato da K7-500

Con incrementi mica da ridere, se si può ottenere un risultato simile tra un po' avremmo Adobe CS4 Intel/Amd edition...

Vedi sopra: in un certo senso è già così, solo che le versioni diverse convivono nello stesso eseguibile, e differiscono per alcune porzioni specifiche di codice

[bjt2]

Originariamente inviato da xeal

CUT
Vedi sopra: in un certo senso è già così, solo che le versioni diverse convivono nello stesso eseguibile, e differiscono per alcune porzioni specifiche di codice

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...

[manga81]

Originariamente inviato da MiKeLezZ

L'articolo è interessante, le piattaforme un po' meno.
In generale si respira aria di "già visto, nulla di esaltante", tipica anche dei Phenom.
D'altronde l'unica vera differenza è data da 790 rispetto al 580, datosi il southbridge resta il SB600.
Mi aspettavo una seppur minima riduzione di consumi, ma evidentemente le eventuali migliorie nel risparmio energetico sono poi state controbilanciate da più componentistica attiva nel chipset.
Unica cosa degna di nota è l'utility Overdrive, davvero ben fatta (entro sé racchiude almeno 3 programmi distinti). Ma, quasi a monito del fatto che AMD non possa fare ciambelle con il buco in mezzo, ecco che manca la compatibilità con il S.O. attualmente più diffuso sulla faccia della terra: XP (/2K) ...
Nelle ultime pagine c'è poi un simpatico confronto Sandra 2008 vs Everest, chi aveva poi ragione? Io credo Sandra...?

Lascio infine uno spunto di discussione: AM2+ come 939? Ovvero la vera piattaforma di riferimento sarà poi AM3, con DDR3...?
Ocio alla tranvata...

p.s. No Comment sui fantomatici bug, ormai non si sa più a cosa attaccarsi. Anzi, un comment lo faccio: aspettarsi, dalla soluzione di quei problemi, prestazioni maggiori di un 3% sarebbe già un pseudo-miracolo... certi incrementi neppure li ottieni raddoppiando la grandezza della cache, figuriamoci dalla correzione di un bug minore.

Originariamente inviato da MiKeLezZ

Mi vorrai scusare se prenderò quei dati con le pinze, e preferisca anzi affidarmi a test condotti su applicativi di comune uso?
La cosa che più mi ha colpito è infatti questa sezione delle recensione di Tom's:
http://www.tomshw.it/cpu.php?guide=2...0_9600_9700-20
Dove si afferma come il Phenom 9700 (2,4GHz) è indietro rispetto al Q6600 (anch'esso 2,4GHz) del 10%, e questo non tiene conto del fatto che il 9700 esista solo sulla carta (mentre il Q6600 è l'entry-level dei Quad-Core), che Phenom sembra non superare i 3GHz (mentre per i Core 2 Duo si arriva anche a 3,6GHz), ma soprattutto che, come è stato detto, i Penryn offriranno il 5% (in media) di prestazioni in più rispetto i corrispettivi attuali... E quindi la forbice è destinata ad aumentare del 15% a vantaggio di Intel (sempre clock to clock, e sempre dimenticando che i Penryn potranno arrivare anche a 4GHz).
Certo non riesco a sperare in correzioni di bug che donino il 15% di prestazioni in più e permettano clock di 3GHz (neppure possibili con CPU meno sosfisticate e più rodate come gli attuali Athlon X2).
Sarò pessimista?

amd mi ha profondamente deluso...io pensavo di fare un htpc con i nuovi phenom e nuovi chipset video integrati...

la realtà è che i nuovi phenom consumano di + e vanno + lenti del vecchio quadcore intel e vengono venduti allo stesso prezzo...

prendere am2+ potrebbe essere una sola...temo un veloce cambio in am3...

ma anche prendere intel in vista di upgrade sarà una sola...dal 2009 si cambia chipset...



NON COMPRATE NULLA!

[xeal]

Non ho capito bene quello che intendi (soprattutto, se ti riferivi a me o se ti riallacciavi al mio discorso... io pessimista non sono, o almeno provo a non esserlo )

Insomma, ste benedette ottimizzazioni specifiche c'erano oppure no?

[bjt2]

Originariamente inviato da xeal

Non ho capito bene quello che intendi (soprattutto, se ti riferivi a me o se ti riallacciavi al mio discorso... io pessimista non sono, o almeno provo a non esserlo )

Insomma, ste benedette ottimizzazioni specifiche c'erano oppure no?

Confermavo quello da te detto. Se un compilatore come il Borland riesce a compilare una libreria in 64 KB e quello MS in 480KB, vuol dire che in quello MS c'è più codice. Immagino che tutti i più recenti compilatori facciano così. Almeno per le piattaforme windows: è chiaro che per Linux in genere si hanno i sorgenti e quindi se si vuole si ricompila per l'architettura specifica, ma per windows dove in genere c'è SW chiuso (e MS non può non supportare SW chiuso) se si vuole velocità ci vogliono per forza code path multipli e automatizzati dal compilatore (sono pochi quelli che scrivono assembler a mano...)

Per rispondere alla tua domanda: non so se c'erano ottimizzazioni, non ho benchato, ma la dimensione del file fa supporre di si...

[xeal]

Ok, adesso mi sono capito

Ma vale anche per linux, per tutte le distro e i pacchetti forniti in binario nei veri repository (poi, chiaramente, chi vuole compila tutto, però, oltre al kernel non so quanto convenga, a meno di avere la pazienza, in molti casi, di eliminare a mano l'installazione precedente e compilare l'ultima versione scaricata del programma, configurando a mano dove necessario e controllando le dipendenze - insomma, un bel rpm, quando c'è, fa bene al cuore ) ma mi sa che così finiamo un po' OT

[Paolo Corsini]

Originariamente inviato da gr@z!

[OT]

Paoloo mi trovo negli states e ci restero' ad libitum (ho un visto H di lavoro qui)..

Lo vuoi un benedetto Phenom 9500 e lo testi per bene????

[/OT]

Non vedo l'ora che si testi per bene la piattaforma Spider cosi' comee' stata concepita dalla signora AMD.

Ottimo lavoro Paolo, come sempre. Grazie per la professionalita'.

PS:
Sono davvero a Los Angeles. Se hai bisogno chiedi

Grazie, ma ho un engineering sample qui e un Phenom 9500 retail

[Paolo Corsini]

Grazie a tutti per i contributi interessanti; sto valutando alcune nuove aggiunte all'analisi comparativa tra le architetture.
Cerco di approfondire con AMD direttamente anche la questione dei due bug evidenziati.

[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?

[xeal]

In questo senso, le cpu affette si comporterebbero, dal punto di vista delle prestazioni, come un k8 con la penalizzazione (lieve) del bug (ovviamente il paragone è limitato ai benefici introdotti dal solo riordino di letture e scritture).

[leoneazzurro]

Originariamente inviato da Errik89

il raddoppio della cache CON ARCHITETTURA INTEL da vantaggi che vanno dal 3% fino anche al 10% (nella media un 5% considerando conroe 4mb vs penryn 6mb e quindi nemmeno un raddoppio), su architettura AMD potrebbero esserci ancora più vantaggi, e considerando che l'architettura K10 si basa proprio sulla cache L3, se questa è "azzoppata" è ovvio che le prestazioni generali ne risentono e nemmeno poco (la prova può essere proprio il bandwith della memoria bassissimo, sintomo di un altro errore di gestione del controller della memoria). Quindi come già detto da bjt2 e da leoneazzurro possiamo aspettarci un incremento di prestazioni nella media dal 5% fino al 10% (cioè dovrebbero pareggiare conroe).

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.

Originariamente inviato da capitan_crasy

non vi è dubbio che AMD abbia fatto una magra figura!
Dopo quasi un anno e mezzo di sviluppo è riuscita a produrre 3 step K10 e nessuno realmente funzionante.
Non vi è dubbio però che l'attuale step B2 abbia un bug non dichiarato ma perfettamente documentabile che in pratica penalizza le prestazioni e credo che il parere di persone come bjt2 e leoneazzurro sia più che una conferma...
Se poi anche lo step B3 non va come dovrebbe allora avrai altro materiale per la tua firma...

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.

Originariamente inviato da Crystal1988

esattamente. è inespressa.

Andrebbero ricompilati tutti gli applicativi con il miglior compiler, più adatto all'architettura K10. il compiler in questione non è di AMD e sono molteplici: nell'esempio sono PGI e PathScale mentre per intel è un compiler Intel.

Questi test sono effettuati usando i compiler migliori per ogni architettura, cioè il compiler migliore per Intel nel caso di Xeon, i migliori compiler per AMD nel caso di Opteron. Come vedi il confronto è fatto tramite i migliori compiler, non uno solo.

è la prima volta che senti questa giustificazione per il semplice motivo che prima non c'erano problemi di questo tipo. Ora invece come mai il phenom che ha potenza DOPPIA in FP rispetto al K8 va solo un 10 o 20 % o adirittura 2 o 3 % in applicazioni FP ?? è strano no?? e qui guardacaso c'è la soluzione all'enigma.

Ma non credere che sia solo colpa dei compiler usati.. nel senso.. l'archiettura COre è da un pezzo che è fuori, è chiaro che le compilazioni comuni sono effettuate per quell'architettura che è più presente (Intel).. qui AMD paga il proprio ritardo... Inoltre AMD avrebbe dovuto utilizzare set d'istruzioni diversi e strutture diverse per sopperire a questo problema... ma avrebbe forse anche dovuto stravolgere completamente l'architettura.

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.

[F1R3BL4D3]

Originariamente inviato da Paolo Corsini

Grazie a tutti per i contributi interessanti; sto valutando alcune nuove aggiunte all'analisi comparativa tra le architetture.
Cerco di approfondire con AMD direttamente anche la questione dei due bug evidenziati.

Ottima notizia questa! Sarà interessante la comparativa fra architetture (un lavoraccio fra l'altro).

[xeal]

Originariamente inviato da Paolo Corsini

Cerco di approfondire con AMD direttamente anche la questione dei due bug evidenziati.

Mi sa che saranno un po' restii a rispondere, perchè se le nostre valutazioni sono corrette, si tratta si di bug, che però non hanno influenza negativa (applicando i workaround) sulla stabilità del sistema o sulla correttezza delle operazioni, ma impattano principalmente sulle prestazioni, quindi fare troppa pubblicità ai problemi attuali come bug, ovvero malfunzionamenti, potrebbe influenzare in qualche modo le vendite nel periodo natalizio. Se poi lo step B3 dovesse portare un aumento di prestazioni, lo faranno passare come il frutto di affinamenti architetturali (che è un modo elegante di rigirare la frittata, ma non una gran bugia, perchè nell'implementazione attuale, con bug + workaround, si hanno dei problemi "solo" prestazionali, e la risoluzione dei bug sarà un miglioramento dell'architettura con benefici prestazionali - da quantificare). Però, visto che i documenti ufficiali citano i problemi, e visto che "qualcuno" vuole chiarire, è anche nel loro interesse aiutare a chiarire la situazione, per inquadrarla nella giusta prospettiva, evitando equivoci, fraintendimenti o esagerazioni... Insomma, chiedi, chiedi... torchia, torchia...

[licarus]

Quello che sembra frenare una massiccia adozione sul mercato della piattaforma Spider, e quindi anche dei chipset AMD serie 7, sono le prestazioni velocistiche delle cpu Phenom: un debutto a 2,3 GHz di clock massimo ha sicuramente deluso tutti gli appassionati

Questo mi sembra il succo della questione: il chipset può essere interessante però mancano il processore e la scheda grafica di fascia alta da abbinare: qui al momento AMD non ha molto da offrire. Il fatto di aver inserito l'utility per l'overclock fa ben sperare che AMD non abbia abbandonato il pubblico enthusiast, perciò io mi aspetto (o spero a questo punto ) dei prodotti top di gamma competitivi per l'anno prossimo (se probabilmente è vero che AMD ha preferito partire dalla fascia media che porta più mercato, bisogna però anche dire che la fascia alta porta tanta pubblicità quindi non può abbandonare questo segmento...).
Certo poi bisognerà vedere i bench, ma soprattutto se non pagherà troppo questo ritardo rispetto ad Intel.

[ThePunisher]

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

[xeal]

In alcune configurazioni con scheda pcie 2.0, cpu am2+ e hypertransport 3.0, rispetto alle gpu pcie 1 e versioni precedenti di htt; presumibilmente il quantitativo di memoria sulla vga che da luogo ai risultati indicati non è elevato. Nell'articolo si contestualizza chiaramente la validità delle dichiarazioni .

[schwalbe]

Originariamente inviato da Crystal1988

Inoltre non ho detto che vengono usati solo i compilatori Intel, ma che in generale, per le applicazioni che compriamo, vengono usati compilatori che non piacciono molto ai Phenom.

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

Originariamente inviato da bjt2

Confermavo quello da te detto. Se un compilatore come il Borland riesce a compilare una libreria in 64 KB e quello MS in 480KB, vuol dire che in quello MS c'è più codice. Immagino che tutti i più recenti compilatori facciano così. Almeno per le piattaforme windows: è chiaro che per Linux in genere si hanno i sorgenti e quindi se si vuole si ricompila per l'architettura specifica, ma per windows dove in genere c'è SW chiuso (e MS non può non supportare SW chiuso) se si vuole velocità ci vogliono per forza code path multipli e automatizzati dal compilatore (sono pochi quelli che scrivono assembler a mano...)

Per rispondere alla tua domanda: non so se c'erano ottimizzazioni, non ho benchato, ma la dimensione del file fa supporre di si...

È 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.