Het grote AMD Hammer topic

lamaar

quote:

Op zondag 14 april 2002 16:27 schreef GiGNiC het volgende:

[..]

Inderdaad, in een dual systeem is remote acces te vergelijken met "CPU/Northbridge/Memory"-acces. Op dit vlak is die on-die memory-controller zeer van nut, in een theoretisch NUMA-systeem waar de memory-controller dan nog eens off-die zit is dat een straffe penalty, maar bij Hammer dus niet.

Kunnen de andere systemen daar dan niet direct de andere memory controller benaderen zonder door de andere CPU te gaan?

Misschien kunnen ze ook mekaars L2 cache benaderen

CPU0 < HTbus > CPU1

quote:

Op zondag 14 april 2002 16:40 schreef SuperG het volgende:
Misschien kunnen ze ook mekaars L2 cache benaderen

CPU0 < HTbus > CPU1

Dat is een noodzakelijke voorwaarde (cache coherency), en wat ik begrijp uit een Hammer/HyperTransport document van AMD is dat dit idd via de HT link verloopt en er geen afzonderlijke snoop bussen zijn. Maar met zo'n snelle HT link lijkt me het gemis van een afzonderlijke snoop bus (zoals bij de huidige AMD SMART SMP) geen echte draw-back.
Maar na het lezen van jouw reply en wat meer info van AMD lijkt de performance penalty in het geval van een remote geheugen benadering idd wel meevallen. AMD zelf zegt dat dit in een 8-way set-up gelijk staat aan een page-mis (natuurlijk gaan ze er wel even aan voorbij dat in dat geval nog steeds een page mis kan optreden zodat je gestraft wordt met een dubbele page-mis tijd). En in een 2-way set-up zal dit nog iets minder tijd kosten

Oh ja, die SparcIII's hebben ook een on-die memory controller (gelukkig)

Volgens berichten krijgen de Hammers maximaal 1MB L2 Cache dus SledgeHammers met 1MB L2.
Das tov de iTaniums met gigantische L3 caches weinig.

Maar wat krijgen de ClawHammers 512MB L2 ofzo minder zou 'n tegen valler kunnen zijn tov de P4 tegen hanger met ook 512MB.

Heb daar nog niks concreets over gehoord.

quote:

Op zondag 14 april 2002 18:44 schreef SuperG het volgende:
Volgens berichten krijgen de Hammers maximaal 1MB L2 Cache dus SledgeHammers met 1MB L2.
Das tov de iTaniums met gigantische L3 caches weinig.

Maar wat krijgen de ClawHammers 512MB L2 ofzo minder zou 'n tegen valler kunnen zijn tov de P4 tegen hanger met ook 512MB.

Heb daar nog niks concreets over gehoord.

Dat is niet noodzakelijk slecht, 512KB voor Claw (kijk ook naar kosten, en die-surface (welke zeer belangrijk is als je net als AMD met maar 1 fabje werkt) en dergelijke)

en omdat main memory zo dichtbij staat (figuurlijk dan) heeft een grotere cache minder effect.

BTW: heeft ier iemand al iets opgevangen over associativiteit van Hammer L2 ?? of van de L2-busbreedte ??(in Athlon issie maar 64bit, in P3/4 issie 256bit)

quote:

Leuk dat ze zoveel zelf vertrouwen hebben maar of dat ook zo was bij die vorige releasen en roadmaps die vaak ivm uitlopen werden aangepast door vertragingen.

De release van de Hammer is al met een jaar uitgesteld. Volgens de laatste geruchten is de release iets vervroegd in het vierde kwartaal. Dit in combinatie met het feit dat AMD blijft herhalen dat ClawHammer in Q4 komt geeft wel wat meer zekerheid.

quote:

Intel DUAL of MP systemen schalen goed door als de app puur CPU dependant is en nauwelijks op geheugen.
In dit geval zal de shared-bus geen bottleneck zijn maar heeft dan nog wat ruimte over totdat bij 'n x-aantal CPU de shared bandbreedte op is.

De Xeon heeft gewoon een veel hogere FSB en geheugen bandbreedte dan de bus van de Athlons. Het voordeel van de point-to-point FSB van de Athlon MP wordt daardoor teniet gedaan.

quote:

Numa heeft wel last van dat het uniforme geheugen niet identiek is en zijn hiervoor drivers nodig die het OS het memory efficient beheren en het juiste vrij geheugen geeft aan de CPU, die door 'n tread gebruikt wordt.
( zijn eigen geheugen aan zijn mem controller dit is het snelste geheugen voor die CPU )

