[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[ozlacs]

mai dire mai Capitano

[capitan_crasy]

Originariamente inviato da ozlacs

mai dire mai Capitano

Lo so, ma in questo caso mi sembra improbabile...
GF sta ancora testando i 32nm e secondo la loro roadmap cominceranno ad accettare ordini solamente nella seconda parte del 2010.
La prima produzione in volumi è fissata durante o dopo il terzo trimestre 2010; con queste date è quasi impossibile che AMD esca con Llano entro l'inizio del 2010...

[Pihippo]

http://www.agner.org/optimize/blog/read.php?i=25

Software programmers may expect the compilers and software libraries to take care of all the intricacies of instruction sets for them. And the obvious way to deal with incompatible instruction sets is to make multiple branches of the code. Ideally, you would have one branch of code optimized for the latest Intel instruction set, another branch for the latest AMD instruction set, and one or more branches for older CPUs with older instruction sets. The software should detect which CPU it is running on and then choose the appropriate version of the code. This is called CPU dispatching. If the compiler can put a CPU dispatching mechanism into your code then you don't have to care about incompatible instruction sets - or do you?
The only compiler I have found that has such a feature for automatic CPU dispatching is Intel's compiler. The Intel compiler can put a CPU dispatcher into your code so that it checks which instruction set (SSE, SSE2, SSE3, etc.) is supported by the CPU and chooses a branch of code that is optimized for that instruction set - but only as long as it is running on an Intel CPU! It refuses to choose the optimal branch if the CPU doesn't have the "GenuineIntel" mark, even if the non-Intel CPU if fully compatible with the optimized code. And who would want to sell a software package that works poorly on AMD and VIA processors?

The situation is only slightly better when it comes to software libraries. Most compilers are equipped with libraries of standard functions, or you can use third party libraries. Some of the best optimized software libraries are published by Intel, but again they are optimized for Intel processors, and some of the functions work sub-optimally or not at all on non-Intel processors. AMD also publishes software libraries, and the AMD libraries work well on Intel processors, but of course the AMD libraries don't have a code branch that is optimized for instructions that are only available on Intel processors. There are many other libraries available, but they are typically less optimized and have little or no CPU dispatching. The GNU people are beginning to build a - long overdue - CPU dispatch mechanism into the GNU C library. The GNU library is open source, and of course it must support all x86 CPUs. But this work is done mostly by an Intel guy who has his natural focus on the latest Intel instruction sets and who has so far tested his improvements mainly on Intel processors. The best optimized code branches will work on AMD and VIA processors only with a few years delay when AMD and VIA have copied the Intel instruction sets into their processors. I am not aware of any AMD people contributing the GNU C library

In sintesi. I compiler c'entrano eccome sulle performance di una cpu...

[Vash_85]

Originariamente inviato da Pihippo

http://www.agner.org/optimize/blog/read.php?i=25

Software programmers may expect the compilers and software libraries to take care of all the intricacies of instruction sets.....
Cut
In sintesi. I compiler c'entrano eccome sulle performance di una cpu...

Ecco perché su os open source un misero phen x3 da filo da torcere ad un i7....

Amd non ha dei compilatori propietari?
Visto che potrebbe anche avere le cpu più potenti del mondo ma se i compilatori intel le fanno andare come dei 386 è meglio lasciare stare...

[Phlmos]

Cmq, secondo me per chi ha 2-4 core sarebbe più sensato aspettare il 32NM.. Magari passando direttamente a 6 Core

Cioè saltare il 2010 praticamente è aspettare l'Am3r2 per non rimanare di anno in anno indietro

Che dite?

Si sopravvive con 2 Core per un anno ?

[Vash_85]

Originariamente inviato da Phlmos

Cmq, secondo me per chi ha 2-4 core sarebbe più sensato aspettare il 32NM.. Magari passando direttamente a 6 Core

Cioè saltare il 2010 praticamente è aspettare l'Am3r2 per non rimanare di anno in anno indietro

Che dite?

Si sopravvive con 2 Core per un anno ?

Io sopravvivo con un single da 1.6 ghz da 3 anni

[carlottoIIx6]

Originariamente inviato da Vash_85

Ecco perché su os open source un misero phen x3 da filo da torcere ad un i7....

Amd non ha dei compilatori propietari?
Visto che potrebbe anche avere le cpu più potenti del mondo ma se i compilatori intel le fanno andare come dei 386 è meglio lasciare stare...

è quel dicevo!
anche senza esagerare... per esempio via è di fatto tagliata fuoori!

era logico e lineare che fosse così!
se pensate che amd e intel hanno lo stesso numero di transistor, le operazioni che possono fare almeno sulla carta sono comparabili.

ma è qui che viene il bello del progetto fusion!

con il magior numero di transistor e le specifiche dell'apu
l'hardware potrebbe adattarsi come un guanto al
software!
inoltre se amd propone prima un nuovo standart
potrebbe avvantagiarsi su intel!!!

peccato che via sia tagliata
fuori!!!

inoltre qui dico che le apu sono avvantagiata sulle
gpgpu!
(per motivi che vi ho detto nell'altro
thread e ragioni
"di fisica"
che non vi sto a specificare
)
e posto questo commento
per dire che windows fa la aprte sua
ricordate il ritardo dei sistemi 64bit?
Commento di Il_Saggio pubblicato in data 07 dicembre 2009 alle ore 21:09
Il fatto è che quando si avranno i 22nm ATI e nvidia non staranno certo lì ancora
con l'architettura odierna (quantomeno ATI non ce l'avrà se vuole competere nel GPGPU)
per cui Intel si troverà ancora indietro (e molto).
L'architettura x86 è inefficiente. L'unica cosa che la tiene in vita è Windows. Elimina
Windows o metti che domani questo esca per altre architetture (ARM, PPC) e tutti i GFlops
che Intel si vanta di avere ora finiscono nella tazza del cesso. Fine del monopolio.
Inizio del vero sviluppo informatico dove conta chi fa più con meno.
Non c'è modo che core x86 possano tenere il passo di core fatti ad hoc per il calcolo
parallelo. Neanche la tanto pubblicizzata "facilità di programmazione perchè sono x86"
ha senso. I compilatori Intel, per quanto ottimi, hanno come target qualcosa che consuma
un sacco di corrente per fare quello che altri fanno con 1/3 della stessa. Altri possono
permettersi compilatori meno ottimizzati, ma con un HW molto più efficiente di quanto
faccia una ottimizzazione su x86, anche HW con tutti quelle parti nel micro che fanno
riordinamento e bufferizzazione della complessa decodifica usando ulteriori milioni di
transistor (e corrente).

