Newsgroup: it.comp.hardware.cpu
Titolo: AMD APU Trinity, anticipazioni sull'architettura

Su VR-Zone alcune anticipazioni sull'architettura della nuova
APU Trinity di AMD che sara' presentata ufficialmente il prossimo
15 Maggio :
http://vr-zone.com/articles/amd-trinity-apu-preview-evolution-or-devolution-/15716.html
 
 
 
 
Ciao
Luca
 
 
 
 
 
 
 

 ha scritto nel messaggio news:4fa0eb59$2$1387$4faf...@reader2.news.tin.it...


 
http://news.softpedia.com/news/AMD-Trinity-Architectural-Preview-Part-II-267131.shtml
 
 
e' una polemica "vecchia" :)
(l'articolo su shashdot e' del 2005)
 
con i compilatori open la situazione cambia poco (Phoronix),
l'unico vantaggio e' il path con flag "bdver1" del GCC
ma credo che Intel non lo implementera' mai ..
 
 
ciao
luca
 
 
 
 
 


Il problema non è Intel, alla quale, in fondo in fondo, non mi
sento di darle tutti i torti...
Il problema è il compiler di Microsoft...che non viene mai aggiornato
con le ultime (ultimissime) istruzioni...quindi lo usano in pochi...
Per non parlare dello snobbato compilatore di AMD...
 
-- 
-----------------------------------------------


 Per non parlare dello snobbato compilatore di AMD...
 
in sintesi la colpa e' dei programmatori ?
 
non vogliamo ricominciare con i compilatori anche adesso
che esce Trinity con l'aggiornata architettura Piledriver ? ;)
 
a tal poposito avevo aperto una discussione a fine Febbraio :
"Confronto tra compilatori Intel, Microsoft e GCC con FX, PII ed i7"
test su 
hardware.fr
 :
http://www.hardware.fr/articles/847-1/impact-compilateurs-architectures-cpu-x86-x64.html
 
 
se vuoi possiamo discutere su questi risultati o se ne hai altri
"recenti" con FX , possibilmente diversi da Phoronix perche'
ne ho segnalati molti e li conosco a memoria ;)
 
ciao
luca
 
 
 
 
 


Non sono informato a tal punto da poter avviare una discussione.


 Dovrebbe "tirarsi su le maniche" e tirar fuori una CPU performante...
 
in passato, secondo me, la differenza tra le CPU era tale che
una ottimizzazione del compilatore, piuttosto che una penalizzazione,
incideva di piu' nel risultato finale, mentre oggi, generalizzando,
c'e' una differenza di prestazioni che prescinde dal compilatore
 
anche secondo me e' colpa di AMD che negli anni non ha
sponsorizzato una soluzione propria, ad esempio quando le sue
CPU erano decisamente piu' competitive, negli ultimi anni, invece,
si e' trovata a rincorrere (K10) e con un'architettura nuova (BD) ,
in queste condizioni e' piu' difficile che riesca a proporsi in modo
aggressivo, o comunque non nel medio termine (ammetto che
sono tutte speculazioni e che lasciano il tempo che trovano)
 
al contrario, trovo che AMD si stia muovendo bene nel campo del
GPGPU, motivata sia dalle soluzioni GPU discrete che integrate (APU)
 
neanche io sono un esperto di compilatori ma leggendo fonti
ritenute imparziali (Phoronix) e siti competenti (
hardware.fr
) ,
mi son fatto un'idea della situazione, dopotutto i numeri
parlano da soli ;)
 
ciao
luca
 
 
 
 
 


 
magari AMD potrebbe tirare furi un compilatore miracoloso, magari no. Ma una 
cosa rimane li scolpita nella roccia: per arrivare a certe prestazioni i 
consumi salgono salgono.. in modo abbastanza indecente. Che facciano un 
compilatore che tenga giu' i consumi... (scherzo, ha poca attinenza).
 
Ma semplicemente dico che se per stare alla ruota del carro grande (Intel) 
AMD ha tirato fuori dei prodotti affamati di energia.. e' come 
autocertificare che non hai una buona architettura, se non la hai e' anche 
inutile sperare in un compilatore miracoloso. Se nel 90% degli scenari d'uso 
perdi e in un 10% vai meglio, non e' che sia una bella situazione, con quel 
10% fai il gol della bandiera per cosi' dire.
 
Il discorso preciso che non lo sto riferendo a Trinity ma alla generazione 
dei vari am3+ attuali 
 

 inutile sperare in un compilatore miracoloso.
 
