Analys av Kaveri-kärnan

Snubblade över en artikel på ExtremeTech som är väldigt läsvärd för det som är intresserade av en analys kring flaskhalsar i Kaveri.

Som de flesta känner till så var en misstanke kring Bulldozer-designes relativt låga prestanda per CPU-tråd att båda CPU-trådarna i en modul delar hämtning och avkodning (fetch & decode) av instruktioner. Kaveri fick separata avkodare för båda trådarna, men tyvärr visade det sig att det inte alls verkar ha varit en flaskhals i praktiken då senare delar av pipelinen inte alls kunde svälja de upp till 32-bytes som fetch/decode kan hantera per cykel.

Själv tror jag att problemet är L2-cachen ("problemet" här är mest att Intel har en L2-cache som är mycket bättre än någon annan, AMD har nästa dubbla latensen och är ändå något bättre än t.ex. senaste ARM Cortex) + att det faktiskt inte finns mer ALU-enheter per CPU-tråd i Kaveri än vad det finns i Jaguar och Silvermont.

Edit: man kan också så något som definitivt inte är en flaskhals, nämligen bandbredd mot CPU-cache. Kaveri har ganska mycket bättre framförallt skrivhastighet mot L1 och bättre både läs&skriv mot L2 än tidigare. Men att det inte hjälper borde inte förvåna, Haswell dubblade både läs&skriv mot L1 & L2 jämfört med tidigare och det gjorde i princip ingenting. IPC förbättringen i Haswell kommer i stort sätt uteslutande från back-end är 33% bredare än innan.

Man kan konstatera att bandbredd finns i överflöd i alla big-core x86 CPUer för de program som normalt körs. Är i stort sätt bara vissa typer av SSE och än mer AVX intensiva program där man behöver rejält med bandbredd. Det som behövs är att minska latens, något som i stort sätt är kört för L1 där big-core idag ligger på 4 cykler medan little-core ligger på 3 cykler (då de inte är designade för lika hög frekvens). Racet är idag kring att designa L2 (och L3 i de fall det används) med så låg latens som möjligt.