Processorexpert hävdar att Woodcrest är underlägsen

Men det är väl rätt känt att det är så? (det som swec. har skrivigt i alla fall).

Det i sig betyder ju heller inte inte att Woodcrest är dålig/sämre/underlägsen.

Delat är sämre än dedikerat? Nähä?

Jag tror han är AMD fanboy ^^

AMD är för roliga. "Allt som Intel gör är sämst, och allt vi gör är bäst." Visst de kanske har en poäng... ibland.

/Adrian

han hade poäng i det han sa, spelar sedan ingen roll vem som skriver det.

underlägsen var väl till att ta i så byxorna spricker

sen kommer en riktig opteron killer: whitfield med 4 cores.
intel kan göra förbättreingar säker men jag tro inte den är underlägsen

Han kanske har en poäng, men han undviker givetvis de två uppenbara invändningarna som är hela anledningen till att Intel valt att göra som de gör:

1. Hur mycket tjänar ett singeltrådat program på att få tillgång till hela L2-cachen istf halva? Förvisso ökar latencien med en gemensam cache (14 cykler på Core Duo jämfört med 10 på Pentium M), men vad som är bäst beror på hur programmet ser ut. Detsamma gäller när man multitaskar, vissa program har ju mer nytta av cachen och kan med en gemensam cache få t ex 75 % av den mot bara 25 % för ett annat program.

2. Vad är bäst när man kör två trådar/program samtidigt? Särskilt i multitrådade program kan det finnas en stor nytta av en supersnabb kommunikation via L2-cachen mellan trådarna och att kunna klara sig med totalt _en_ kopia av vissa saker i cachen istf en för varje kärna. Hans invändningar behandlar ju inte detta öht, utan fokuserar endast på fallet där en kärna kör något och den andra är helt oanvänd men ska precis börja exekvera något.

Man måste även se på framtidsutsikterna, hans kritik är ju bara tillämpbar när man har en kärna belastad och den andra obelastad. Ju längre tiden går, desto fler program kommer bli multitrådade och därmed belasta båda kärnorna samtidigt. Då är hans kritik helt irelevant. Intel har dessutom designat Core-arkitekturen för att den ska vara med ett tag. Det är ganska sannolikt att Pentium D och X2 har två separata caches för att minska ner på time-to-market-tiden, vilket givetvis är mycket viktigt inom processorbranschen. Men vi får se vad AMD gör i framtiden, ska bli mycket spännande.

Strömförbrukningen är jag mer osäker på. Jag tror dock inte att den gemensamma cachen gör att man behöver större cache. Det har alltid varit så att Intel gjort större caches än AMD, och nu när AMD har integrerad minneskontroller är behovet sannolikt betydligt större för Intel.

Här skriver Intels ingenjörer själva om hur de valde vilken cachearkitektur de skulle använda:
http://www.intel.com/technology/itj/2006/volume10issue02/art0...

Vill även tillägga att såna här diskussioner förvisso är intressanta, men kom ihåg att det inte har _någon_ betydelse när man väljer processor. Då väljer man den som är snabbast, har bäst pris/prestanda, är strömsnålast eller efter något annat vettigt kriterium. Det är totalt irrelevant hur processorn/hårddisken/bilen etc fungerar rent tekniskt, det inressanta är vilka egenskaper man märker av när den används.

AMD siktar väl på att börja med delad L3-cache? Fast då är det ju givetvis bara fördelar.

Han har väl rätt i sak, men missar den stora bilden.

Du är lite inne där på att gemensamt cache är bättre för att slippa kopior, speciellet när programmen fördelar belastningen på kärnor så att alla används samtidigt, det var ju det jag pratade om hela tiden i förra nyheten

Bara att jag ville ta det ett steg längre och ha gemensamt cache för alla kärnor

Annars så käns amds kritik lite orelevant och amd borde gå över till att göra gemensamt cache själva. Och då slipper man ju flusha och reloada för då har man ju redan nyaste datat i cachet. Eller?

Jo, jag höll ju delvis med dig. Men jag fick som sagt uppfattningen av att du trodde det blev kopior mest hela tiden och att all data som skrevs omedelbart behövde föras över till den andra processorns cache. Tvärt om är det viktigt att optimera programmet så att kärnorna inte skriver och läser till/från samma cache lines mer än nödvändigt eftersom den då måste flyttas fram och tillbaka om processorern har två separata caches. Fast samma sak gäller även när kärnorna har en gemensam cache, fast mindre allvarligt, eftersom de fortfarande har separata L1-caches.