NUMA van AMD zal hier dan mits goede NUMa drivers de voordeel hiervan laten zien.

Bij een 'echt' NUMA systeem wordt hiermee rekening gehouden. Wat AMD met de Hammer maakt is een systeem dat in hardware opzicht een UMA architectuur is, maar door de software als een normale SMP architectuur gezien kan worden. De Linux 2.5/2.6 kernel krijgt NUMA support voor de grote serversystemen. Het zal dan waarschijnlijk niet veel moeite zijn om Linux te optimaliseren voor de Hammer. AMD zal daar niet op willen wachten en zorgt er voor dat bestaande besturingssystemen ook gebruik kunnen maken van multi-processor Hammer servers.

quote:

Dit betekend dus dat elk voordeel van de latentieverminderende on-die memory controller wegvalt omdat cpu 0 z'n data via de HyperTransport link via de crossbar en memorycontroller van cpu 1 moet ophalen; dat lijkt me een behoorlijke performance penalty. Zo'n penalty krijg je nooit in een zuiver SMP systeem; daar spreken beide cpu's via een gedeelde bus of point-to-point verbinding één gesharede 'geheugenbank' aan.

De latency penalty tov lokaal geheugen is er wel, maar de latency zal dan nog steeds vergelijkbaar of lager zijn dan een normaal SMP systeem met gedeelde FSB en het geheugen achter de northbridge. HyperTransport heeft meer bandbreedte dan de huidige FSB technologien.

Ik vraag me trouwens of of processen die op CPU x draaien ook prefereren om geheugen te gebruiken dat aan CPU x hangt. Als dat het geval is, zou de NUMA architectuur zonder specifieke support al redelijk effectief kunnen werken. De meeste besturingssystemen zullen het switchen van dezelfde processen tussen verschillende CPU's zoveel mogelijk willen beperken (ivm effectiever gebruik cache).

quote:

Op zondag 14 april 2002 23:21 schreef Femme het volgende:
...
Ik vraag me trouwens of of processen die op CPU x draaien ook prefereren om geheugen te gebruiken dat aan CPU x hangt. Als dat het geval is, zou de NUMA architectuur zonder specifieke support al redelijk effectief kunnen werken. De meeste besturingssystemen zullen het switchen van dezelfde processen tussen verschillende CPU's zoveel mogelijk willen beperken (ivm effectiever gebruik cache).

Ik denk wel dat dat op de een of andere manier wat 'gestuurd' moet worden, temeer het OS /de software het systeem als een 'klassieke' SMP doos ziet (en dus geen onderscheid maakt in lokaal en remote geheugen). Het lijkt me met name lastig voor multithreaded software om de applicatie overeenkomstig de threads achter beide memorycontrollers in het geheugen te laden (het is volgens mij toch onmogelijk te voorspellen welke thread op welke cpu zal gaan draaien, mits je een affinity insteld o.i.d., maar daar ondermijn je volgens mij het SMP principe deels mee).

quote:

De Xeon heeft gewoon een veel hogere FSB en geheugen bandbreedte dan de bus van de Athlons. Het voordeel van de point-to-point FSB van de Athlon MP wordt daardoor teniet gedaan.

Niet helemaal, althans, je houdt nog enkele leuke bijkomstigheden over in het geval van P-to-P; de cpu's hoeven elkaar niet steeds in de gaten te houden of de FSB vrij is (want die is niet geshared) en dat bespaart weer wat tijd. En het cahe-coherency proces verloopt een stuk sneller. Maar idd, als er een 128bit geheugeninterface op zou zitten zou het pas echt leuk zijn worden

Hum, over dat 128bits geheugen bus dat zou mooi zijn voor voor de 760MP. Maar igv de Sledge Hammer die heeft 128bits membus wat in mijn ogen inhoud Per CPU minimaal 2x 64bits DIMM's

Dus in DUAL Sledge per 4 DIMM's
in Quad Sledge per 8 DIMM's. set

Dit is ook weer nieuw in PC X86 land dat ging tot nu toe hoog uit per 2 Dimms/Simms/Sipps?

Dus als je 'n Quad mobo hebt met uitbreidings mogelijkheden dus 4Dimm's per CPU is dat 4 sockets en 16Dimm sloten dat wordt 'n groot mobo bordje.

