Link all'Articolo: http://www.hwupgrade.it/articoli/skmadri/1850/chipset-amd-serie-7-la-base-dei-sistemi-spider_index.html

Alla base della piattaforma Spider, come vero e proprio punto d'incontro tra processore e scheda video, i chipset AMD della serie 7 vengono proposti per differenti segmenti di mercato, introducendo tra le varie la tecnologia CrossfireX per avere sino a 4 GPU in parallelo.

Click sul link per visualizzare l'articolo.

un sistema così è solo per sboroni:rolleyes: uno che se ne fà di 4 schede video? già 2 in sli sono inutili bah

paolo, ma come mai in un'articolo noinato:
"Chipset AMD serie 7, la base dei sistemi Spider"
non viene neanche preso in considerazione il chipset rs780 (780G) che sara' la VERA piattaforma SPIDER per desktop e Laptop de gennaio in poi???

come errore mi sembra abbastanza grossolano non averne parlato... non credi?

paolo, ma come mai in un'articolo noinato:
"Chipset AMD serie 7, la base dei sistemi Spider"
non viene neanche preso in considerazione il chipset rs780 (780G) che sara' la VERA piattaforma SPIDER per desktop e Laptop de gennaio in poi???

come errore mi sembra abbastanza grossolano non averne parlato... non credi?
Ciao,

premesso che, qualora avessi ragione, si tratterebbe di dimenticanza e non di errore, ti spiego perché quel chipset non è stato menzionato in questo articolo:

1) si parla delle piattaforme presentate da AMD, e il chipset 780G non lo è stato; AMD ha detto che verrà presentato nel mese di Febbraio, non a Gennaio, senza fornire dettagli su quelle che saranno le caratteristiche tecniche se non che integrerà UVD e chip video DX10.

2) quel chipset, stando alle mie informazioni, NON entrerà all'interno del pacchetto di piattaforme Spider. Spider è una piattaforma per enthusiast, mentre un chipset con video integrato va necessariamente verso altre tipologie di sistemi in primis i commercial business.


Del chipset 780G, in ogni caso, avevo già parlato a Maggio in questo articolo:
http://www.hwupgrade.it/articoli/cpu/1727/piattaforme-mobile-amd-per-il-2008-griffin-e-puma_5.html
è una piattaforma sicuramente interessante in ambito desktop, ma che trova la propria applicazione più efficace in ambiente notebook. Di questa famiglia AMD immetterà due versioni:
- RS780: per sistemi desktop
- RS780M: per sistemi notebook
Per entrambi il nome sarà 780G, e onestamente non mi aspetto differenze architetturali se non al limite una gestione più sofisticata, nel chipset mobile, del bilanciamento tra GPU integrata e GPU discreta quando presente nel sistema in funzione del tipo di alimentazione.

paolo, ma come mai in un'articolo noinato:
"Chipset AMD serie 7, la base dei sistemi Spider"
non viene neanche preso in considerazione il chipset rs780 (780G) che sara' la VERA piattaforma SPIDER per desktop e Laptop de gennaio in poi???

come errore mi sembra abbastanza grossolano non averne parlato... non credi?

ti sbagli, la piattaforma "Spider" è composta dai chipset 790FX, 790X e 770.
La piattaforma con il 780G si chiamerà "Cartwheel"...

scusa paolo :)

pero' e' piu' bello dai :D :D :D :D ;)

Ehm Bellissimo articolo , con unico appunto riguardante i prezzi del 790-770.

Veramente si trovano (su qualche shop tedesco) schede con 790x della MSI già a partire dagli 89 € ed a 80 € (direttamente in Italia) Le schede (asus e asustek) con il 770

Ehm Bellissimo articolo , con unico appunto riguardante i prezzi del 790-770.

Veramente si trovano (su qualche shop tedesco) schede con 790x della MSI già a partire dagli 89 € ed a 80 € (direttamente in Italia) Le schede (asus e asustek) con il 770
Quelli riportati sono i prezzi suggeriti da AMD; ben venga che i prezzi delle schede madri siano inferiori, in quanto almeno per il momento i prezzi delle cpu Phenom sono ben superiori a quanto indicato da AMD.

@Corsini

Mi chiedevo se sia un buon metodo di misura dei consumi utilizzare alimentatori così sovradimensionati. Non si rischia di andare ad utilizzarli in uno scenario di carico molto inferiore al range di massima efficienza ottenendo quindi risultati sballati con una misura alla presa?
Ciao,
in parte hai ragione; d'altro canto, il range di errore è di fatto unificato tra le varie piattaforme quindi considerando che l'unico elemento di differenza è dato dalla scheda madre l'incidenza è complessivamente ridotta.
Diverso sarebbe stato se avessimo confrontato consumo di sistemi con forti differenze sia dal lato cpu che da quello delle schede video: in quel caso la variazione sarebbe stata ben più consistente, con possibili margini di errore dovuti all'efficienza non lineare degli alimentatori.

Ottimo articolo,come sempre del resto

Non so perchè,ma leggendo quelle pagine traspirava una certa speranza sul successo di queste piattaforme,la stessa che ho io :sofico:

Ottimo articolo :)

Bellissimo il layout della MSI, pulito ed ordinato :).

Un problema dell'AFR dei sistemi SLi /Crossfire è che ogni scheda, pur renderizzando il "proprio" frame", deve in ogni caso mappare per intero la memoria video.
512Mb li vedo piuttosto limitanti laddove siano richieste 2-3 o 4 schede video.
Sarà anche vero che Pci-e 2.0 + HT 3.0 possono essere d'aiuto laddove finisce la memoria video (anche se 10 e 20% è ben poca cosa, a pensarci bene), ma parliamo anche di dover "servire" più di una scheda video.
Anche a 1680x1050 - 4AA - 16AF (direi veramente la risoluzione minima per sistemi a 2 o più schede video), molti giochi usciti negli ultimi 6 mesi, superano i 512Mb.
Vero anche i giochi oggi sono molto più limitati dalla potenza degli shaders che dal memory bandwidth, ma i 256bit potrebbero essere anch'essi un problema, quando si parla di 3 o 4 schede video.

Qualche "enthusiast" si farà attirare da sistemi di questo genere, è indubbio, ma io aspetterei di vedere le prestazioni concrete di tutta questa "baracca" :-)

mmmmmmm ho appena guardato per bene la recensione e l'overdrive è proprio na gran figata!!!! però non capisco come mai la recensione è stata fatta cn una sola scheda video:mbe:

una sostanziale limitatezza di funzioni del south bridge SB600: ... in particolare con riferimento al numero di periferiche SATA che vengono supportate contemporaneamente. E' vero che la maggior parte degli utenti non utilizza più di 2 o 3 hard disk

È un bel limite, però, considerando che non conviene più comprare periferiche ottiche Eide (questo è l'ultimo chipset a supportarne 2, dal prossimo 0)...
Do per scontato che quelle del SB600 abbiano il supporto Serial Atapi, visto che il Promise T3 è specificato "only storage".

Il Phenom lo state testando con questa scheda, vero? :D

Ma quando i test dei phenom??

Scusate, ma mi sembra abbastanza clamoroso che non abbiate ancora pubblicato una recensione dei nuovi processorei AMD.

La piattaforma è interessante, l'SB600 però non mi convince completamente. Ci vorrebbe un southbridge con buone prestazioni RAID in un sistema "Enthusiast".

Il Phenom lo state testando con questa scheda, vero? :D
Al momento no; ho in test in questo momento due processori Phenom e due schede madri, Sapphire e Gigabyte

Ma quando i test dei phenom??

Scusate, ma mi sembra abbastanza clamoroso che non abbiate ancora pubblicato una recensione dei nuovi processorei AMD.
E' stato spiegato in un articolo pubblicato settimana scorsa che AMD non ha campionato la stampa con processori prima del lancio, ecco perché non ne abbiamo pubblicato una recensione. C'è chi traduce lavoro di altri e pubblica, noi lavoriamo con i prodotti che abbiamo a disposizione cercando di fare analisi sulle quali mettiamo la nostra firma: modi di lavorare differenti, ma quantomeno penso di avere la serenità di poter dire di sapere quello che scrivo quando parlo di un prodotto.

No problem per avere schede madri e schede video per sistemi Spider prima del lancio, ma con il processore l'unica soluzione per noi era quella di attenderne la commercializzazione. Venerdì i primi processori sono stati spediti dai distributori, giusto mezz'ora fa abbiamo ricevuto un Phenom 9500 regolarmente acquistato.
Contemporaneamente AMD ha voluto supportarci mandandoci, dietro non poche insistenze (e grazie anche l'aiuto di persone molto in gamba all'interno di AMD, che abbiamo stressato a non finire con le nostre richieste) un sistema Spider con processore Phenom.

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. Ci vorranno un po' di giorni, ma penso ne varrà la pena.

giusto mezz'ora fa abbiamo ricevuto un Phenom 9500 regolarmente acquistato.

Ottimo. Anche le schede madri sono identiche a quanto si può trovare in giro? Non sono pre-sample o come simili? Perchè è interessante, visto che si parla sempre di bios non aggiornati, vedere cosa effettivamente uno può comprarsi.

parole parole parole...

quando escono i phenom?
quanto adranno?

da un pezzo a questa parte, AMD parla e Intel fa i fatti.

parole parole parole...

quando escono i phenom?
quanto adranno?

da un pezzo a questa parte, AMD parla e Intel fa i fatti.

disponibili da qualche giormo e ovviamente si conoscono anche le prestazioni

http://www.hwupgrade.it/forum/showthread.php?t=1606158

Ottima Recensione!

@Paolo Corsini:

vorrei sapere 3 cose:
1) hai intenzione di fare una recensione anche con un quad crossfire?
2) hai intenzione di fare una recensione con lo step B3 dei phenom visto quello detto da amd, sul bost prestazionale e sulla risoluzione dei bug (nn che sull'aumento di frequenza)? (immagino di si, ma vorrei avere una tua conferma)
3) vista l'immaturità delle bios come ti comporti? (magari hai già bios aggirnati?)

Grazie

Ma.... il dissipatore della CPU nella foto con le 4 schede video non è montato al contrario??..... Oppure ha la ventola che spinge cmq verso l'esterno? :confused:

Ottima Recensione!

@Paolo Corsini:

vorrei sapere 3 cose:
1) hai intenzione di fare una recensione anche con un quad crossfire?
2) hai intenzione di fare una recensione con lo step B3 dei phenom visto quello detto da amd, sul bost prestazionale e sulla risoluzione dei bug (nn che sull'aumento di frequenza)? (immagino di si, ma vorrei avere una tua conferma)
3) vista l'immaturità delle bios come ti comporti? (magari hai già bios aggirnati?)

Grazie

Ciao,

1) si, non appena saranno disponibili i driver; presumo a Gennaio, non prima
2) ovviamente si, non appena sarà disponibile. Anche qui prevedo non prima di Gennaio. B3 risolverà il bug e dovrebbe permettere di incrementare la frequenza di clock, ma architetturalmente non dovrebbero esserci novità di alcun tipo in termini di superiore IPC
3) testo e cerco di capire se ci sono problemi di stabilità operativa evidenti o meno

noi lavoriamo con i prodotti che abbiamo a disposizione cercando di fare analisi sulle quali mettiamo la nostra firma: modi di lavorare differenti, ma quantomeno penso di avere la serenità di poter dire di sapere quello che scrivo quando parlo di un prodotto.

------------------------------------------------------------------------

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. Ci vorranno un po' di giorni, ma penso ne varrà la pena.


Se fossi donna ti sposerei :sofico:

Ciao,


2) ovviamente si, non appena sarà disponibile. Anche qui prevedo non prima di Gennaio. B3 risolverà il bug e dovrebbe permettere di incrementare la frequenza di clock, ma architetturalmente non dovrebbero esserci novità di alcun tipo in termini di superiore IPC


Ciao Paolo:
Su questa questione voglio aggiungere una cosa molto importante:

Preso dal Thread ufficiale del K10 Phenom ( Clicca qui ) (http://www.hwupgrade.it/forum/showpost.php?p=19703307&postcount=6)

AMD ha ritirato dalla vendita pochi ore prima della presentazione ufficiale la CPU Phenom 9700 da 2,4 GHz per causa di un bug non risolvibile con un update del bios a motivo dell'impatto prestazionale che questo potrebbe portare.
Il bug si presenta solo con cpu a 2,4 GHz di clock e in particolari scenari di utilizzo del processore con tutti e 4 i Core pienamente funzionanti al 100%
La conseguenza, per AMD, è stata quella di posticipare il lancio di questa cpu nel momento in cui verrà resa disponibile la revision B3 del processore, in grado di supportare il funzionamento a queste frequenze di clock e di risolvere il bug. Con la revision B3 del processore, inoltre, AMD dovrebbe avere importanti margini d'incremento della frequenza di clock sino alla soglia di 3 GHz.
Attraverso la pubblicazione di questo documento (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41322.pdf) si possono avere più dettagli tecnici sul problema dello step B2.
Grazie all' aiuto di bjt2, la quale è stato così gentile nel paragonare questo documento con il "BIOS and Kernel Developer's Guide for AMD" ( Clicca qui (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf) ) uscito qualche mese fa, si è scoperto che l'attuale K10 Phenom B2 soffre di un altro e più preoccupante Bug:
Ecco i problemi nel dettaglio:



I due bug sono i seguenti:

Primo BUG:

Sintomo:
Possibile blocco del sistema sotto alto carico, dovuto a cache miss nella cache TLB.

Soluzione temporanea di AMD:
Disabilitare il caching della page table nella cache normale.

Conseguenze:
Su un cache miss nelle TLB deve necessariamente accedere in RAM. Nessuna possibilità di trovare il dato in cache normale. Penalizzazione prestazionale modesta, ma consistente per alti carichi o processi che occupano molta memoria.

Secondo BUG:

Sintomo:
Possibile corruzione dei dati su scrittura parziale (ossia scrittura in memoria di linee di cache parzialmente riempite)

Soluzione temporanea di AMD:
Disabilitare questa funzione. Per scrivere anche un solo byte, la CPU deve prima leggere tutta la linea di cache, unire i dati e riscrivere tutta la linea di cache

Conseguenze:
Maggior carico sulla memoria e grosse perdite di prestazioni, mitigate dal fatto che il Write Combining non sembra disattivato e quindi più scritture piccole possono essere combinate, ma se ci sono molte scritture in coda, può essere forzata una scrittura parziale prima di completare il buffer e allora si avrà scarsa efficienza.



Il BUG più terribile è il secondo, sia perchè il primo, come segnalato da leoneazzurro, non dovrebbe essere presente in CPU sotto 2.4GHz (anche se il documento AMD non specifica una determinata frequenza), sia perchè le prestazioni calerebbero di poco e solo per alto traffico RAM.

Ecco l'opinione di leoneazzurro


Ci sono sicuramente dei margini. Occhio che però il bug del TLB non dovrebbe apparire sui Phanom inferiori a 2.4 GHz, per cui alla fine su questo punto non credo si possa recuperare molto. L'altro bug è decisamente più pesante, e sinceramente credo penalizzi fortemente le prestazioni. C'è da dire inoltre che in molte delle recensioni che ho visto viene usato un timing penalizzante (wait state 2 anzichè 1) e questo in una CPU K8 portava via un 5% buono di prestazioni, su Phenom non so quanto in realtà incida, ma è sicuramente indice di una piattaforma ancora acerba. Purtroppo a quest'ora acerba non doveva esserlo.

Un grazie a leoneazzurro e bjt2 !

Tu che ne pensi di questo secondo Bug?

Ciao,

1) si, non appena saranno disponibili i driver; presumo a Gennaio, non prima
2) ovviamente si, non appena sarà disponibile. Anche qui prevedo non prima di Gennaio. B3 risolverà il bug e dovrebbe permettere di incrementare la frequenza di clock, ma architetturalmente non dovrebbero esserci novità di alcun tipo in termini di superiore IPC
3) testo e cerco di capire se ci sono problemi di stabilità operativa evidenti o meno

Sei sempre gentilissimo
Grazie

;)

x Paolo Corsini

nella recensione per favore tenete anche conto di tutto questo:

Sarebbe il caso di approfondire il fatto che i Phenom non si riescono a overcloccare decentemente a causa del moltiplicatore che il northbridge applica all'HTT:muro: :cry: :cry:

quindi se ho capito bene, è la velocità del northbridge che dà fastidio!!!

stanno provando ad aggirare il blocco modificanfo valori del bios con WPCREDIT, in particolare il moltiplicatore del northbridge.... sviluppi in tempo reale...

posto di nuovo il thread su xtremesystems cosicchè possiate seguirlo anche voi da vicino(magari conoscete l'inglese meglio di me)in modo da tenere aggiornata la situazione (in italiano)anche in questo thread:
http://www.xtremesystems.org/forums/showthread.php?t=166792&page=5

speriamo bene:mc: :mc:

Ciao,

1) si, non appena saranno disponibili i driver; presumo a Gennaio, non prima
2) ovviamente si, non appena sarà disponibile. Anche qui prevedo non prima di Gennaio. B3 risolverà il bug e dovrebbe permettere di incrementare la frequenza di clock, ma architetturalmente non dovrebbero esserci novità di alcun tipo in termini di superiore IPC
3) testo e cerco di capire se ci sono problemi di stabilità operativa evidenti o meno

Non per creare casino, ma credo che sul secondo punto ci sia da riparlarne... i 2 Bug in questione sono molto influenti... perché quello meno pesante influisce abbastanza sulle prestazioni in quei casi di alto carico delle memorie.. mentre il secondo impone anche per la scrittura di pochi bytes, la completa lettura e riscrittura della cache... e questo va ad appesantire la ram e rallenta molto le operazioni, soprattutto se vi sono molte operazioni piccole in serie.. magari non influenza direttamente l'IPC ma sicuramente le prestazioni in generale...

Qui il link al 3D dove abbiamo valutato la questione dei BUG dal punto di vista tecnico e prestazionale...

http://www.hwupgrade.it/forum/showthread.php?t=1606158

Inoltre volevo dare un'idea: perché non fate dei test tipo quelli di SPEC.org confrontando le prestazioni da Compiler a Compiler?? perché o notato che ricompilando i programmi per K10, questo migliora tantissimo..

IMHO niente a che vedera con soluzioni concorrenti Intel ma tutto sommato mi pare una soluzione valida,il software AMD overdrive é una bomba.

