Ciao
Il memory controller per nehalem secondo me è stata una modifica doverosa. Uno dei punti critici delle architetture è che per quanto la tua cache sia ottima per quanti registri interni possiedi per tenere il più possibile istruzioni ed operandi all'interno, quanti branch corretti predici prima o poi sbagli qualcosa, quindi flush della pipeline, DMA e aspetti circa 100 cicli per trovare dati\operandi con buona pace di tutto e di tutti.
Per il discorso compiler ti posso dire che la situazione è disastrosa, per i volenterosi avevo postato un qualcosina
CASO 1: librerie matematiche
http://abinstein.blogspot.com/2007/0...ouldnt-be.html
Sunto: in SPECCPU 2000 benchmark satndard per le cpu da server i core2 distanziavano i k8 opteron di circa il 50% in INT(integers) e 25% FP(floating point) a parità di clock, SPECCPU 2006, stranamente dopo che i processori amd k8 opteron utilizzano le libreire matematiche di amd( e quelli di intel le intel) il divario cala a 20% negli INT e circa il 2% nel FP. Nota bene,
architettura k8, nessun load store reordering(uccide le performance in integers visto che 1 istruzione su 3 sono operazioni di load), instruction fetch di 16bytes (molte istruzioni int e sse sono più lunghe di 16byte qunidi altro ciclo di clock a fare l'instruction fetch), le sse con dati a 128bit richiedono 2 cicli di clock.
Caso 2: compiler
http://abinstein.blogspot.com/2007/0...-and-amds.html
Sunto:
33% di vantaggio dei core2 sul k10 in base alle istruzioni usate.
Ovviamente tutto ciò in mia opinione.