AMD FX "Bulldozer" – dagen efter

BF3 = bästa spelet just nu = Bulldozer bästa CPU just nu?

Jo detta var ju minst sagt en besvikelse. Om dom lyckas få upp prestandan rejält och fixa problemet mellan moduler och kärnor och grejer så blir det nästan nästa dator då jag i första hand är studiotekniker (där musikprogrammen redan är optimerade för dubbla fyrakärniga serverprocessorer och datorer med över 16 gb ram, 8 kärnor lär ju inte vara något problem där inte)

Jag tänker på tekniken, tekniken bakom ser enligt mig väldigt bra ut bara de de ser till att få den intrimmad.

Exempelvis måste de lösa detta problemet
http://www.tweaktown.com/articles/4348/amd_fx_8150_am3_3_6ghz...

Att skriva till L1 cachen verkar ta ungefär lika lång tid som att skriva till L2 cachen och då skall man tänka på att L2 cachen är ganska långsam i och med att den är så stor. Kanske är det just detta som är problemet, att det hänt något som gör att det inte fungerar där. Löser de denna (bara att få upp prestanda till phenom..) är det en rejäl ökning av total prestanda. Skrivningar till L1 cache är liksom en väääääääldigt vanlig operation

ÖNSKETÄNKANDE:
Tänk om AMD snart släpper en biosuppdatering där man fixar till problemet skrivprestanda till L1 cachen, att man endast gjorde detta för att sprida namnet bulldozer för maken till marknadsföring har väl ingen processor fått även om den här är negativ. Låt säga att skrivprestanda plötsligt blir bättre än phenom (vilket borde vara logiskt) och vips så lämnar den 2600K bakom sig.
Tror inte själv på denna fantasifulla teori men som det utvecklat sig vore det ett genialiskt drag

http://www.xbitlabs.com/news/other/display/20111012223953_ORN...

Verkar som åtminstone vissa ägare till stora datorer tänker köpa Bulldozer i alla fall. Där krängde de 18000 Interlagos på en gång.

Jävla massor tjat om mjukvarufixar, det enda som egentligen gör något av att operativsystemet är medveten om strukturen om moduler är att TurboCore funkar, andra mjukvarufixar (cache) ger ännu mindre. Det finns inga OS, BIOS eller trollerifixar för det hela. 2-10% prestanda gör liksom ingen skillnad här, de kommer fortfarande vara för slöa per kärna/tråd och skala för dåligt. AMD kan inte gå och vänta på Windows 8 som är långt ifrån färdigt och i dagsläget bara ett Windows 7 med en ny runtime bredvid allt gammalt. AMD kommer dessutom redan ha fått in arkitekturförbättringar innan dess. Tydligen vet dom sen länge att de misslyckades och behövde förbättra, laga och få in nya arkitekturförändring (och nya instruktioner FMA3 kommer med Piledriver). Det är inte heller så konstigt med deras roadmap. Hade det inte varit några problem så hade de inte väntat till enhanced bulldozer för att göra några Fusion-varianter. IPC-förbättringar hade man knappast planerat och lagt ut som de gjort om de inte förvänta sig situationen. 2013-14 behöver de antagligen dubbla FPUerna också.

Att det tar lika lång tid att skriva till L1 som L2 på BD är superenkelt att förklara: BD L1 cache är en en s.k. "write through" cache, d.v.s en "read-only cache". Alla skrivningar går alltid rakt igenom (därför det kallas "write through") till L2 så resultatet man skriver hamnar både i L1 och L2. Detta var en sak jag reagerade på redan förra året då detaljerna kring BD började dyka upp. Ingen x86 CPU har använt sig av "write through" cache sedan 486:an, utan de kör med "write-back" cache (read/write cache) som i.o.f.s. är mer komplicerad att implementera men skrivningar är betydligt mycket snabbare.

Edit: den mest trovärdiga förklaringen jag hittat till valet av "write through" cache på BD är just att varje BD implementerar en form av "HT". Massor med saker ÄR delade (L1I cache, TLB-cache, fetch/decode, etc). För att kunna hålla båda L1D cacharna koherenta med varandra och RAM i en miljö där mycket annat är delat så gjorde man dessa "write through" eftersom man då löste det problemet då allt också hamnar i den delade L2 cachen.
En annan orsak (som inte går på tvärsen med den första) är att en "write through" cache är mycket enklare -> lättare att klocka högt.

Efter att sett massor med resultat från alla möjliga site:er så skulle jag ändå säga att BD presterar rätt OK. Problemen som jag ser det är
* för samma pengar får man en snabbare Intel CPU
* AMD envisas med att kalla BD 8xxx för en 8-kärnors CPU, trots att skalbarheten för en modul är mer som 1.5 kärnor. En 4 modulers BD har näst intill identisk skalning med en Phenom X6.
* AMD envisas med att kalla BD 8xxx för en 8-kärnors CPU, trots att den totala kapaciteten på en modul när båda trådarna används är i nivå med en Nehalem CPU-kärna

Tror man gör sig själv en björntjänst med att kalla sina moduler för 2-kärnor. FX 8150 är endera en riktigt usel 8-kärnors CPU, eller en rätt bra 4-kärnors CPU med möjlighet att köra två trådar med CPU-kärna. Visst är det bara semantik, men det gör skillnad i hur man ser på produkten.