[alesc]

La storia dei compilatori, nota da tempo, credo sia molto importante ma c'è qualcosa che non mi torna. Se fosse così importante perché AMD non ha mai fatto un suo compilatore? Perché in pubblico non ha mai denunciato che la differenza fra le sue cpu e quelle intel è per la maggior parte dovuta al compilatore Intel (che è il più usato)?

[greeneye]

Lo ha fatto: uno dei capi di accusa nel processo contro intel è l'ottimizzazione fantasiosa dei suoi compilatori.

Non mi ricordo il programma (mi pare povray) dove bastava rinominare una dll (facendogli caricare la stessa che usava con i processori intel che i phenom volavano (....andavano meglio....)

[carlottoIIx6]

Originariamente inviato da alesc

La storia dei compilatori, nota da tempo, credo sia molto importante ma c'è qualcosa che non mi torna. Se fosse così importante perché AMD non ha mai fatto un suo compilatore? Perché in pubblico non ha mai denunciato che la differenza fra le sue cpu e quelle intel è per la maggior parte dovuta al compilatore Intel (che è il più usato)?

se ti leggi l'articolo indicato da pihippo
http://www.agner.org/optimize/blog/read.php?i=25
ti rendi conto che è più che il compilatore
ma
anche
una lotta ad imporre un standart
cosi mi sembra di aver capito...
chi riesce ad imporre uno standart (ai progammatori) infine ha i programmi più ottimizzati...
poi c'è anche la compilazione che agiunge!
amd ha vinto solo ocn le istruzioni a 64bit
ed è stato il periodo in cui intel era in crisi!

per me un solo standard appiattirebbe le cose
per me dovrebbero mettere i programmotori in grado di scrivere indipendentemente dai vari standard
e permettere ai compilatori di compilare scegliendo le librerie
ecc
in funzione
dell'hardware

così amd, intel, via
nvidia con le gpgpu
possono farsi le loro istruzioni
e il compilatore
ottimizzare per hardware!

spero di non essere troppo fantasiosi, anche se a occhio e croce si può fare.

PS mi scuso, perchè cmq
scrivo
in fretta, per gli errori

[lele980]

perdonate la mia svogliatezza nel leggere questo manoscritto

ma ho una domanda da fare:

qua si parla dell architettura bulldozer per il 2011

quindi per tutto il 2010 non ci sara' alcuna cpu superiore al 965???

parlo in ambito desktop

[capitan_crasy]

Originariamente inviato da lele980

perdonate la mia svogliatezza nel leggere questo manoscritto

ma ho una domanda da fare:

qua si parla dell architettura bulldozer per il 2011

quindi per tutto il 2010 non ci sara' alcuna cpu superiore al 965???

parlo in ambito desktop

Ci sarà sicuramente il core "Thuban" CPU AMD 6 core desktop e forse il 975 @ 3.60Ghz...

[carlottoIIx6]

Originariamente inviato da Maxmoss90

pechè fare una cosa del genere ? comporterebbe un lavoro allucinante per i programmatori. Nessuno è così pazzo da sacrificarsi per uan fetta di mercato così minuscola come VIA e AMD. ovvio che quando un programmatore fa un applicativo usa sempre le istruzioni e il compilator intel che rappresenta la fetta più grande in assoluto.

nella mia idea il programmatore scrive in un linguaggio
indipendente che vle per tutti
mentre le librerie e la compilazione dipendono dall'hardware!

il vantaggio è per l'utente
aumentanto la competizione abbiamo più prestazioni a meno prezzo
e per il programmatore che
a questo punto deeve pensare solo al programma

intel non è un monopolio, ma vorrebbe esserlo!

poi non esiste solo
windows!
intel voleva di fatto "eliminare" le gpu
con il terribile progetto della gpu-x86!

in pratica voleva determinare lo standard delle gpu
quindi fine della concorrenza!
nvidia morta... amd no ma...

edit: per avere concorrenza deve esserci un quadro su cui ogni produttore può intervenire. il programmatore non vede essere chiamato in causa, ma deve avere la strda spianata, poichè i cambiamenti devono essere a monte.
sti x86, sono una minaccia!
amd dice sulla mancata produzione
di larrabee
(la gpu =tanti cpux86)
"Fin dall'inizio, abbiamo visto Larrabee come un'ulteriore conferma dell'importanza del visual computing. Continuiamo a dire che la GPU è essenziale per l'esperienza con il computer, di oggi e di domani. AMD è leader nella tecnologia GPU per la grafica 3D, il video e il calcolo", ha dichiarato Dave Erskine, Graphics Public Relations di AMD.

"Quando si ha solamente la CPU o la GPU, un'azienda è costretta a far ricorso alle proprie capacità per rispondere alle necessità dell'industria. AMD è l'unica azienda con diverse proprietà intellettuali su GPU e CPU. In risposta alla direzione presa dell'industria, stiamo mettendo insieme la CPU e la GPU nel progetto Fusion".

le apu amd sono la
a mio modesto avviso
di non esperto del campo
l'unica vera apertura a un monopolio che è un deserto
di idee
una specie di matrix, che ci fa contenti ma usa le nostre energie!

[Vash_85]

E' sempre lo stesso funboy intel...lascialo perdere.....

[lele980]

Originariamente inviato da capitan_crasy

Ci sarà sicuramente il core "Thuban" CPU AMD 6 core desktop e forse il 975 @ 3.60Ghz...

dando un rapido sguardo in rete thuban dovrebbe arrivare sugli scaffali nel terzo trimestre del 2010

molto in ritardo rispetto al core i9 che dovrebbe debuttare verso febbraio

insomma anche a questo giro amd è abbastanza indietro

gia il 965 rispetto ai core i7 soffre visibilmente.

non va bene!!, intel per inizio anno continuera a fare da padre padrone

dettando legge nel mercato

[capitan_crasy]

Originariamente inviato da lele980

dando un rapido sguardo in rete thuban dovrebbe arrivare sugli scaffali nel terzo trimestre del 2010

Thuban sarà presentato nel secondo trimestre 2010 (si parla di aprile) con la piattaforma LEO

molto in ritardo rispetto al core i9 che dovrebbe debuttare verso febbraio

Thuban dovrebbe costare MOLTO meno dei Nehalem 6 core...

insomma anche a questo giro amd è abbastanza indietro

gia il 965 rispetto ai core i7 soffre visibilmente.

non è una novita...

non va bene!!, intel per inizio anno continuera a fare da padre padrone

dettando legge nel mercato

Nel mercato conta molto il prezzo finale della CPU e attualmente i K10 hanno un buon prezzo che si abbasserà ancora nel corso del 2010...

[carlottoIIx6]

Originariamente inviato da lele980

insomma anche a questo giro amd è abbastanza indietro

gia il 965 rispetto ai core i7 soffre visibilmente.

non va bene!!, intel per inizio anno continuera a fare da padre padrone

dettando legge nel mercato

hmm se i phenom arrivano a 4GHz competono cin gli i7 in prestazioni su software che penalizza amd!
vedi guru3d recensione su 965

l'importante e che il tdp rimanga
uguale!

man mano che la frequanza aumenta il prezz resta uguale
e quindi più competitivi

965 e i5 se la giocano...
mentre gli i7 sono per chi vuole il top ed
è disposto a pagarlo... troppo direi!
penso che la grossa fetta del mercato se la giocano i5 e
phenom II!

se solo fosse confermata la mia supposizione, che amd stia vendendo i proci... peggiori e stia ammucchiando
i 975
e magari gli
985...
una notizia del genere sarebbe data solo all'ultimo momento per non interferire con le vendite del 965

[carlottoIIx6]

http://www.appuntidigitali.it/5393/l...cazioni-varie/

http://www.chip-architect.com/news/2...it_Core.html#4

"
Infine sull’argomento supporto la situazione è effettivamente quella descritta: a conti fatti soltanto Intel viene supportata, perché ha in mano la maggioranza del mercato ed è l’unica che produce compilatori di qualità (ma supporta anche il GCC) che, per ovvie ragioni, funzionano bene o esclusivamente sui suoi prodotti. I concorrenti non hanno sufficiente know-how o risorse da dedicare allo scopo, e ciò inevitabilmente gli si ritorce contro.
"


"
Secondo l’autore dell’articolo buona parte dei problemi esposti finora si risolverebbero se l’evoluzione dell’architettura fosse affidata a un collegio di aziende anziché all’arbitrarietà delle singole. Questo è in parte vero, perché eviterebbe sicuramente che ognuno reinventi la ruota (cioè istruzioni & opcode diversi per fare esattamente la stessa cosa) e costringa poi gli altri a supportarla, ma non sarebbe la soluzione definitiva, e questo per due motivi.
"

"
In definitiva il problema dei code path diversi continuerebbe comunque a esistere sia per le inevitabili estensioni (il mercato si evolve, e le ISA pure perché devono soddisfarne le esigenze) sia per le diverse implementazioni (tanto più se confrontiamo un Core Duo 2 con un Atom: le differenze sono abissali), ed è bene che i programmatori ne prendano atto…

"

il problema dell'ottimizzazione c'è addirittura all'interno della stessa casa per differenti architetture...
il decoder è comunque una piccola parte del chip... vedi secondo link citato...

qual è il problema? che intel viene supportata... non nelle differenze
prestazionali
dei chip!
Gcc (quindi linux) anche viene supportato... qui quindi emerge un quadro diverso!
ma mi sembra che Gcc non ottimizza per processore
quindi risalta di più
l'architettura

[The Incredible]

su toms parlano dei 975...

[capitan_crasy]

Originariamente inviato da The Incredible

su toms parlano dei 975...

Notizia OT...
Questo thread è dedicato alle CPU AMD a 32nm...
Comunque sia la notizia è di FUDZILLA che a sua volta la presa da altre fonti...