Vilket fall tänker du på? När ett program går från att använda en tråd till att använda två trådar? Ja, under uppstarten borde man tjäna på en gemensam cache. Men detta gäller ju bara precis när den andra tråden börjar köras. Vad som är betydligt viktigare är nog som sagt hur programmet påverkas av den högre latencien för en gemensam cache jämfört med den lägre latencien när det finns separata, fast mindre, caches.

Vad jag menade är att man ska utgå från att man kör ett programm som är gjort för flera kärnor och då är gemensamt cache bättre i min mening, annars kan man ju säga att volvo är sämre än saab för att man inte kan tanka den med vatten.

Latrencen uppkommer som sagt för stora cache, stora cache har många problem, inte minst kosstnad, i den mening är ju många små cache bra men som sagt ett programm som fördelar exekveringen i över olika kärnor måste dessa kärnor ha tillgång till all data som är relevant för exekveringen, alltså måste resultatet av alla beräkningar sparas i allas kärnornas cache som exekverar samma programm.

Sen så har amd alla sina cache kopplade internt på chippet så cache kan skriva till cache utan att gå genom RAM, villket nästan eliminerar rördröjningen, intel verkar inte ha något sådant effterssom amd säger att ny data måste laddas från RAM.

Jag ser inga nackdelar med gemensamt cache.

Nej! Man måste skriva programmet så att ett resultat som beräknas av en tråd inte behövs av andra tråden med en gång. Detta försämrar även prestanda med en gemensam cache eftersom det dels leder till onödig synkronisering mellan trådarna, och dels så har kärnorna fortfarande separata L1-caches.

Om du kollar på mitt exempel igen i andra tråden så ser du att vektorerna bara behöver ligga i en cache om man har två kärnor med separata caches. Matrisen hade däremot kunnat delas i en gemensam-cache-arkitektur (om den varit större än 4*4 element, som det är nu får den plats i L1-cachen som ändå är separat. Dessutom ligger den på stacken i sin nuvarande form vilket ändå betyder att den måste lagras två gånger i cachen).

Och det är inte så att mitt exempel är alltför verklighetsfrämmande för att ha någon praktisk betydelse, utan det är verkligen så att man inte förlorar så mycket på att ha två kopior i cachen eftersom det inte blir så stor del av cachen som tas upp av kopior.

Försök komma på ett enda exempel där det har stor betydelse (dvs nära 100 % kopior i cacharna) där man inte kan ordna koden så den exekveras på ett snabbare sätt utan lika mycket kopior.

Som sagt, latencien blir högre och det beror inte enbart på att cachen är större utan även pga synkroniseringen. Dessutom måste ju båda kärnorna dela på cachens bandbredd. Om det är bäst med två separata eller en gemensam cache varierar från program till program (oavsett om de är singel- eller multitrådade), och det är svårt, för att inte säga omöjligt, att säga vilket som är bäst i genomsnitt utan att noggrant analysera ett stort antal program.

Vad du pratar om är beroende att exekvering av nästa snutt program kod är beroende av resultatet från en annat tex (2*5)+3 om man fördelar det mellan två kärnor så blir den kärna som ska beräkna +3 tvungen att vänta på att (2*5) beräknas, och kommer därmed att stå still och vänta på resultat, men om kärnor inte delar cache så måste resultatet av 2*5 sparas så att andra kärnan kommer åt det, dvs i andra cachet(kopia), eller i RAM. Det får nog bli mitt exempel

Det är ju väldigt simpelt exempel och men det visar tanken med hur jag menar att det blir många kopior.

Sen är det ju klart att man ska se till att det inte blir problem med beroende och sånt, men det ska en kompelator kunna fixa om det är tillräckligt smart.

[QUOTE]
Som sagt, latencien blir högre och det beror inte enbart på att cachen är större utan även pga synkroniseringen. Dessutom måste ju båda kärnorna dela på cachens bandbredd. Om det är bäst med två separata eller en gemensam cache varierar från program till program (oavsett om de är singel- eller multitrådade), och det är svårt, för att inte säga omöjligt, att säga vilket som är bäst i genomsnitt utan att noggrant analysera ett stort antal program. [/QUOTE]

Vad behöver man synkronisera i gemensamt cache när det aldrig kan innehålla både ny och gammal data som med delat cache, det är ju när man har delat cache som det kan ske att ena kopian är nyare och andra är älldre och då måste man tömma det och hämta senaste från ram, för resultatet skrivs till cache och RAM samtidigt. Har man gemensamt cache så fins det alltid uppdaterad data där vilket gör att kärnor behöver hämta mindra från ram.