Två processorer i AMD FX-serien släpps den 19 september

Men hela min poäng var ju just att bara "kärnor" inte spelar någon roll.
Så hur kan jag ha fel när det du säger är ett argument för det jag sade?
Om du tycker att det var ett dåligt exempel, så visst. Tyck det.
Men det är inte "fel".

EDIT: Alltså, detta är bland de märkligaste diskussionerna jag varit inblandad i på senare tid.
Som exempel på att prata om "kärnor" kan vara missvisande tar jag ett exempel som är väldigt väldigt annorlunda men ändå har samma antal "kärnor".
Någon tycker jag har fel eftersom mitt exempel inte är x86 och därför väldigt annorlunda, vilket just var min intention. Inte att nödvändigtvis säga något som inte är x86 men att ta något som var väldigt annorlunda men som ändå pratas om som att det har samma antal "kärnor".
Du håller med om min poäng och både bekräftar och förstärker den men tycker samtidigt att jag har "fel".
Kan någon annan förklara det här för mig?

Nej.
Men vi är rätt klara här.
Och jag tror inte att det jag sade bevisar något öht, det var ett illustrativt exempel. Inte ett bevisande exempel.

EDIT: Och det var inte att antalet kärnor inte spelar någon roll utan att snacket var så upphängt på kärnor istället för faktisk prestanda och övriga detaljer. Och då är alltså just KÄRNOR intetsägande utan att prata om någonting annat. Precis som Cell-kärnor är jämfört med Bulldozer.
Om man enbart fokuserar på kärnor så är dom likvärdiga, om man tittar på ett uns mer information än bara antalet kärnor som står i PR-materialet så visar sig en helt annan bild.

EDIT2: Fan! Trodde jag var klar men det kändes så svårt att lämna en diskussion som är så långt ut i skogen mot var den borde vara.

Sluta påstå eller skriv saker om mig i trådar som inte stämmer. Du kan ta det jag skrev personligt att du inte kan diskutera på samma tekniska nivå då du senast blev överbevisad och hade fel i en diskussion som handlade om TDP, olika tillverkningsprocesser och effekt kontra temperatur. I detta fallet komma med någon invändning eller skriva en egen FAQ eller något annat åt det mer konstruktiva hållet. Vad levererar du till forumet om man jämför?

Sen skrev du:

Ett HD4870 har 800 kärnor, inte fan kostar det 2500kr. Ungefär lika dum och meningslös jämförelse.

Kan alla inblandade i den här diskussionen ta den någon annanstans tack. Mer än hälften av alla posts i den här tråden handlar inte om rubriken.

Några kommentarer till kommentarerna till denna artikel.

TDP
Har sätt massor med gånger hur folk hävdar att TDP skiljer sig mellan AMD och Intel. Och många hävdar att t.ex. TDP på 95W på AMD motsvarar en lägre strömförbrukning än TDP på 95W på Intel.

Det är FEL. En gång i tiden användes inte TDP utan något som kallades "typical thermal power" och detta mått skilde sig mellan Intel och AMD.

TDP = den kyleffekt som kylaren minst måste ha för att CPUn ska fungera på ett tillförlitligt sätt. AMD och Intel mäter på exakt samma sätt.

Vill också göra en kommentar om AMDs vs Intels "hyperthreading".

1. Den korrekta termen är SMT. Hyperthreading är bara Intels namn på deras SMT implementation.
2. Både Sandy Bridge och Bulldozer har samma maximala teoretiska prestanda på de två trådar som tillhör samma "modul". Anledningen är att i både SNB och BD så delar de båda trådarna på den logik som utför "prefetch", "decode" samt "retire" stegen av pipelinen..
3. BD har duplicerat alla ALU för heltal medan de båda trådarna i SNB delar ALU enheter.

Så i praktiken borde BD vara mer effektiv när båda CPU trådarna i en modul används förutsatt att båda trådarna använder SAMMA ALU enheter. Om de använder olika ALU enheter så har BD inte ens en teoretisk fördel mot SNB. AMD hävdar 80% effektivitet på trådarna när båda används samtidigt, vilket betyder att en modul motsvarar 1.6 "riktiga" kärnor. Hyperthreading brukar kunna ge motsvarande 1.3-1.6 "riktiga" kärnor, lite beroende på arbetslast. Så om det AMD säger är sant (vilket verkar helt rimligt) så är en modul på BD mer effektiv än två trådar på SNB.

Har själv jobbat en hel del med att optimera kod för HT och att få ut "1.6 kärnor" är definitivt möjligt på SNB om koden består av en mix av flyttal och heltal (har faktiskt lyckats få 1.7). Tänker man lite på det är det inte så svårt att förstå varför just den kombon blir effektiv, man CPUn kan omväxlande använde flyttals ALU och heltals ALU på de två trådarna så ingen tråd behöver vänta på "sin" ALU enhet.