Beh... guarda... almeno a livello di fascia media... e entry level (guarda caso dove si guadagna di più...) le schede video nuove e le mobo con questi nuovi chiepsets sono dei portenti... le schede video vendono parecchio.. e stranamente le mobo (alle quali manca ancora l'SB700 per completare il tutto) oltre a consumare poco sono anche economiche... difatti stiamo mediamente a 50€ al di sotto dai prezzi teorici... Inoltre il Phenom deve ancora assestarsi come prezzo... ed il nuovo StepB3 dovrebbe dare miglioramenti prestazionali di rilievo... tuttavia non raggiungerà Intel (secondo me più per motivi di compilazione)

Direi cip economico ma nei risultati si spera che con le nuove cpu mostri ciò che amd dichiara sulla carta senò se resta così comè con nuovi bench.. è solo un pò di fumo spacciato per polvere d'oro

Ripeto... fate un confronto delle cpu su Spec.org... oppure guardate il post che ho messo qui http://www.hwupgrade.it/forum/showpost.php?p=19772559&postcount=825 ... guardate bene il confronto e capirete che qui la situazione è ben più complicata di un semplice discorso di architettura buona o cattiva...

Beh... guarda... almeno a livello di fascia media... e entry level (guarda caso dove si guadagna di più...) le schede video nuove e le mobo con questi nuovi chiepsets sono dei portenti... le schede video vendono parecchio.. e stranamente le mobo (alle quali manca ancora l'SB700 per completare il tutto) oltre a consumare poco sono anche economiche... difatti stiamo mediamente a 50€ al di sotto dai prezzi teorici... Inoltre il Phenom deve ancora assestarsi come prezzo... ed il nuovo StepB3 dovrebbe dare miglioramenti prestazionali di rilievo... tuttavia non raggiungerà Intel (secondo me più per motivi di compilazione)

è verissimo quello che dici, tranne una cosa (parte in grassetto): questi bug danno al phenom un -7/12% di prestazioni, quindi imho mettimo il caso più sfortunato che aumentino di un solo 7% però con bios aggiornati e soprattutto con software ricompilato (anche se devo capirla megli sta storia) ci potrebbe essere un sostanziale pareggio tra intel e amd (e nn sarebbe male) oppurecasi in cui intel va meglio in alcuni settori e altri dove amd va di più

è verissimo quello che dici, tranne una cosa (parte in grassetto): questi bug danno al phenom un -7/12% di prestazioni, quindi imho mettimo il caso più sfortunato che aumentino di un solo 7% però con bios aggiornati e soprattutto con software ricompilato (anche se devo capirla megli sta storia) ci potrebbe essere un sostanziale pareggio tra intel e amd (e nn sarebbe male) oppurecasi in cui intel va meglio in alcuni settori e altri dove amd va di più

Ma guarda... se prendiamo in considerazione la sistemazione dei bug... arriveremmo secondo me a superare Intel in alcune circostanze, a pareggiare in altre e a perdere in altre... ma il sunto è che sarebbe cmq un pò inferiore (ma poco) agli attuali 65nm Intel e un pò di più rispetto ai 45nm...

SE invece prendiamo in considerazione il problema di ricompilazione... cambia tutto.. Ora ti spiego...
A quasi parità di di clock (2,5 Opteron e 2,66 Xeon) nei calcoli INTEGER, utilizzando i migliori COMPILER per processore, L'Opteron perde SOLO il 4-6 % mentre in FLOATIN POINT vince del 34/36 % !!! Ciò spiega un pò il problema delle compilazioni dei programmi di tutti i giorni... Tuttavia non so se i Barcellona hanno questi bug... ma se li avessero pure loro... allora sarebbe tutto un casino...

Ma guarda... se prendiamo in considerazione la sistemazione dei bug... arriveremmo secondo me a superare Intel in alcune circostanze, a pareggiare in altre e a perdere in altre... ma il sunto è che sarebbe cmq un pò inferiore (ma poco) agli attuali 65nm Intel e un pò di più rispetto ai 45nm...

SE invece prendiamo in considerazione il problema di ricompilazione... cambia tutto.. Ora ti spiego...
A quasi parità di di clock (2,5 Opteron e 2,66 Xeon) nei calcoli INTEGER, utilizzando i migliori COMPILER per processore, L'Opteron perde SOLO il 4-6 % mentre in FLOATIN POINT vince del 34/36 % !!! Ciò spiega un pò il problema delle compilazioni dei programmi di tutti i giorni... Tuttavia non so se i Barcellona hanno questi bug... ma se li avessero pure loro... allora sarebbe tutto un casino...

Il K10 Barcelona usa lo step B1/BA la quale soffre di altri piccoli bug + quelli del B2...

Il K10 Barcelona usa lo step B1/BA la quale soffre di altri piccoli bug + quelli del B2...

quindi il phenom è meglio, nn solo ma il BA ricordo che aveva un bug gravissimo nella mamoria e nell'ht

quindi si è fiduciosi

speriamo che il buon Paolo ci risponda :D

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.

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.

ovviamente lo definisci bug minore perché hai letto i documenti giusto?
allora parlacene in dettaglio, quali comportamenti dovremmo aspettarci dalle cpu che sono affette da questo bug? la stima del 3% viene da dei dati precisi immagino, puoi approfondire il tuo pensiero?

ovviamente lo definisci bug minore perché hai letto i documenti giusto?
allora parlacene in dettaglio, quali comportamenti dovremmo aspettarci dalle cpu che sono affette da questo bug? la stima del 3% viene da dei dati precisi immagino, puoi approfondire il tuo pensiero?Cavolo, adesso i sostenitori di AMD si arrabbiano pure se definisco il bug come "minore". :D

Va bene, allora non è un bug minore, ma bensì un bug grosso... bello grosso... :oink: e dono un "compliments" ai coraggiosi che vorranno provare l'ebrezza del BSOD random e delle prestazioni dimezzate proprio quando serve di più (ovvero con un carico del 100%).

Così va meglio? :stordita:

p.s. Il 3% è l'incremento medio che si ottiene solo con il raddoppio della cache, appunto... e comunque rimane un mio pensiero, se questo ti far star meglio... :-)

Cavolo, adesso i sostenitori di AMD si arrabbiano pure se definisco il bug come "minore". :D

Va bene, allora non è un bug minore, ma bensì un bug grosso... bello grosso... :oink: e dono un "compliments" ai coraggiosi che vorranno provare l'ebrezza del BSOD random e delle prestazioni dimezzate proprio quando serve di più (ovvero con un carico del 100%).

Così va meglio? :stordita:

p.s. Il 3% è l'incremento medio che si ottiene solo con il raddoppio della cache, appunto... e comunque rimane un mio pensiero, se questo ti far star meglio... :-)

mi sono arrabbiato? non mi pare, ti ho solo chiesto di approfondire il tuo pensiero dal punto di vista tecnico, visto che sembri così ferrato

c'è gente come bjt2 e leoneazzurro con una buona preparazione che l'ha già fatto, se potessimo aggiungere anche i tuoi commenti renderemmo il tutto più completo no?

Cavolo, adesso i sostenitori di AMD si arrabbiano pure se definisco il bug come "minore". :D

Va bene, allora non è un bug minore, ma bensì un bug grosso... bello grosso... :oink: e dono un "compliments" ai coraggiosi che vorranno provare l'ebrezza del BSOD random e delle prestazioni dimezzate proprio quando serve di più (ovvero con un carico del 100%).

Così va meglio? :stordita:

p.s. Il 3% è l'incremento medio che si ottiene solo con il raddoppio della cache, appunto... e comunque rimane un mio pensiero, se questo ti far star meglio... :-)
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).

Se mi posso azzardare, ai miei occhi sembra che si voglia per forza trovare una giustificazione per le prestazioni (concedetemi il termine) deludenti... e forse non è il caso.
Forse, come per l'architettura R600, le prestazioni sono (concedetemelo ancora) deludenti semplicemente per colpa dell'architettura poco prestante... senza necessità di tirare in ballo drivers, ottimizzazioni via shaders mancanti, BIOS acerbi, oppure bug.
Ciò non toglie vi possano esser miglioramenti, ma di certo (e RV670 ne è esempio lampante), resta valido il famoso detto "strizza strizza ma non puoi tirare fuori il sangue da una rapa".
Sempre un mio pacato pensiero, eh. Sia chiaro! :-)