Intel, IBM och Oracle kallar ju inte precis sina produkter för 20-kärnors (Xeon E7, 10-kärnor, 2-trådar per kärna), 32-kärnors (POWER7, 8-kärnor, 4-trådar per kärna), 512-kärnor (Niagara T3, 16-kärnor, 8-trådar per kärna). Å andra sidan duplicerar ingen av dessa CPUer sina ALU enheter mellan trådar, detta är också något som gör att jag lite undrar hur optimal BD verkligen är för servers. BD har helt enkelt för mycket ALU-enheter för server laster, då dessa väldigt ofta inte får plats i cache och BD front-end kommer inte klara av att leverera tillräckligt med data för att hålla båda trådarna aktiva. BD var helt klart ett försök att skapa ett riktigt bra desktop-chip. Den absolut viktigaste anledningen att Intel/IBM/Oracle använder sig av SMT är att det är ett effektivt sätt att få en CPU-kärna att använda sina ALU-enheter hela tiden, trots att vissa trådar måste vänta på RAM.

Haha... Det är roligt att läsa allt snack om "Det här skadar bara Intel Fanboys" med hänsyn till konkurrensen. Det ni menar är att priserna går upp, fanboys betalar ändå. I övrigt kommer priser och utveckling att påverkas väldigt lite de närmaste åren. OM amd sen skulle ligga på ruinens brant så kommer det göras ett antal insatser just för att upprätthålla en viss konkurrens. Ni glömmer också att AMD har en strålande marknad inom bärbart och grafikkort.

Min poäng är att ni nog inte behöver oroa er över eventuell konkurrensproblematik.

Tror i princip alla processorer med olika nivåer av cache har olika trick för att få upp hastigheten, även om man har write through används kö-teknik för att minska bandbredd och få upp hastigheten.

Jag undrar om de varit medvetna efter att ha läst igenom på olika ställen. Bulldozer verkar vara riktigt strömsnål om klocken håller sig på lägre nivåer. Server processorerna ser riktigt bra ut och de är strömsnåla. Så fort man ökar klocken däremot så verkar den skena i strömförbrukning. Förmodligen har de missbedömt tillverkningen och att den process de använder där utvecklas långsammare än beräknat. Möjligen är också detta anledningen till förseningen, första försöket drog för mycket ström.

Det och problemet med skrivhastigheten till L1 verkar vara det som måste förbättras.

BD har en form av "kö" bestående mellan L1D och L2. Cachen är uppdelad i "cache-lines" som på alla moderna x86-CPUer är 64 byte. BD har tydligen gjort optimeringen att "write-through" delen kan fördröjas så att man alltid skriven en full cache-line från L1D till L2. Denna optimering fungerar någorlunda så länge som man verkligen skriver data konsekutivt. Skrivs data till mer eller mindre slumpmässiga adresser så måste man synka L1D och L2 mellan varje skrivning då data skrivs till olika cache-lines.

Ok, då man man väl lösa problemet med att göra denna "kö" större? Ja och nej
Ja: den lösningen heter "byt till write-back cache"
Nej: om anledningen till valet av "write-through" är cache-koherens så går det inte att öka storleken på kön då det skulle haverera cache-koherensen. Om detta är fallet betyder det också att L2 cache-linjen måste låsas från det att första byte:en skrivs till L1D tills dess att L2 och L1D är i synk igen. Detta kan i teorin vara väldigt dåligt för skalbarhet då den andra CPU-tråden kan blocka på en access mot den nu låsta L2 cache-linjen. I praktiken så vill man alltid undvika att två olika CPU-trådar skriver på samma cache-linje då det är extremt dåligt för prestanda, detta fenomen kallas "false sharing" och program så orsakar detta kan mycket väl se minskad prestanda när de går från att köra på 1 CPU-kärna till att köra på >1 CPU-kärna.

"Gaah AMD kommer gå i konkurs!!, BD suger blabla". Entusiast-marknaden är hur stor? 5-10%? Tror detta bara kommer betraktas som ett mindre bakslag hos AMD. Sen att dom börjar köra massa fulspel är ju mindre kul. BD är ingen dålig processor, men i nuläget är den inte tillräckligt mycket bättre än en PII x6 1100T för att vara köpvärd.
Anledningen till att man kör AMD är att dom oftast är billiga för prestandan och att moderkorten står sej mer än 1 år

Hade en snabbare men mindre L2 hjälpt?

2600k:n måste juh vara klockad för hårt.. går sämre än originalhastigheten.

Det är något annat, så fort cache uppdateras så tar den XX antal byte. Kallas för "cache line" eller "cache block". Läser programmet in en byte från adress 100 så uppdateras cachen inte med en enstaka byte utan då 64 byte om cpu's "cache line" är 64 byte

Rätt vanligt att programmerare tänker på det när de lägger data i olika objekt. Lägger man de vanligaste medlemsvariablerna övers i ett objekt snabbar det upp koden då de laddas "gratis", alltså de åker med i farten

För att cachen inte är byggd för höga frekvenser (skämt)

/cry

Vilken besvikelse det blev. Men vi hoppas ju på att AMD ska komma tillbaka nästa gång!