Intel lanserar "Opteron-dödare"

Soft ge mig

Jaha...efter....4 år...så kommer intel....och va tror intel att AMD har gjort under dessa år??? Tagit fika???
ahahah....vi får se va AMD svarar med... det lär ju inte dröja så länge...

undrar hur mycket sanning det ligger i detta: http://mikrodatorn.idg.se/ArticlePages/200606/26/200606261034...

är det verkligen kentsfield? ja menar, de skriver "Kentsfield, som går under det officiella namnet Core 2 Duo E6600", är inte E6600 en vanlig conroe?

i vilket fall så verkar det mycket lovande. självklart kommer amd så småningom med en ny processor, det måste de. men frågan är när.

Amd is tha shit !!! helt ointressant...

lika clockvänlig?

"...krets har två processorkärnor som gemensamt delar på fyra megabyte cacheminne. Totalt ger det processorn åtta megabyte cache."

Varför gör dom inte gemensamt cache för alla kärnor / processorer på plattan, det sparar ju mycket tid, kosstnad, värme.
Istället för att dom två på 4mb var ska synkranisera data med varandra så att båda delar har samma data, dessutom skulle det behövas mycket mindre cache för att i dessa 8mb kommer det att finnas data från cache 1 på 4mb och cache 2 på 4mb vilket resulterar i att i verkligheten så har den bara 2 mb verklig cache för att 2 mb måste allokeras till kopia av data från den andra 4mb cache och vise verse.
Resultat 8 mb cache är i vekligheten 2 mb fast 4 gånger dyrare.

Liten ilustration under ifall beskrivningen var otydlig.

|-----------|. . . . . |------------|
|cache1| === |cache2|
|. 4mb. .|. . . . .|. 4mb. .|
|_______|. . . . .|_______|

resulterar i:

|-----------|------------| . . . |------------|-----------|
|cache1| copy. .|===|cache2| copy. .|
| 2mb. . |cache2| . . . | 2mb. . |cache1|
|_______|__2mb_| . . . |______|__2mb_|

Så innan ni köper en cpu med mycket cache kolla om kärnor har gemensam cache eller separat, för som sagt 8 mb kan i verkligheten visa sig vara 2 mb, och en cpu med endast 2mb cache(men gemensamt) är nog mycket billigare.

Kollade länken, och nu är jag förvirrad, är det inte två kärnor dem släpper nu ?
" Core 2 Duo E6600"

Men .... "Core 2 Duo E6600, har fyra processorkärnor som är byggda med 65-nanometersteknik. "

Det skumma är ju att det är 4 kärnor enligt deras källa också.. och den är väl ganska tillförlitlig..

http://www.xtremesystems.org/forums/showthread.php?t=103982

men det kan ju va nån processor som inte identifierats rätt..

edit:
"Oooh teh Kentsfield, CPU-Z can't recognize it properly yet of course.."

står det iofs på sidan så det är nog deras serverprolle och inte E6600 som mikrodata skriver..

Nej, det är ju egentligen två E6600 på samma sockel. Kentsfielden skulle väl lanseras som en Core 2 Extreme så den kommer nog heta X****.

/Adrian

AMD har redan annoserat sin kommande microproccesing teknik som kommer 2007. Troligtvis mycket bättre än k8l som i dagsläget har det svettigt mot Intels nya server (spel också) cpu's . Hur som helst min Opteron165 @OC funkar fint för både min server och spelande hittills.. Jag hoppar nog över AM2 och väntar på nästa generation. Min prolle funkar nog hyffsat tills dess. Både angående angående spel och andra roliga saker jag har på min dator. Visst conroe har bättre fps för tillfället men hur mycket mer fps behöver man i ett år framåt..?
Jag är inte efrämmande för att byta plattform om inte amd fixar till det. Vilket de kommer göra.. Den som lever får se!

Jag begriper inte riktigt vad du menar, men jag håller inte helt med. Visst kommer cachen bli kopior av varandra om alla kärnorna jobbar på exakt samma minnesbitar, men i praktiken sker detta väldigt sällan. Nackdelen med att ha en helt delad cache är att cachen blir långsammare och att det ökar utvecklingstiden. När det gäller Kentsfield är det dessutom två chip som sitter ihop (varje chip har två kärnor och en 4 MB L2-cache), dvs ungefär som dagens Pentium D (fast där har varje chip en kärna och 1-2 MB L2-cache). Att göra så sparar pengar, eftersom det är många gånger dyrare att göra ett stort chip istället för två mindre. Inte heller kan man dela på cachen särskilt lätt när det görs på det viset eftersom all kommunikation sker via FSBn och den är långsam.