Questo è vero, ma puoi sempre fare in modo di gestire al meglio i 
thread per quanto concerne l'allocazione delle risorse...sempre meglio 
di niente.
 
 

 condizioni di utilizzo medio e basso della cpu.
 
credo che l'unico vantaggio pratuci dei p-state programmabili
via software sia nella gestione della frequenza minima e massima
 
perche' le frequenze intermedie andrebbero "calibrate" ad hoc,
sistema per sistema in base alle applicazioni usate, altrimenti
si rischia di peggiorare il funzionamento cosi' come previsto da AMD
 
se un determinato sistema necessita di una certa potenza
elaborativa per compiere determinati task, occorre impostare
i p-state intermedi in modo che non si superi la soglia
di intervento per arrivare al P0 , ad esempio :
 
P3 idle
P3-P2 navigazione, office, multimedia in genere
P2-P1 grafica, editing audio/video, visione filmati HD
P0 full load
 
purtroppo non e' cosi' semplice ed alla portata di tutti,
inoltre occorre diverso tempo per rendere il sistema
stabile in ogni condizione d'utilizzo, ovviamente per
chi e' pratico e' uno strumento in piu' :)
 
ciao
luca
 
 
 

 dei vari am3+ attuali
 
concordo, la storia e' piena di corsi e ricorsi :)
 
purtroppo la strada imboccata da AMD con Bulldozer non
e' power-friendly (frequenze elevate) , anche se un po' e'
colpa del processo produttivo "acerb" (GF 32nm)
 
con il core Piledriver presente in Trinity si dovrebbe gia' avere
un miglioramento, promesso maggior IPC e diminuzione del leakage,
anche se non bisogna affidarsi alle "sole" slide ("sole" con doppio
senso LOL)
 
ciao
luca
 
 
 
 
 

 si rischia di peggiorare il funzionamento cosi' come previsto da AMD.
 
Puoi anche giocare con la tensione di alimentazione per ogni P-State 
intermedio... ma concordo che è un lavoraccio.
 
 

 luca
 
eheh che sole! (triplo senso, sto guardando fuori dalla vetrata del 
laboratorio..) 
 


 
Infatti...concordo...


atrejus ha usato la sua tastiera per scrivere :

lol
 
 

 passi pure dalla scheda video...
 
avevo letto solo il titolo della news ma non avevo approfondito,
considerando che le schede video sono sempre esistite e che
il GPGPU inizia ad avere alcuni anni sulle spalle (5+) , e' quasi
ora che venga sfruttata questa possibilita', che sia discreta o
integrata
 
intanto Rory Read continua a riorganizzare il direttivo
 
 
Intel e' indietro sotto questo aspetto, solo con Sandy Bridge
e' riuscita a tirar fuori qualcosa di diverso dalla solita integrata
(nel chipset) che serviva solo a visualizzare il desktop :)
 
secondo me SNB e' la fase "alpha", IVB la "beta" e con Haswell
si dovrebbe arrivare ad un prodotto hardware "finale", il problema
principale e' lato software (driver)
 
nel frattempo :
http://www.hardocp.com/news/2012/05/04/new_intel_media_sdk_supports_bluray_3d_open_cl/
 
 
 
l'FPU tradizionale sparira' quando ci sara' l'astrazione completa
di tutte le componenti della CPU , cioe' quando il sw potra'
accedere al core x86 o alla GFX  in modo trasparente
 
ciao
luca
 
 
 
 
 


 
Quello si che sarà un cambiamento epocale...:)
 
 

 accedere al core x86 o alla GFX  in modo trasparente
 
Dubito succedera`, dato che in quel caso quale
CPU si abbia, x86, PPC od ARM, non farebbe piu`
differenza. Il che non va bene ad intel, forse
neanche ad AMD.
 
bye,
 
-- 
 
piergiorgio

 accedere al core x86 o alla GFX  in modo trasparente
 
La vedo difficile, non e' un problema di unita' funzionali ma di come
queste sono organizzate insieme al sottosistema di memoria.
Quel che voglio dire e' che se e' certamente possibile scrivere un
pezza di codice che esegua sia sulla CPU che sulla GPU, e' alquanto
probabile che le prestazioni non saranno granche', perche' certi
algoritmi vanno proprio scritti in modo diverso per adattarsi
all'architettura della CPU (pochi thread potenti) rispetto alla GPU
(SIMD/vettoriale massiccio). Certi task si adattano meglio ad una
architettura e altri all'altra e non puoi astrarre questo a meno che
il sw stesso capisca come ristrutturarsi e dove girare a seconda della
piattaforma hw sottostante (in modo trasparente per il programmatore),
e non lo vedo succedere tanto presto :)