Ook zullen de DImm sloten verspreid over de mobo zitten als socket940 & DIMM groep paarjes.

Op blz. 22 van deze AMD Hammer_Presentation.pdf staat onder Integrated Memory Controller Details dat er een Direct connection to 8 registered DIMM's is. Dus zou je denken dat je flink wat DIMM's op zeg een 4-way bord kwijt kan. Of dit nu voor de Claw- of SlegdeHammer geldt staat er weer niet bij (denk de laatste).

quote:

Op zondag 14 april 2002 21:33 schreef GiGNiC het volgende:

....
BTW: heeft ier iemand al iets opgevangen over associativiteit van Hammer L2 ?? of van de L2-busbreedte ??(in Athlon issie maar 64bit, in P3/4 issie 256bit)

Ik zag in dit artikel dat Hammer's L2 16-way associative is. Maar de L2 busbreedte, nee, nog niks van gelezen.

quote:

Op zondag 14 april 2002 18:05 schreef Abbadon het volgende:
AMD zelf zegt dat dit in een 8-way set-up gelijk staat aan een page-mis (natuurlijk gaan ze er wel even aan voorbij dat in dat geval nog steeds een page mis kan optreden zodat je gestraft wordt met een dubbele page-mis tijd).

Wat is een page miss precies?

quote:

Op maandag 15 april 2002 07:51 schreef SuperG het volgende:
Dit is ook weer nieuw in PC X86 land dat ging tot nu toe hoog uit per 2 Dimms/Simms/Sipps?

Nee, 30 pins SIMMs zaten ook al per 4.

quote:

Dus als je 'n Quad mobo hebt met uitbreidings mogelijkheden dus 4Dimm's per CPU is dat 4 sockets en 16Dimm sloten dat wordt 'n groot mobo bordje.

Dat wordt een dure grap.

quote:

Ook zullen de DImm sloten verspreid over de mobo zitten als socket940 & DIMM groep paarjes.

Jah, wel mooi allemaal.
Maaruh ik mis toch iets.......

Kun je er nl. ook een spelletjuh met spelen?

quote:

Op maandag 15 april 2002 10:57 schreef OlafvdSpek het volgende:

[..]

Wat is een page miss precies?

Ja, dat kan ik niet zo in één, twee, drie woorden uitleggen, maar ik probeer het (hopelijk) duidelijk te brengen. Een page is de verzameling van alle geheugencellen met hetzelfde adres binnen een bank, van alle chips op de DIMM. Je weet neem ik aan dat er op een DIMM meerdere geheugenchips zitten en dat deze bestaan uit verschrikkelijk veel cellen (waar één bit in opgeslagen kan worden), tevens is zo'n chip opgedeeld in 4 logische banken. Daarnaast zitten er op de chips ook Sense Amps, dit is een klein snel buffer van waaruit de chipset de benodigde data leest. In de Sense Amps past precies één page (veelal 4, 8 of 16kB groot) en als er een verzoek om data wordt gedaan welke reeds in de open page staat spreek je van een Page Hit. Staat de gevraagde data niet in de open page (de Sense Amps), dan zal er een extra slag moeten worden gemaakt om de data van uit de juiste page naar de Sense Amps te kopiëren, dit heet een Page Mis en kost dus extra tijd (die extra kopieslag). Als na het benaderen van een open page er data uit een andere open page moet worden gehaald (er zijn 4 banken op één DIMM, en dus ook maximaal 4 open pages voor die DIMM) kan de chipset beslissen de open page te sluiten of open te houden. Het meest ideale is deze open te houden want stel dat de het eerstvolgende verzoek om data vanuit die open page kan worden gehonoreerd, dan heb je weer ene page hit en tijdswinst Nu kunnen niet alle chipsets even veel en even lang page's open houden. En de page zelf kan natuurlijk ook niet altijd open blijven want de Sense Amps zijn namelijk ook nodig voor de refresh cyclus. Vooral toevallig/random geheugenbenaderingen hebben veel profijt van een goede open page policy.

quote:

Direct connection to 8 registered DIMM's

Dat is SledgeHammer, ClawHammer kan 2 DIMM's unbuffered (en maayybbee 4 DIMM's Registered)

quote:

Bij een 'echt' NUMA systeem wordt hiermee rekening gehouden. Wat AMD met de Hammer maakt is een systeem dat in hardware opzicht een UMA architectuur is, maar door de software als een normale SMP architectuur gezien kan worden. De Linux 2.5/2.6 kernel krijgt NUMA support voor de grote serversystemen. Het zal dan waarschijnlijk niet veel moeite zijn om Linux te optimaliseren voor de Hammer. AMD zal daar niet op willen wachten en zorgt er voor dat bestaande besturingssystemen ook gebruik kunnen maken van multi-processor Hammer servers.

Inderdaad, in een multi-processor Hammer-bak wordt geheugen-space gezien als "Flat", wat dus inhoud dat de software alle geheugen als 1 mooi blok RAM ziet.
Zonder optimale OS-support is op deze manier het potentieel van NUMA minder benut, maar het is wel zeer probleemloos te integreren voor software (die weet toch van niks).

quote:

Ik zag in dit artikel dat Hammer's L2 16-way associative is. Maar de L2 busbreedte, nee, nog niks van gelezen.

OK, bedankt.
Ik vermoed dan dat L1 ook weer 128KB "harvard style" is, 2-way associatief, hopelijk is deze eer L2-bus wel breder geworden (remember T-Bird disappointment )

woops, messed up signature

quote:

Dus als je 'n Quad mobo hebt met uitbreidings mogelijkheden dus 4Dimm's per CPU is dat 4 sockets en 16Dimm sloten dat wordt 'n groot mobo bordje.

Dat wordt een dure grap.

Daarom verwacht ik ook eerder 2-way en 4-way borden met 2 DIMM slots per CPU. Met max 2GB per DIMM is er geen reden om meer dan acht DIMM slots op een plank te plaatsen.

quote:

Op maandag 15 april 2002 22:30 schreef Femme het volgende:

[..]

Daarom verwacht ik ook eerder 2-way en 4-way borden met 2 DIMM slots per CPU. Met max 2GB per DIMM is er geen reden om meer dan acht DIMM slots op een plank te plaatsen.

Als dat zo is en mijn vorige reply is geldig dus dat per twee gepaalts moet worden moet je dimms per twee plaatsen * X-tal CPU ivm 128bits memcontroler en dan heb je bij de sledgehamme alle dimmsloten vol wat bij mem upgrade inhoud dat als je meer geheugen ruimte wilt de oude dimms vervangen moeten worden door grotere exemplaren.

dus 8GB (Quad 8*1GB dimms) en je wilt naar 16GB dan moeten de 1GB dimmes allemaal vervangen worden door 2GB Dimmes.

Vraag me af of elke CPU ook 'n andere mem grote mag hebben.?

quote:

Op dinsdag 16 april 2002 07:33 schreef SuperG het volgende:

[..]

Vraag me af of elke CPU ook 'n andere mem grote mag hebben.?

Dat mag zeker, curtecy of NUMA

Hoppa: NUMA support voor Windows: http://www.tweakers.net/nieuws/21457

Het lijkt me niet onwaarschijnlijk dat Sledge- en ClawHammer native door .Net Datacenter en Enterprise Server ondersteund zullen worden. Jerry doet alvast zijn best om iets voor elkaar te krijgen (http://www.tweakers.net/nieuws/21454) - XP64 support?, NUMA?.

iTaniums hebben volgens dat bericht ook NUMA nodig dus die hebben ook 'n MEM controller on die of memory per itanium. Dat wist ik niet.

Maar ja 'n iTanium voor thuis zit er niet in Hammertje wel.

De Itanium heeft geen on-die memory controller, maar je kunt wel een NUMA systeem bouwen door bijv. 4-way chipsets aan elkaar te plakken. AMD heeft wel eens diagrammen laten zien vn 4-way en 8-way systemen die waren samengesteld uit twee of vier 760MP chipsets (http://tweakers.net/ext/i.dsp/957212333.gif). In feite heb je dan een NUMA systeem.

quote:

Op woensdag 17 april 2002 07:47 schreef SuperG het volgende:
iTaniums hebben volgens dat bericht ook NUMA nodig dus die hebben ook 'n MEM controller on die of memory per itanium. Dat wist ik niet.

Maar ja 'n iTanium voor thuis zit er niet in Hammertje wel.

Ja, maar dan niet met Windows, of ben je van plan er .Net Enterprise Server en .Net Datacenter op te draaien?

LoLzZzz, Athlon = Clawhammer, Opteron = Sledgehammer

marketingsgewijs een mooie zet

Kunnen die Hammers op een standaard AMD-bord (socket A dus) ? En moet je rperze DDR 333 bij gebruiken?