p.s. Penso anche che AMD e ATI abbiano già di loro fior fiori di ingegneri.

Se mi posso azzardare, ai miei occhi sembra che si voglia per forza trovare una giustificazione per le prestazioni (concedetemi il termine) deludenti... e forse non è il caso.
Forse, come per l'architettura R600, le prestazioni sono (concedetemelo ancora) deludenti semplicemente per colpa dell'architettura poco prestante... senza necessità di tirare in ballo drivers, ottimizzazioni via shaders mancanti, BIOS acerbi, oppure bug.
Ciò non toglie vi possano esser miglioramenti, ma di certo (e RV670 ne è esempio lampante), resta valido il famoso detto "strizza strizza ma non puoi tirare fuori il sangue da una rapa".
Sempre un mio pacato pensiero, eh. Sia chiaro! :-)


p.s. Penso anche che AMD e ATI abbiano già di loro fior fiori di ingegneri.

non mi pare che bjt2 o leoneazzurro abbiano cercato di giustificare nessuno, hanno fatto un'analisi in base alle loro conoscenze, che a quanto hanno dimostrato nel forum sono buone

aspettiamo le tue analisi tecniche che confutino quello che hanno scritto loro, se è questo quello che vuoi fare, ma se è solo un tuo pensiero stimato a "occhio" stai facendo semplicemente un ragionamento opposto a chi, a tuo modo di vedere, giustifica le prestazioni deludenti in base alla sua "fede" per AMD, quindi le tue affermazioni valgono come le "loro"

Se mi posso azzardare, ai miei occhi sembra che si voglia per forza trovare una giustificazione per le prestazioni (concedetemi il termine) deludenti... e forse non è il caso.
Forse, come per l'architettura R600, le prestazioni sono (concedetemelo ancora) deludenti semplicemente per colpa dell'architettura poco prestante... senza necessità di tirare in ballo drivers, ottimizzazioni via shaders mancanti, BIOS acerbi, oppure bug.
Ciò non toglie vi possano esser miglioramenti, ma di certo (e RV670 ne è esempio lampante), resta valido il famoso detto "strizza strizza ma non puoi tirare fuori il sangue da una rapa".
Sempre un mio pacato pensiero, eh. Sia chiaro! :-)


p.s. Penso anche che AMD e ATI abbiano già di loro fior fiori di ingegneri.
beh se i bug ci sono e sono bug che influiscono le prestazioni possono essere aumentate eccome, qua nessuno sta tentando di giustificare prestazioni scadenti, si sta solo vedendo come l'architettura sia uscita ancora immatura e probabilmente le prestazioni deludenti sono dovute a quello. Ne riparleremo con lo step b3 (se verrò smentito però non metterlo in firma come hai fatto con rv670... :D )...

Se mi posso azzardare, ai miei occhi sembra che si voglia per forza trovare una giustificazione per le prestazioni (concedetemi il termine) deludenti... e forse non è il caso.
Forse, come per l'architettura R600, le prestazioni sono (concedetemelo ancora) deludenti semplicemente per colpa dell'architettura poco prestante... senza necessità di tirare in ballo drivers, ottimizzazioni via shaders mancanti, BIOS acerbi, oppure bug.
Ciò non toglie vi possano esser miglioramenti, ma di certo (e RV670 ne è esempio lampante), resta valido il famoso detto "strizza strizza ma non puoi tirare fuori il sangue da una rapa".
Sempre un mio pacato pensiero, eh. Sia chiaro! :-)


p.s. Penso anche che AMD e ATI abbiano già di loro fior fiori di ingegneri.

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

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).Bhe, guarda, innanzitutto è evidente come un confronto "Core 2 Duo vs Penryn" non sia possibile ricondurlo a un "4MB vs 6MB", a fronte di tutte le migliorie architetturali che evidentemente danno dei (seppure minimi) benefici.
D'altro canto, a supporto di ciò che dico, posso linkarti questa recensione:
http://www.phoronix.com/scan.php?page=article&item=219&num=5
Risulta infatti discretamente semplice "sputare dati" per AMD datosi che anni fa commercializzava CPU proprio la cui unica differenza era "il doppio di cache".
Quindi, ecco l'estratto che a noi interessa: "In conclusion, for average users, we found that the San Diego offers an average of 3% higher return than its counter part, Venice, when running at the same clock speed."

Se mi posso azzardare, ai miei occhi sembra che si voglia per forza trovare una giustificazione per le prestazioni (concedetemi il termine) deludenti... e forse non è il caso.
Forse, come per l'architettura R600, le prestazioni sono (concedetemelo ancora) deludenti semplicemente per colpa dell'architettura poco prestante... senza necessità di tirare in ballo drivers, ottimizzazioni via shaders mancanti, BIOS acerbi, oppure bug.
Ciò non toglie vi possano esser miglioramenti, ma di certo (e RV670 ne è esempio lampante), resta valido il famoso detto "strizza strizza ma non puoi tirare fuori il sangue da una rapa".
Sempre un mio pacato pensiero, eh. Sia chiaro! :-)