Jag vet inte i detalj hur delningen går till på en vanlig Core (2) Duo. Jag har läst att varje del av cachen hör till en kärna och att uppdelningen sker dynamiskt men jag vet inte hur smidigt det går att läsa från den andra kärnans cache och om det går att skriva till den eller inte. Men det kan alltså ligga samma minnesbitar i båda kärnornas cache (dvs kopior) även här menar du?

Sen måste man komma ihåg att det viktiga när det gäller processorer är inte att kolla på hur häftiga lösningar de har, som hur mycket cache det finns och hur den används. Det viktiga är prestanda i förhållande till pris.

var precis det jag undrade över

Quad cores (Kentsfield, Clovertown, K8L) kommer först nästa år, de blandar ihop beteckningar i länkarna. Core 2 Duo E6600 kommer vara en dual core med 4 MB L2-cache (se t ex http://en.wikipedia.org/wiki/Intel_Core_2), tror knappast modellbeteckningarna för Kentsfield är helt bestämda än.

Pratar du om "Reverse HyperThreading" nu eller vad? Hur Reverse-HT fungerar vet vi inte, så det går nog inte att säga så mycket om hur cachen kommer användas (om Reverse-HT ens existerar).

Annars jobbar inte kärnorna på exakt samma minnesbitar samtidigt, normalt sett. Men visst blir det en del kopior i minnet, men att säga att _allt_ blir kopior stämmer inte alls. Normalt jobbar inte trådarna så intimt med varandra som du verkar tro, det skulle bli alldeles för mycket overhead för synkronisering av dem då.

Japp jag menade "Reverse HyperThreading" och som sagt man vet inget om det än, men när du säger att trådarna inte jobbar så intimt med varandra så är det i min mening inte så bra och man borde eftersträva mer intimt sammarbete, och det är därifrån min teori dök upp om att "Reverse HyperThreading" skulle vara just en sådan sak, för man måste ju eftersträva en så jämn fördelning som möjligt.

Teoretisk ska det fungera så att kompelator delar upp programmet i oberoende bitar för att sedan belasta alla kärnor så att allt exekaveras samtidigt eller oberoende, det är ju det som är poängen med flera kärnor trotts allt. Och det sker dynamiskt så att om en kärna tar långt tid på sig så går den kärna som är klar över till att exekvera nästa delen av programmet och nästa delen kanske behöver data från tidigare exekvering som kanske ligger på andra chachet.

Jag är inte riktigt med på vad du menar med att jobba på samma minnesbit, men om man inte begränsar cpun till att bara två kärnor exekverar ett programm så måste det bli som jag sa att det måste finnas exakta kopior av allt.

Vad jag tror att du menar är att ena delen (två kärnor) bara kör windows och andra två kör nått program så behöver man inte ha kopior, och det är ju sant men det är inte så effektivt.

Jag pratar om hur det fungerar idag, och när man kör ett flertrådat program idag ligger det definitivt inte bara kopior i cacharna. Hur det blir om Reverse-HT dyker upp kan vi inte veta eftersom vi inte vet hur den fungerar, som sagt. Om det rör sig om slipstreaming (http://en.wikipedia.org/wiki/Slipstream_(computer_science)) så kommer man inte tjäna lika mycket på det med separata cachar eftersom den första tråden ska prefetcha data från minnet som den andra tråden ska dra nytta av.

Med att jobba på samma minnesbit så menade jag samma del av minnet (samma cache line). Var lite fel ord av mig, särskilt som det kan se ut som om jag snackade om enskilda bitar (1 och 0) men det var alltså inte tanken.

Sen förstod jag inte vad ditt sista stycke hade med Reverse-HT att göra om det nu var RHT du pratar om? Det är därför jag blir lite förvirrad, tycker stundtals det låter som det är RHT du pratar om och stundtals inte

Vad jag pratar om är helt enkelt hur ett program ska exekveras på en flerkärnig cpu på optimalt sätt, att ett programm delas upp i så många oberoende bitar som möjligt och exekveras så parralelt som möjlit.

Istället för att köra:

######## -> |cpu| -> output

så

## -> |cpu| -> output
## -> |cpu| -> output
## -> |cpu| -> output
## -> |cpu| -> output

För det behöver inte att alla kärnor jobba på exakt samma cache line, men om alla kärnor exekverar ett enda program så måste alla kärnor ha tillgång till all data som tillhör programmet som exekveras, därav mitt påstående om att mycket kommer att gå åt till cache kopior. Andra kärnor kommer kanske aldrig att göra nått med data som ligger i cachet men den måste finnas där utifall det behövs efterssom det tillhör programmet som exekveras.

"What happens if CPU 1 has a line in its cache, and then CPU2 tries to read a word in the same chache? In the absence of any special rules, it too, would get a copy in its cache. In principle, having the same line cached twice is accepteble." // Structured computer organization by Andrew S. Tanenbaum.

Och det var vad jag pratade om, men jag kollade upp det i boken och där stod det att kopiera chache fungerar för 2 till 3 cpuer sen så blir det som sagt för många kopior, teoretiskt sätt är cpun vi pratar om just nu är två cpuer så att ha kopior av allt är fullt möjligt.

Men för flera scpuer skiter man helt enkel i det och om en cpu inte har nödvändigt data i cachet hämta det från RAM, men RAM är som bekant en flaskhalls.

Så det hänger på hur intel har löst det, antigen man inga kopior men mycket mer användning av RAM (vilket motsäger hela poängen av cache) eller kopieras allt som resulterar i 2mb cache.

Jag förstår vad du menar, men jag får känslan av att du tror att hela programmet ligger i cachen och så är inte fallet. En cache line fylls när motsvarande position i minnet läses eller skrives till första gången. Om en tråd inte läser en del av den data programmet i helhet behandlar så hamnar den aldrig i cachen som hör till den tråden. Om man tar ett exempel kanske det är lättare att illustrera:

Antag att vi vill transformera en miljon vertexar med en matris (alla med samma matris). I C++ blir det något i stil med

Matrix m( /* lämplig initiering */);
Vector4d* vectors = new Vector4d[1000000]; // I verkligheten innehåller vertexarna verkliga värden, här blir det bara oinitierat skräp i dem.
Vector4d* result = new Vector4d[1000000]; // Resultatet

for (int i = 0; i < 1000000; i++) {
result[i] = m * vectors[i];
}

Eftersom iterationerna i loopen är oberoende kan vi lätt göra om den till två loopar som kan exekvera parallellt, så som
for (int i = 0; i < 500000; i++) {
result[i] = m * vectors[i];
}
och
for (int i = 500000; i < 1000000; i++) {
result[i] = m * vectors[i];
}
(i verkligheten skulle jag delat upp den i tio delar och låta trådarna hämta delarna allt eftersom de är klara med föregående del, men principen är exakt densamma)

Nu kommer bara vektorerna 0 till 499999 hamna i den ena kärnans cache och den andra kärnans cache kommer bara innehålla nr 500000 till 999999. Den första tråden accessar ju aldrig minne från någon minnesposition där vektor 500000 till 999999 finns, och motsvarande/tvärt om för den andra tråden.

I princip funkar det så, dvs detta är "the big picture". I verkligheten så behövs ingen L2-cache för detta eftersom det i princip bara är streamat till och från minnet, men även om vi hade längre beräkningar som drog nytta av cachen (t ex med en större matris och fler än 4 element i vektorerna) skulle principen fortfarande gälla. Det är naturligtvis ett exempel som kanske är lite väl anpassat för det jag ville visa, men principen gäller även på mer verkliga program.

Fö är det mycket viktigt att optimera för cacheanvändning om man ska ha snabb kåd. Man bör mao _inte_ lämna över resultat till den andra kärnan så fort, utan försöka behandla data så mycket det bara går när man ändå har den i cachen. Detta gäller även när man bara har en tråd.

Jo fast nu delade du upp det i 2 delar som exekveras samtidigt och lika snabt, men vad händer om man delar upp det i flera delar som du sa där ena tar väldigt långt tid att exekvera, andra går lite snabbare och resten går välldigt snabt att exekvera, då fastnar ena kärnan och kommer att sitta med samma kod snutt hela tiden, andra kärna kanske hinner med att exekvera 2 delar av programmet och resten exekveras väldigt snabbt. Som jag förstår det så ska allt fördelas lika och att andra kärnor måste vänta på att den långsammaste exekverar sitt, men så ska det ju inte vara den som är klar ska fortsätta exekvera andra delar av programmet.

Jag menar inte att hela programmet laddas till cache, det fins inte plats för det helt enkelt vad jag pratar om är "out of order" exekvering över kärnor, som medför inte att all cache måste ladda samma data från ram, men resultatet måste defenitivt finnas i all cache, för man vet inte vilken kärna kommer att behöva det näst.

Men men jag antar att sanningen ligger nånstans mittemellan, för att data som laddas från RAM behöver inte finnas i båda cache, men resultatet måste finnas överallt. så det blir väll 75%-25% fördelning kanske istället för 50%-50%.

Men det verkar inte vara det viktigaste verkar det som, för amd klagar på något annat, i nyheten på sweclockers, har inte hunnit läsa artickeln än kom nyss hem från jobbet, men ska göra det så fort jag kan, men problem med cache handlar den om ialafall.

Kanske kan diskutera den nyheten sen ;P