Chipset AMD serie 7, la base dei sistemi Spider

[MiKeLezZ]

Originariamente inviato da dagon1978

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

Va bene, allora non è un bug minore, ma bensì un bug grosso... bello grosso... 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?

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

[dagon1978]

Originariamente inviato da MiKeLezZ

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

Va bene, allora non è un bug minore, ma bensì un bug grosso... bello grosso... 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?

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?

[Errik89]

Originariamente inviato da MiKeLezZ

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

Va bene, allora non è un bug minore, ma bensì un bug grosso... bello grosso... 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?

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

[MiKeLezZ]

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.

[dagon1978]

Originariamente inviato da MiKeLezZ

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"

[Errik89]

Originariamente inviato da MiKeLezZ

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

[capitan_crasy]

Originariamente inviato da MiKeLezZ

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

[MiKeLezZ]

Originariamente inviato da Errik89

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

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?pag...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."

[Crystal1988]

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da dagon1978

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"

Originariamente inviato da Errik89

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

Originariamente inviato da capitan_crasy

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

Io vorrei aggiungere inoltre la storia della ricompilazione:

http://www.hwupgrade.it/forum/showpo...&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.

[Crystal1988]

Originariamente inviato da MiKeLezZ

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

[MiKeLezZ]

Originariamente inviato da Crystal1988

Io vorrei aggiungere inoltre la storia della ricompilazione:

http://www.hwupgrade.it/forum/showpo...&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=2...0_9600_9700-20
Dove si afferma come il Phenom 9700 (2,4GHz) è indietro rispetto al Q6600 (anch'esso 2,4GHz) del 10%, e questo non tiene conto del fatto che il 9700 esista solo sulla carta (mentre il Q6600 è l'entry-level dei Quad-Core), che Phenom sembra non superare i 3GHz (mentre per i Core 2 Duo si arriva anche a 3,6GHz), ma soprattutto che, come è stato detto, i Penryn offriranno il 5% (in media) di prestazioni in più rispetto i corrispettivi attuali... E quindi la forbice è destinata ad aumentare del 15% a vantaggio di Intel (sempre clock to clock, e sempre dimenticando che i Penryn potranno arrivare anche a 4GHz).
Certo non riesco a sperare in correzioni di bug che donino il 15% di prestazioni in più e permettano clock di 3GHz (neppure possibili con CPU meno sosfisticate e più rodate come gli attuali Athlon X2).
Sarò pessimista?

[Crystal1988]

Originariamente inviato da MiKeLezZ

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

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

[MiKeLezZ]

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

[Crystal1988]

esattamente. è inespressa.

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

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

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

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

[Maxt75]

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.

[schwalbe]

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

[Crystal1988]

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.

[K7-500]

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

[Crystal1988]

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

[Crystal1988]

Originariamente inviato da K7-500

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