Pleg ha detto questo venerdì :

Certo, ma ihmo questo tipo di approccio sarà il futuro :)
Già con le attuali gpu ad esempio è possibile fargli elaborare (con 
tutte le limitazioni del caso) istruzioni sia vettoriali che scalari.
 
 

 tutte le limitazioni del caso) istruzioni sia vettoriali che scalari.
 
Ma e' quello il problema: "con le limitazioni del caso" :)
Anche io una volta ho scritto un pezzo di codice scalare in CUDA, le
prestazioni facevano cagare :) e le prestazioni per watt lasciamo
stare.
E' inevitabile, quello hardware e' costruito per processare dati
paralleli, se provi a fargli fare qualcos'altro fa schifo, per questo
sono molto scettico su una "trasparenza": puoi rendere il codice
trasparente, non le prestazioni.
Un modo potrebbe essere dare dei suggerimenti nel codice del tipo
"questa parte e' sequenziale, questa parte puo' essere paralllizzata",
ma cmq dipende anche da che tipo di parallelismo si tratta, e di che
tipo di granularita' hai (un grosso blocco parallelo potresti metterlo
in una funzione di libreria e chiamarla dal resto del codice, come
cuBLAS e cose del genere, ma granularita' fine la vedo molto molto
dura).

Nel suo scritto precedente, Pleg ha sostenuto :

Chiaramente dovranno evolvere anche i tool di sviluppo oltre che 
l'hardware... ho fatto solo un esempio in cui già oggi si sfruttano le 
gpu per far svolgere istruzioni nativamente non compatibili col suo set 
originale.
 
Tutto ciò richiederà del tempo, ma alla fine si arriverà a questo tipo 
di approccio ihmo... tra l'altro (esulando un pò dall'argomento 
specifico), la stessa AMD prevede che con l'introduzione della futura 
architettura Excavator avvierà il supporto all'Unified Space Address, 
dove cpu e gpu condivideranno lo stesso spazio di memoria, al contrario 
di quanto accade attualmente e all'HSA.
 
http://www.anandtech.com/show/5493/amd-outlines-hsa-roadmap-unified-memory-for-cpugpu-in-2013-hsa-gpus-in-2014
 
 
 

il problema principale e' lato software (driver)
 
Non ho capito cosa intendi... :(


 neanche ad AMD.
 
non so a chi convenga di piu' o di meno ma potrebbe
essere un'ulteriore passo avanti nel progetto di "fusione"
CPU/GPU (nel medio-lungo termine)
 
 
ciao
luca
 
 
 
 
 
 
 

 Non ho capito cosa intendi... :(
 
voglio dire che AMD ed NVIDIA rilasciano driver grafici con
scadenza mensile , con bug fix e miglioramenti continui
(talvolta miracolosi) e possono contare sulla collaborazione
diretta con software house di giochi e community di milioni di utenti
 
Intel non potra' mai competere sotto questo aspetto e credo
che non le interessi piu' di tanto (al momento), basti pensare
che e' arrivata ad una soluzione DX11 con 3 anni di ritardo :/
 
di Haswell si sa poco, non ci si aspettano miracoli e neanche
che possa competere con le soluzioni entry di AMD/NVIDIA ,
pero' con il raddoppio delle prestazioni attuali e con un'ulteriore
"GT3" , potrebbero diventare un prodotto finito (forse maturo ?)
e garantire un'esperienza d'uso "dignitosa" in ambito portatlle
(o ultraportatile) e, perche' no, anche in ambito desktop ..
.. driver permettendo :)
 
anche il supporto OpenCL delle HD2500/4000 IVB non e'
completo, per questo lo ritengo un progetto ancora in fase
preliminare, la strada e' lunga per Intel :)
 
ciao
luca
 
 
 
 
 
 
 

 ha scritto nel messaggio
news:485360d9-570c-4f46...@c18g2000pbu.googlegroups.com...

infatti non ho detto che succedera' adesso, era una risposta
all'ipotetica sostituzione della FPU con "qualcosaltro" ,
ammesso che il software possa accedervi in modo trasparente,
potrebbe essere un passo avanti nel progetto di "fusione"
auspicato da AMD
 
ciao
luca