p.s. Penso anche che AMD e ATI abbiano già di loro fior fiori di ingegneri.

non mi pare che bjt2 o leoneazzurro abbiano cercato di giustificare nessuno, hanno fatto un'analisi in base alle loro conoscenze, che a quanto hanno dimostrato nel forum sono buone

aspettiamo le tue analisi tecniche che confutino quello che hanno scritto loro, se è questo quello che vuoi fare, ma se è solo un tuo pensiero stimato a "occhio" stai facendo semplicemente un ragionamento opposto a chi, a tuo modo di vedere, giustifica le prestazioni deludenti in base alla sua "fede" per AMD, quindi le tue affermazioni valgono come le "loro"

beh se i bug ci sono e sono bug che influiscono le prestazioni possono essere aumentate eccome, qua nessuno sta tentando di giustificare prestazioni scadenti, si sta solo vedendo come l'architettura sia uscita ancora immatura e probabilmente le prestazioni deludenti sono dovute a quello. Ne riparleremo con lo step b3 (se verrò smentito però non metterlo in firma come hai fatto con rv670... :D )...

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

Io vorrei aggiungere inoltre la storia della ricompilazione:

http://www.hwupgrade.it/forum/showpost.php?p=19772559&postcount=825

Se osservate vedrete come almeno a quasi parità di clock il Barcelona (che è uno step BA al momento, quindi andtecedente al B2 e che ha i bug in questione più altri ancora) le da di santa ragione in FP e perde relativamente poco in Integer... tutto con RICOMPILAZIONE. Quindi qui non è tanto il problema di architettura non valida, ma un problema di SOFTWARE e COMPILAZIONE a mio avviso... e questi dati sono sotto gli occhi di tutti.

Bhe, guarda, innanzitutto è evidente come un confronto "Core 2 Duo vs Penryn" non sia possibile ricondurlo a un "4MB vs 6MB", a fronte di tutte le migliorie architetturali che evidentemente danno dei (seppure minimi) benefici.
D'altro canto, a supporto di ciò che dico, posso linkarti questa recensione:
http://www.phoronix.com/scan.php?page=article&item=219&num=5
Risulta infatti discretamente semplice "sputare dati" per AMD datosi che anni fa commercializzava CPU proprio la cui unica differenza era "il doppio di cache".
Quindi, ecco l'estratto che a noi interessa: "In conclusion, for average users, we found that the San Diego offers an average of 3% higher return than its counter part, Venice, when running at the same clock speed."

Sinceramente non ha molto senso fare paragoni fra un Bug di questo tipo con l'incremento di cache...
non vorrei dire ma il BUG impone anche nel caso di scrittura di 2 bytes di rileggere la cache, riunificare i dati e riscrivere TUTTA la cache... per le operazioni piccole e medie è un vero salasso prestazionale... poi vorrei far notare che il primo bug diventa rilevante quando la memoria si satura o si carica molto... e il secondo bug ha l'effetto di caricare molto la memoria di sistema... quindi è una cascata.

Cmq sia riscrivere intermante l'intera cache per qualunque operazione e coda dati piccola o media, è un salasso, è chiaro. Con ciò non dico che debba dare per forza prestazioni del 10% in più... ma che l'entità del problema è decisamente rilevante... Inoltre invito a leggere il 3D sul K10 per quanto riguarda i test di Sandra sulle memorie..

Io vorrei aggiungere inoltre la storia della ricompilazione:

http://www.hwupgrade.it/forum/showpost.php?p=19772559&postcount=825

Se osservate vedrete come almeno a quasi parità di clock il Barcelona (che è uno step BA al momento, quindi andtecedente al B2 e che ha i bug in questione più altri ancora) le da di santa ragione in FP e perde relativamente poco in Integer... tutto con RICOMPILAZIONE. Quindi qui non è tanto il problema di architettura non valida, ma un problema di SOFTWARE e COMPILAZIONE a mio avviso... e questi dati sono sotto gli occhi di tutti.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=20071120&page=amd_phenom_9500_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?

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=20071120&page=amd_phenom_9500_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?

Credo tu non abbia capito il mio concetto:
non sto dicendo che uno o l'altro siano affidabili a livello generale e comune, per carità.. tuttavia dal punto di vista server, dove la ricompilazione è comune, è più affidabile il test di SPEC.org (che per altro è la società che raccoglie i test supermicro che sono estremamente affidabili). Il punto del mio discorso verte sulla compilazione... per l'utente normale, è chiaro che va visto attraverso i programmi comuni, che sono PRECOMPILATI (ricorda... PRECOMPILATI).. tuttavia il mio discorso è prettamente tecnico ed assolutistico: se vengono RICOMPILATI i programmi con i migliori COMPILER, i Barcellona (più deboli dei Phenom) migliorano radicalmente, distruggendo in FP i Quad Core Intel e avvicinandosi parecchio nell'integer. Ciò infatti rispecchia il fatto che rispetto alla vecchia generazione i phenom hanno risorse letteralmente doppie rispetto ai K8 in FloatingPoint ed era strano che in quel campo andassero solo poco più forte se non uguale in alcuni casi... ecco svelato il motivo: c'è un problema nella compilazione.

Con ciò non voglio dire assolutamente che oggi giorno, con le applicazioni che tutti usano, bisogna cambiare la prospettiva, dico solo che c'è un problema di istruzioni e linguaggio di compilazione che abbatte letteralmente le prestazioni dei phenom.

E ti ricordo che i test di Spec.org sono attendibili.. soprattutto quelli SuperMicro all'interno (i test considerati sono SuperMicro)

PS. in quei test vengono utilizzate moltissime applicazioni di uso comune MA vengo RICOMPILATE.
PS2. i problemi di overclock dei phenom sono dovuti al NB. l'Ht è settato dal moltiplicatore del NB e va a 3.6 ghz.. quando si overclocca, l'ht sale alle stelle e va in palla... infatti sono solo pochi fortunati che riescono a mantenere buoni livelli con l'ht. purtroppo i bios sono ancora acerbi per queste nuove schede madri e non permettono di abbasare il molti del NB e conseguentemente la stellare frequenza dell'HT. è quello il collo che tarpa le ali all'oc sui phenom. Quindi se già adesso qualcuno raggiunge i 3.0 ghz con questo problema di HT alle stelle... figuriamoci conq questo problema risolto...

Sono concetti per me un poco -e qua sono indeciso con l'aggettivo- astrusi/astratti.