Håller däremot inte med AMD om att FPU kan ersättas med en GPU. Det finns vissa saker man kan göra på en GPU och dessa saker utförs mycket mer effektivt på en GPU än på en FPU. Men det finns långt mycket mer där strömmen av instruktioner är en blandning av heltal, flyttal och eventuellt hopp. Sådan kod är extremt ineffektivt att utföras på en GPU. Sedan börjar flyttalsprestanda bli rätt imponerande även på CPUn med AVX som kom med SNB. Tyvärr kommer AVX prestanda vara rätt dåligt på BD då dess FPU inte är 256-bitars som SNB. BD kör 256-bitars AVX instruktioner genom att beräkna halva resultatet ena klockcykeln och andra halvan nästa klockcykel.

BD decode sharing and AVX impl.

Sålänge dess Front-End i Bulldozer orkar med flödet till ALU'erna så som det är sagt så ligger flertrådsteknologi efter. Du kan också få minskad prestanda med flertrådsteknik vilket aldrig händer med en CMP lösning eller i detta fallet Bulldozer. Sen ang FPU'n hos Bulldozer så kan du lära dig hur den fungerar här då det riktigt inte är så enkelt:

http://blogs.amd.com/work/2010/10/25/the-new-flex-fp

Att CMT inte kan leda till lägre prestanda är fel. Många naiva sätt att göra program multitrådade leder till att programmet går långsammare. Men SMT har ett extra sätt man kan få lägre prestanda än CMT då båda trådarna i HT delar L1 cache så tävlar de också om denna resurs. I CMT lösning varje tråd sin egen L1 cache. BD ligger mitt i mellan dessa, båda trådarna delar en 64kB stor L1I cache, men har separat L1D cache på 16kB var.

Tack för länken på FPU i BD, David Kanter på RealWorld Technologies är extremt kunnig, men han skrev artikeln om BD för ca 1 år sedan och AMD gav honom inte all information han frågade efter, så det verkar som om han fått lite felaktig information om FPUn. Det man dock bör ha i åtanke när man läser din länk är att den är skriven av AMD, så den är inte precis opartisk. Sedan tycker jag AMD har konstig definition av 256-bitars FPU. Den består av två st 128-bitars FMAC enheter, vilket inte riktigt är samma sak som en 256-bitars enhet (som SNB har). Har man två st 128-bitars enheter så betyder det 128-bitars databredd vilket i sin tur betyder att AVX instruktioner endera kan delas upp mellan enehterna (låter dyrt/komplicerat) eller att AVX instruktioner tar 2 cykler att slutföra (något David Kanter tror) fast det är då möjligt att köra två AVX instruktioner parallellt. Att en delad FPU är så effektivt som AMD påstår motsägs även av dessa läckta siffror där man jämför ett "engineering sample" av BD mot Magny-Cours. Visst är det inte den "riktiga" BD, men då testet är gjort i år lär inte AMD ändrat allt för mycket + att BD presterar ungefär som väntat, bättre än MC på heltalt sämre på flyttal räknat per klockcykel. Men vi lär se hur bra/dåligt BD är om ca 2 månader.

Samma sak gäller huruvida BD SMT implementation är bättre/överlägsen SNB. Intel har en långt mycket bättre branch-predictor än AMD och BD kommer inte täta detta glapp. En av de absolut vanligaste anledningar till pipe-line stalls är att front-end delen måste slänga bort allt jobb den gjort då den spekulerat fel. Så det är helt omöjligt att säga vilket som blir mest effektivt av
* Lite sämre front-end + duplicerade heltals ALU enheter
* lite bättre front-end + delade ALU enehter

Även SNB kan i många fall köra BÅDA trådarna en given klockcykel då det finns 5 exikveringsportar och båda trådarna kan köras helt eller delvis samtidigt om de använder olika portar. SNB kan, precis som BD, maximalt köra 4 instruktioner en given klockcykel, så med "delvis" menas t.ex att en tråd kör 2 instruktioner och den andra 1 eller att båda trådarna kör 1 instruktion var. Det är relativt ovanligt att det faktiskt går att köra 4 instruktioner per klockcykel i alla fall utan HT.

Edit: värt att nämna är också att HT på SNB är i vissa fall, t.ex fallet jag hade med blandning av FPU+Integer instruktioner, långt mycket mer effektiv än HT på nehalem. På programmet i fråga fick jag ca 1.4-1-5 gångers ökning av HT på Nehalem men hela 1.7 gånger på SNB. En stor förklaring till detta är att SNB har också något som Intel kallar "trace cache" eller L0 cache. L0 cachen är bara för instruktioner och innehåller avkodade instruktioner i CPUs interna format, så en träff i L0 betyder att fetch/decode steget inte behöver köras vilket i sin tur betyder att den andra HT-tråden får hela front-end delen för sig själv. Det betyder också att den effektiva längden på pipe-line:en i SNB blir något kortare än den fysiska som är 16 eller 18 steg (är inte helt säker). BD har ingen motsvarighet till SNB L0 cache

