AMD FX "Bulldozer" – dagen efter

Om du har en "write-through" cache L1 så måste VARJE byte även skrivas till L2, inte enbart hela cache-lines. Det jag försökte säga är att BD har en form av kö mellan L1D och L2 som rent implementationsmässigt består i en buffer som delas mellan båda kärnorna. I denna buffer kan man spara upp till en hel cache-line innan det faktiskt skrivs till L2.

Och sedan jobbar jag med att skriva multicore optimerad programvara, så har lite koll på detta. Som tips bör du inte använda ditt eget tips ovan då det ganska lätt leder till "false sharing". Du ska i stället dela upp dina variabler i "read-only/mostly" och de som är "read/write". De som är "read-only/mostly" ska INTE ligga på samma cache-line som ditt lås (mutex/spinlock) eller någon annan variabel som du tänker skriva i då detta triggar trafik över bussen för MESI protokollet. Det verkar som AMDs val av "write-through" cache är just p.g.a. av att de vill slippa implementar MESI för L1D cachen, vilket inte behövs om man vet att L2 alltid innehåller samma sak och L2 delas mellan kärnorna. Däremot måste man använda MESI mellan L2 på olika moduler.

Har hört många säga nu att man borde "bryggat gapet" med en Phenom III. Som om det vore en smal sak. Det skulle naturligtvis kräva stora resurser för att föra lyckas med detta, och väldigt snabbt är man inne i samma återvändsgränd igen och behöver en helt ny arkitektur. Tror inte AMD har råd att utveckla två stora projekt samtidigt.. dessutom ska det sättas i produktion hos GF som redan är överbelamrade.. Nä, det verkar inte vara en bättre ide med Phenom III än Bulldozer

Enligt prestandamätningar (om de stämmer) så verkar det just att denna kö inte fungerar

Du är inte unik med det..
Att designa en cache utan kö när det gäller skrivningar begriper vem som helst som sysslar med med trådad programmering att det är riktigt korkat eftersom det är något alla som trådar upp kod undviker. Varje tråd håller sin egen "state" och så fort två trådar skriver till samma minnesadress behöver synkroniseras.
Att designa cache efter att direkt uppdatera L2 för skrivningar till L1, så dumma kan inte ingenjörer på AMD vara.

virtual_void: En Niagara-cpu (som T3) har inte 8 st fulla front-ends med logik för allt med sina 8 st kärnor av både ALU/AGU + FPU/SIMD exekveringsenheter på deras 128-trådiga cpu. Det är inte så det fungerar, på T1 hade du ju 8 kärnor med ALU/AGU och en flyttalsdel, 4-trådar per heltalsenhet, och då alltså bara en helt komplett front-end för hela processorn. Vad du kallar kärna har väl snarare med hur pipeline och körning av instruktioner sker. En heltalsberäkningsenhet har ju bara en uppsättning L1-cache men har för det mesta flera uppsättningar heltalsblock av aritmetik och adressgenerering. Hade du dessutom gått på det spåret och delat resurserna på riktigt på mer samma sätt, så hade du med CMT på desktop-Bulldozer fortfarande inte fått någon prestanda i dugliga termer, du hade ju istället kört 4 st trådar på en modul t ex, fördelen har väl varit om du kunde mata den delade FPUn snabbare. I Niagara har alltså hela processorn delade resurser. På sitt sätt. T2 och T3 har fler ALUs per kärna än T1, som de kallar för hela heltalsenheter då med delad LSU för att klara extra heltsalsbelastningen. Det AMD kan göra är väl egentligen att ge upp att köra sin CMP-design (plus CMT) på Bulldozermoduler och istället där de tagit bort ena heltalsberäkningensdelen, bara köra en tråd per modul och köra fler kärnor genom att lägga ut fler block av "moduler", eller så får de ta och fixa sina 4 st frontends för det är ju främst front-endprestandan som lär vara lägre även om de traditionella heltalsberäkningsenheterna rent arkitekturmässigt lär vara slöare. Så mycket cache som de har lär inte behövas om de fixar det hela. Halvering av cache hade ju minskat storleken med 400 miljoner transistorer. Hur som helst förväntar jag mig inte så värst prestanda ur Enhanced Bulldozer/Piledriver där de bärbara processorerna bara kommer att vara två-modulsvarianter och egentligen ska ersätta AMD 4-kärnorvarianter av Stars-arkitekturen. Någon desktop-mainstreamvariant av Bulldozer får vi väl inte fören 2013 heller om inte FM2 kommer ut. AM3+ är inget kort AMD kan ha i rampljuset nästa år iaf, är nog hyfsat ointressant även om de får nya processorer.

Det är hur som helst hur pipeline ser ut än hur många frontends och separata fetch/decodesteg av x86-instruktioner snarare. Prestandan är sämre än deras förra kärnor än så länge, men nog är det 8 st pipelinade kärnor av det hela där 8 st trådar kan köra på 8 st heltalsberäkningsenheter och 4-st dual-issue flyttalsenheter som ska kunna hantera 8st 128-bit operationer per cykel. Men som det ser ut nu verkar de inte kunna hantera resurserna särskilt bra och verkar ha problem på lägre nivå än så. Delad cache är ju för övrigt något Intel fått ut bra prestanda av på x86. Nog går det att göra bättre även på den arkitekturen.

Ni som diskuterar, i övrigt så har AMD redan Stars/K10-kärnorna på 32nm i Llano, så enkelt är det med den saken. Dual-die-variant MCM av Llano är inte svårare än Magny-cours eller annan SMP. Och nog är kärnorna så syntetiserade att de lär kunna stoppa in fler kärnor i Llano precis som de gjorde med Thuban. Mer resurser än så behövs inte. Det var därför jag nämnde Llano/Stars som en väg där de kan få ut lite mer prestanda istället för att bry mig om AM3+ och 45nm-processorer. Även om det inte finns något L3 där. Enhanced-Bulldozer kanske kan lyckas bättre också, men det krävs mer än IPC-förbättringar, 4-instruker (x86) per cykel och modul lär väl vara tillräckligt. För att de ska ligga bra till behöver ju den enkärnor/entrådade prestandan upp ca 50%. Det är en hel del det. Vi får se hur mycket de tar sig över Stars-kärnorna om något halvår eller när vi nu ser Piledriver.