In pratica mi stai dicendo che la potenza dei Phenom è inespressa, e per sfruttarla bisognerebbe ri-compilare tutti gli applicativi? (e questo compilatore alternativo è magari di AMD? e inficia le prestazioni degli Intel?)

Com'è che è la prima volta che sento di questa giustificazione (per prima intendo "con gli Athlon XP, Prescott, Core 2 Duo nessuno si era posto di questi problemi)?

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.

Vedere un sistema a 4 schede video (o 3) ,e pensare all'esborso in denaro, e pensare ai consumi, e pensare alla differenza di spesa che passa tra un pc che una volta poteva essere buono,magari con una scheda, e uno come questi a 3 o 4, fa venir voglia di comprarsi un Nintendo WII o una 360 o PS3 se preferite.
In questi ultimi anni sono sempre stato pro pc, dopo aver abbandonato le console, ma vedendo queste cose, sinceramente mi passa la voglia, se poi tutti i futuri giochi prendono la piega di Crysis.. meglio un NDS o PSP se preferite.
Bo..forse sono gusti personali, ma se il futuro del PC game è questo, sono ben felice di lasciarlo, piu che altro perchè i programmatori..mi chiedo come facciano per ottimizzare i giochi..usciranno sempre peggio secondo me.

Ma noo, ancora la storia dei compilatori.
È vero che gli eseguibili dei compilatori Intel viaggiano di più su Intel.
Però i compilatori Intel ci sono, quelli AMD no.
E che tutti usino compilatori Intel non mi sembra mica tanto vero...

Prima di parlare, per favore, guarda i test in questioni sopra linkati...
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.
è vero che non esistono compilatori AMD, ma ciò non vuol dire che i PathClass ed i PGI utilizzati facciano pena, anzi!!! utilizzando questi, i Barcellona crescono radicalmente e fanno a pezzi in FP gli XEON (cosa che per applicazioni precompilate non avviene e data la potenza doppia di K10 su K8 in FP, dovrebbe avvenire).
Ergo, il discorso dei compilatori non è errato.

Dico solo Corsini fatti venire il sangue alle mani su sto Phenom, e tagli da molex sulle dita... Insomma: buoni test approfonditi!


La storia dei compiler ha senso nel momento in cui chi scrive può permettersi di farlo, la maggior parte dei produttori SW prende quel che trova e se va va, se non va pace.

Se incide in questo modo allora prima o poi scatteranno dei correttivi durante la scelta dei compilatori, se sono architetture diverse alla fine, uè, bisogna fargli andare sti processori.

Mi sembra ovvio come ragionamento, solo facendo il parallelo semplice semplice delle istruzioni sse, chi le implementa si trova con programmi che le possono sfruttare, e fanno tirare come delle bestie le loro macchine. Con incrementi mica da ridere, se si può ottenere un risultato simile tra un po' avremmo Adobe CS4 Intel/Amd edition...

Dài, mi è morto il pc l'altro ieri, datemi un concorrente valido per pochi schei.... su...

In aggiunta, per quanto riguarda l'oc, se si aumenta, come si fa per come si è visto, di 30 mhz circa il bus.. cioè circa 230 mhz... se a 200 mhz di bus abbiamo 3600 mhz di HT, senza toccare il molti del NB abbiamo 4140 mhz di HT e senza toccare neppur i voltaggi... è dura che regga quei mhz...

Dico solo Corsini fatti venire il sangue alle mani su sto Phenom, e tagli da molex sulle dita... Insomma: buoni test approfonditi!


La storia dei compiler ha senso nel momento in cui chi scrive può permettersi di farlo, la maggior parte dei produttori SW prende quel che trova e se va va, se non va pace.

Se incide in questo modo allora prima o poi scatteranno dei correttivi durante la scelta dei compilatori, se sono architetture diverse alla fine, uè, bisogna fargli andare sti processori.

Mi sembra ovvio come ragionamento, solo facendo il parallelo semplice semplice delle istruzioni sse, chi le implementa si trova con programmi che le possono sfruttare, e fanno tirare come delle bestie le loro macchine. Con incrementi mica da ridere, se si può ottenere un risultato simile tra un po' avremmo Adobe CS4 Intel/Amd edition...

Dài, mi è morto il pc l'altro ieri, datemi un concorrente valido per pochi schei.... su...

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.

Cmq è chiaro, loro fanno quel più fa comodo e meno costa, oltre al fatto che per 1 anno c'è stata solo Intel con i Core e quindi ha avuto più attrattiva per le compilazioni.

Cmq questa pesante influenza di compilazione lascia veramente basiti... soprattutto perché cmq, le software house se ne fregheranno...

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?? :mad: e ci fate guardare le foto delle schede collegate! :D 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??

@ 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 :D

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ì :D (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 ;)

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???? :p



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

Dimenticavo:

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.


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 ;)

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

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.

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=20071120&page=amd_phenom_9500_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...

:sofico:

NON COMPRATE NULLA! :D

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 :p)

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

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 :p)

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

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

Ok, adesso mi sono capito :p ;)

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 :D ) ma mi sa che così finiamo un po' OT :p

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???? :p



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

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.

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?

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

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.

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.

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.

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

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

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.

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

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 .

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.


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

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

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

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

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

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)... :D Si tratta di abilitare dei flag e aspettare un po' di più per compilare... :D

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

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.

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.

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)... :D Si tratta di abilitare dei flag e aspettare un po' di più per compilare... :D

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.

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

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)

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.

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.

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.

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

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

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

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

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!

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.

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

@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 :p 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 :p), 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.

@ Free Gordon

Ma figurati, siamo qui per questo :D

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) :p

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

AMD + ATI siamo sempre sotto a INTEL + GEFORCE

AMD + ATI siamo sempre sotto a INTEL + GEFORCE

Ecco, avevamo avuto 10 pagine di commenti interessanti, questo invece non solo non lo è, ma è anche deleterio per una buona discussione.

X Corsini