Mer sällan skulle jag skrivit för att vara petig. Det har bevisats genom många år då flertrådsteknologi implementerades att det är svårt att konkurrera mot en CMP. Dock går det att argumentera för att det är en ruggigt effektiv lösning per transistorantal, men i denna aspekt ser Bulldozer's modul-uppbyggnad mer lovande ut, vilket vi snart får se.

Vad en processor är rent tekniskt kapabel till så är det bara bra att den informationen kommer från AMD då dom är dom ändå som vet och knappast skulle ljuga om en lovad feature. Finns även ganska mycket mer info att tillgå genom Bulldozer software optimization guide som styrker informationen. Den nya flyttalsenheten i Bulldozer verkar lovande och den bör vara rejält mycket snabbare än tidigare FPU i K10 per tråd. Värt att notera är också att man har dedikerade schemaläggare för både heltalsenheterna och flyttalsenheterna i Bulldozer.

Enligt informationen som jag tolkar det så kan FPU'n agera som 1x256-bit till antalet av 4st hos en 8 kärnig Bulldozer eller 8st 128-bit FMAC's. Hur AVX breder ut sig återstår att se, och det är endast i detta fall man kan ha nytta av en stor 256-bit FPU. Den ska vara mycket fexibel (om du läste hela blogginläggen av JF-AMD så går han ganska djupt inpå varför, speciellt lite längre ner) vilket innebär I många av fallen tror jag att den kommer skina i flyttalsberäkningar, speciellt i äldre applikationer förutom x87 vilket är irrelevant idag. Dom tester som finns går verkligen inte att styrka som äkta eller att det skulle vara relevant till processorns prestanda i dess slutgiltiga stepping. Vi får helt enkelt vänta.

Jag har länge argumenterat för att Bulldozer på många vis måste ha en komplett stark front-end. Det här är desto mer intressant. Hur du uttalar dig om Bulldozer's branch predictor förstår jag inte riktigt då ingen vet. Det är väldigt stora förändringar hos Bulldozer's front-end av något, och speciellt dess branch predictor, som dels blir viktigare med dess längre pipeline och för att sen hitta träffar för att fetcha instruktioner till 2 heltalsenheter och leverera 80% prestanda av dess typiska 100%. Man har även separerat branch och fetch hos BD, och branchen ska tydligen också ha en motsvarighet till trace-cache där den kan köa framtida adresser till fetch. Vid felförutsägelse utav branch så kan den fortsätta fylla sin "kö-cache" med adresser. Genom att fetchen kollar igenom branchkön kan den upptäcka framtida missar i L1 cachen. Det har och andra sidan sitt bakslag jämfört med designen i K10, men passar Bulldozer bättre med sin design. Eftersom det rör sig om en mycket speciell cache så vet jag inte hur denna relaterar sig till den cache-hierarki som vi än så länge vet om Bulldozer, men det lär uppenbara sig!

Decode steget hos Bulldozer lär vara en stor styrka också. Vi har branch-fusion hos nåde BD och SB. Hurvida dessa är utav komplex eller simpel typ gör det avgörande för flödet beroende på instruktioner. Man minns att detta hade stor inverkan hos K7 versus P3 på sin tid då P3 bara hade 1 komplex decode enhet.

Vi har en intressant tid att invänta. Skulle BD i värsta fall göra folk besvikna så har dom gjort ett enormt steg som kommer minska gapet och snabba upp deras utveckling på processorsidan. Bulldozer som design är en ny grund med enorm potential och något dom kallar MSPACE. Global foundries kommer också denna gång se till att AMD har tillverkningsresurserna. Det ser lovande ut. Det är inte varje dag den ena av världens viktigaste processortillverkare släpper en helt ny mikroarkitektur (~12 år sedan K7).

Bulldozer har INGEN flertrådsteknologi. Vart i hela världen har du fått det ifrån? Det är 8 kärnor och 8 trådar, inget annat.

Ja, i5 är ett väldigt stabilt val och det är ingen större mening med att vänta.

Eller så får man en lika bra processor fast med åtta kärnor i Bulldozer. Den som lever får se.

Om processorn är lika bra är det väll helt ovesäntligt hur många kärnor den har.

Ja helt rätt men oddsen är ju betydligt högre för att en processor med åtta kärnor presterar bättre än en med fyra kärnor i program och uppgifter som faktiskt drar nytta av 4+ kärnor. Ja, jag vet att de antalet program är minimala men min poäng är att om Bulldozer matchar SB i prestanda i spel och normala uppgifter så är det ju liksom mer grädde på moset att ha en åttakärnig processor kontra en med fyra.

Ungefär som att köpa 8GB RAM minne istället för 4 GB om priset är detsamma, fast det är extremt sällan en normal datoranvändare och PC-spelare kommer i närheten av behovet av 8GB så köper man ju hellre åtta för det är helt enkelt lite mer för pengarna.