Uno sguardo al die dell'APU Trinity

[eric1]

Già.. dai miei (umili) test su BD la potenza della singola FPU è migliorata, ma la differenza numerica incide pesantemente laddove il software non sfrutta FMA4, xop e via dicendo. Meglio dal lato integer dove un aumento in termini di MHz potrebbe essere sufficiente.
Da segnalare per Piledriver l'adozione delle istruzioni FMA3 (che se sfruttate dovrebbero garantire un 25% di performance in più), BMI (Bit Manipulation Instructions, TBM (trailing bit manipulation) e un IOMMU(Input/Output Memory Management Unit) v2 utile in ambienti molto virtualizzati se sfruttato dal sw. In merito all'area dell'uncore pare sia un 40% superiore, grazie anche allo spazio ricavato dall'unione di due cores..Confido che questo spazio non venga sprecato..

[Alessio89]

Se adottano anche FMA3 è perché hanno cambiato strategia sulle estensioni alla AMD.
Prima era una gara fra intel e AMD e spesso vinceva intel solo perché vendeva di più, ora AMD ha cambiato tattica: AMD ha fatto cambiare idea ad intel 3 volte solo sulle estensioni FMA3 e FMA4, per non parlare di AVX e AVX-2 anticipando sin da subito l'annuncio delle SSE5 (ora XOP).
AMD ora si trova con CPU che supportano tutte le estensioni x86 sul mercato (ad esclusione di quasi la totalità di 3DNOW divenuta ormai obsoleta) mettendolo in quel posto ad intel.
In ambiente server questo significa molto visto che sarà molto semplice cambiare ecosistema mantenendo praticamente inalterato il software ottimizzato per estensioni che intel voleva avere tutte per se. Se adotteranno anche FMA3 mi domando cosa si inventerà intel per creare nuove incompatibilità a livello di assembly xD

[eric1]

La penso come te..purtroppo a livello desktop il miglioramento del sw è molto più lento..ma entriamo nel solito discorso..alla fine un utente che vuole investire al meglio i propri soldi da 90€ in su si vede costretto ad investire su Intel..

[Alessio89]

A livello desktop ormai gli sforzi per le ottimizzazioni delle librerie sono volte al gpgpu.
La colpa inoltre dell'enorme ritardo è da dare pure all'ISO/IEC che ci ha mesos ben 13 anni a far uscire una nuova versione del c++ (la 2003 non conta diamine), e solo ora il linguaddio più utilizzato in ambiente desktop e server per applicazioni che guardano le performance supporta ufficialmente il multi-threading (Stroustrup s'è pure incaxxato più volte per i continui ritardi).
Sinceramente non so quante altre nuove estensioni per le cpu si verranno a creare negli anni a venire, meglio concentrarsi sul calcolo eterogeneo e sfruttare le igp il meglio possibile, anzi meglio fare in modo che parlare di igp non sia più necessario perché scorretto.

[eric1]

Da cosa mi risulta Sandy è più avanti in questo (se così si può dire.. ) in quanto la cache L3 è condivisa dalla parte che si occupa della grafica. Probabilmente questa caratteristica apparentemente banale può essere il vantaggio che nella pratica si ottiene con il Q.Sink.(correggetemi se sbaglio), che a mio parere è un ottimo passo in avanti.