Se non sbaglio, dovreste avere in redazione una versione beta di VirtualDub che supporta le SSE4: potrebbe essere interessante vedere come si comporta con i Phenom, cioè cercare di capire se supporta o meno la presenza delle sse4a (e se lo fa, presumibilmente supporterà anche il nuovo path di esecuzione per le sse in generale), magari confrontando il risultato con la versione precedente, per avere una qualche stima delle variazioni (forse converrebbe misurare le variazioni anche con un k8, per cercare di evidenziare eventuali variazioni che prescindano dal supporto a diversi elementi architetturali, in modo da capire meglio se le ottimizzazioni per sse4 comprendano anche il supporto per il k10, e in caso affermativo valutarne meglio l'impatto). Tanto non ti farebbe crescere il lavoro, vero? (prima di premere il grilletto, sappi che mi sono allontanato dal pc, quindi la fucilata virtuale non mi arriva :p)

X Corsini

Se non sbaglio, dovreste avere in redazione una versione beta di VirtualDub che supporta le SSE4: potrebbe essere interessante vedere come si comporta con i Phenom, cioè cercare di capire se supporta o meno la presenza delle sse4a (e se lo fa, presumibilmente supporterà anche il nuovo path di esecuzione per le sse in generale), magari confrontando il risultato con la versione precedente, per avere una qualche stima delle variazioni (forse converrebbe misurare le variazioni anche con un k8, per cercare di evidenziare eventuali variazioni che prescindano dal supporto a diversi elementi architetturali, in modo da capire meglio se le ottimizzazioni per sse4 comprendano anche il supporto per il k10, e in caso affermativo valutarne meglio l'impatto). Tanto non ti farebbe crescere il lavoro, vero? (prima di premere il grilletto, sappi che mi sono allontanato dal pc, quindi la fucilata virtuale non mi arriva :p)

Ciao,
ho verificato in questo momento: Divx 6.7 non permette di abilitare il supporto SSE4 con le cpu Phenom

Ciao,
ho verificato in questo momento: Divx 6.7 non permette di abilitare il supporto SSE4 con le cpu Phenom

Ecco, per il Phenom, come dire... il buon giorno si vede dal mattino :D

Va be', è una beta (giusto?), quindi il supporto potrebbe essere abilitato prima della release finale, a meno che non sfruttino istruzioni escluse dal set 4a e non preferiscano evitare modifiche all'algoritmo... Chissà se c'è un modo "semplice" per far credere al programma che verrà eseguito su di un'altra cpu, senza doverne toccare il codice... magari andrebbe in crash per l'assenza di qualche istruzione, ma potrebbe essere un tentativo interessante (se lecito)...

Grazie per la risposta e buon proseguimento nei test!

Ecco, avevamo avuto 10 pagine di commenti interessanti, questo invece non solo non lo è, ma è anche deleterio per una buona discussione.

In effetti mi sa ke la AMD + la ATI nn vanno troppo lontano ma forse cn questa serie 7 va un po meglio. Mi kiedo cm mai la AMD nn ha ancora superato i 3.2Ghz. La INTEl invece ha raggiunto su in overclocking addirittura i 5Ghz. :muro:

In effetti mi sa ke la AMD + la ATI nn vanno troppo lontano ma forse cn questa serie 7 va un po meglio. Mi kiedo cm mai la AMD nn ha ancora superato i 3.2Ghz. La INTEl invece ha raggiunto su in overclocking addirittura i 5Ghz. :muro:

Quello che critico è il celolunghismo imperante. "Io sto sopra, tu stai sotto" è un concetto francamente insulso, visto che poi sappiamo bene che la ruota può girare...

PS :se parliamo di P4 si sono raggiunte frequenze oltre i 6 GHz... Comunque ci sono anche CPU AMD in overclock spinto che sono arrivate a 4 GHZ...

Si però e ancora un po indietro ma anke se e la migliore (secondo me). :)

Piccola curiosità, dato che è possibile variare la frequenza dei 4 core separatamente impostando 4 frequenze diverse per ogni core la cache L3 a quel punto a che velocità andrà?

Piccola curiosità, dato che è possibile variare la frequenza dei 4 core separatamente impostando 4 frequenze diverse per ogni core la cache L3 a quel punto a che velocità andrà?

La cache L3 va alla velocità del NB ed è dotata di un buffer per ogni core (e credo almeno un buffer per tutti i link HT, anche se probabilmente un buffer per link) per gestire l'asincronia... ;)

Quello che critico è il celolunghismo imperante. "Io sto sopra, tu stai sotto" è un concetto francamente insulso, visto che poi sappiamo bene che la ruota può girare...

PS :se parliamo di P4 si sono raggiunte frequenze oltre i 6 GHz... Comunque ci sono anche CPU AMD in overclock spinto che sono arrivate a 4 GHZ...

Sì, però il nuovo WR super pi 1M 7.75s, tra l'altro italiano, è 5,8 Ghz con Intel QX9650 (retail).
È un dato di fatto che AMD è anni che, gira e gira, è sempre ferma alle stesse frequenze, sia di targa che in over.

Sì, però il nuovo WR super pi 1M 7.75s, tra l'altro italiano, è 5,8 Ghz con Intel QX9650 (retail).
È un dato di fatto che AMD è anni che, gira e gira, è sempre ferma alle stesse frequenze, sia di targa che in over.
Super PI, single threaded. Who cares?

Sì, però il nuovo WR super pi 1M 7.75s

Ecco, appunto, celopiccolismo esasperante :D

:Prrr: :Prrr: :Prrr: :Prrr: :Prrr: :Prrr: :Prrr: :Prrr:

Super PI, single threaded. Who cares?

Sì, ma non discutevo sull'utilità del record, record che tra l'altro varian bene con i timing delle Ram mentre in applicativi pratici c'è poca diffrenza, ma che Intel con i Core Duo è partita da frequenze basse e sta arrivando alle frequenze del P4.
AMD, no, il che dice che ha qualche problema in questo ambito che cerca di sopperire con un'efficenza migliore.

Poi non sono partigiano di una casa, anzi mi fa piacere se Amd ritorna al vertice, ci mancherebbe, una bella e sana "lotta" con cambio della posizione di vertice è quanto di meglio c'è per le prestazioni e il portafoglio (basti pensare ai prezzi "da ricchi" degli Athlon X2 nel peggior momento di Intel).
A dimostrazione dico che ho sia un E6600 che un 64 3800+, e seguo sempre le novità, perchè mi piacerebbe passare a (Q6600 o Q9xx0) e (Phenom o X2 5000+ Black intanto).

Sotto coi test, che sto aspettando con ansia! :D

fra quanto la recensione sulla piattaforma? l ho detto gia a tutti gli amici :D

scusate la mia immensa ignoranza
ma secondo le immagini riportare dal sig. Corsini sui test
nn vedo una grandissima differnza di prestazioni tra la 580X e la 790FX. il che inuce a optare per una 580X che tra laltro mi costa anche meno. mi spiegate dove che sta la differenza.
grazie.