Het grote AMD Hammer topic

[TERW_DAN]

Heeft iemand enig idee wanneer de AMD K8 (de Hammer) uitkomt?
Op de AMD site kan ik maar een press release vinden van 16 jan 2001 en daar staat verder geen release datum in van de proc.
ook op T.net is niet echt veel te vinden.

[Moartn]

http://www.tweakers.net/nieuws/20590

[edit]
De eerste clawhammer moet dus eind dit jaar in de winkels liggen met een snelheid van M3400 (nieuwe speedrating)

[TERW_DAN]

Op zaterdag 16 februari 2002 15:54 schreef Moartn het volgende:
http://www.tweakers.net/nieuws/20590

Staat volgens mij niet bij wanneer deze proc nu precies gaat uitkomen.

[bazs2000]

De Hammer komt uit in het 4^e kwartaal van 2002/
Het staat in dat mooie grafiek.

[Moartn]

Op zaterdag 16 februari 2002 15:56 schreef Terw_Dan het volgende:

[..]

Staat volgens mij niet bij wanneer deze proc nu precies gaat uitkomen.

Is Q4 van 2002 niet precies genoeg dan? Het duurt nog 9 maanden ofzo, dan gaan zo toch niet een exacte datum noemen?

[BrZ]

Hmm.. ik krijg toch echt het idee dat hammers niet voor "normale" mensen zijn... net zoals eigenlijk bijna alle andere 64bit cpu's... denk dat ze voorlopig gewoon te duur worden... zelfs voor een idioot als ik

[Moartn]

Op zaterdag 16 februari 2002 16:01 schreef BrZ het volgende:
Hmm.. ik krijg toch echt het idee dat hammers niet voor "normale" mensen zijn... net zoals eigenlijk bijna alle andere 64bit cpu's... denk dat ze voorlopig gewoon te duur worden... zelfs voor een idioot als ik

Zoals je in bovenstaande nieuwspost kunt lezen gaat de Duron verdwijnen, de Athlon gaat richting Duron-prijsklasse, en de Clawhammer word wat nu Athlon is... De Sledgehammer wordt waarschijnlijk toch echt voor professioneel gebruik....

[Gardocki]

Bewaar dit topic maar voor over 6 maanden ofzo

[BrZ]

Op zaterdag 16 februari 2002 16:04 schreef Moartn het volgende:

[..]

Zoals je in bovenstaande nieuwspost kunt lezen gaat de Duron verdwijnen, de Athlon gaat richting Duron-prijsklasse, en de Clawhammer word wat nu Athlon is... De Sledgehammer wordt waarschijnlijk toch echt voor professioneel gebruik....

Nee hoor, het lijkt erop dat dat gaat gebeuren, is nog helemaal niet zeker

[bazs2000]

Iets in mij zegt dat Terw_Dan als een van de eerste een Hammer in zijn pc zet.

[Zap]

Op zaterdag 16 februari 2002 17:54 schreef bazs2000 het volgende:
Iets in mij zegt dat Terw_Dan als een van de eerste een Hammer in zijn pc zet.

Ik wilde net zeggen, wel typisch dat hij dit topic start
Zou z'n hamerverslaving weer terugkomen?

^{Sorry voor offtopic reply btw}

[KeRsTmAnNeKe]

Op zaterdag 16 februari 2002 17:59 schreef Zap het volgende:
Zou z'n hamerverslaving weer terugkomen?

Dat idee krijg ik ook...

Maaruh, als die als vervanger voor de Athlon komt... komt der dan ook meteen software voor ?

[TERW_DAN]

Op zaterdag 16 februari 2002 17:59 schreef Zap het volgende:

[..]

Ik wilde net zeggen, wel typisch dat hij dit topic start
Zou z'n hamerverslaving weer terugkomen?

^{Sorry voor offtopic reply btw}

Waarom denk je dat ik een Hammer wil

[Anoniem: 23465]

Op zaterdag 16 februari 2002 16:04 schreef Moartn het volgende:

[..]

Zoals je in bovenstaande nieuwspost kunt lezen gaat de Duron verdwijnen, de Athlon gaat richting Duron-prijsklasse, en de Clawhammer word wat nu Athlon is... De Sledgehammer wordt waarschijnlijk toch echt voor professioneel gebruik....

Die kans bestaat zeer zeker
hou er rekening mee dat clawhammer maar 104mm² groot is (huidige palomino is 129mm²) en .13µ met SOI door Barton al zou moeten ingewerkt zijn, dus kwa productiekosten zou het moeten meevallen, enkel kwa marketing moet het allemaal passen natuurlijk, en daar is gequote methode een zeer goede mogelijkheid

[Anoniem: 23465]

Ik meen hier net in een webcast te hebben gehoord dat Hammer maarliefst 100 miljoen transistors heeft (Athlon is 37.5 Mil, P4 is 42 Mil, GeForce 4 doet 63 Mil)

MaD amount of transistors, vind ik

[Femme]

ook op T.net is niet echt veel te vinden.

De Clawhammer release streefdatum van 4de kwartaal is al vaak genoemd, bijvoorbeeld in <a href='http://tweakers.net/reviews/256'>deze feature</a> en talloze nieuwspostings.

Ik meen hier net in een webcast te hebben gehoord dat Hammer maarliefst 100 miljoen transistors heeft (Athlon is 37.5 Mil, P4 is 42 Mil, GeForce 4 doet 63 Mil)

MaD amount of transistors, vind ik

Het lijkt veel, maar het valt wel mee als je rekening houdt met de grotere caches die de Hammer krijgt. SRAM cellen vreten veel transistors.

[superbikkel]

Op zaterdag 16 februari 2002 18:02 schreef KeRsTmAnNeKe het volgende:

[..]
Maaruh, als die als vervanger voor de Athlon komt... komt der dan ook meteen software voor ?

De Hammer kan native draaien in 32bits mode, dan werkt alle huide x86 software.

Ik meen te hebben gelezen dat bij de demo die werd gegeven tijdens de IDF dat een van de 2 Hammers tegelijkertijd 32bits en 64bits software draaide, onder een Linux OS.

Owjah, Suse komt nu al met een aangepaste Linux kernel.

Dus ik denk dat er wel software gaat zijn ja.

[Anoniem: 23465]

Op woensdag 06 maart 2002 07:15 schreef superbikkel het volgende:

[..]

De Hammer kan native draaien in 32bits mode, dan werkt alle huide x86 software.

Ik meen te hebben gelezen dat bij de demo die werd gegeven tijdens de IDF dat een van de 2 Hammers tegelijkertijd 32bits en 64bits software draaide, onder een Linux OS.

Owjah, Suse komt nu al met een aangepaste Linux kernel.

Dus ik denk dat er wel software gaat zijn ja.

Linux kernel 2.6 krijgt x86-64 native, maar SuSe en anderen hebben al een x86-64-werkende linux
kunt ook standaard 32bits OS-en draaien, net als met een athlon (maar dan sneller ), maar in een 64bits OS kunnen tegelijk 64bits en 32bits software draaien (16bit niet meer, das net iets te ver trug)

[Anoniem: 23465]

Heeft iemand eigenlijk al enige geruchten/feiten/whatever opgevangen over de cache-structuur van Hammer ?

L1-size, latencies, associativiteit, busbreedte tussen L1<=>L2, exclusief of inclusief,...

zo van die dinge

iemand ?

[superbikkel]

Op zaterdag 09 maart 2002 17:36 schreef GiGNiC het volgende:

[..]

maar in een 64bits OS kunnen tegelijk 64bits en 32bits software draaien (16bit niet meer, das net iets te ver trug)

Uh, hoe moet dat dan met Win9x en ME, daar zit toch echt nog 16 bits code in? En DOS is ook 16 bits.

Of bedoel je dat tegelijkertijd draaien van 64, 32 en 16 bits niet kan?

[SG]

Dacht dat de Hammer 3 CPU modes zouden krijgen
32bits
64bits compatible mode met IA32
64bits native

[froggie]

Op woensdag 20 maart 2002 20:23 schreef superbikkel het volgende:

[..]

Uh, hoe moet dat dan met Win9x en ME, daar zit toch echt nog 16 bits code in? En DOS is ook 16 bits.

Of bedoel je dat tegelijkertijd draaien van 64, 32 en 16 bits niet kan?

Het zou vervelend zijn als je geen Win9x meer kunt draaien. Ben best nog wel gehecht aan Win98 eigenlijk (naast Linux natuulijk, maar Win98 is er nog één zonder fratsen )

[NitroX infinity]

ik ben wel nieuwsgierig naar de FSB's van de hammer modellen. Zal die nou 2*133MHz of iets anders zijn?

[DirtyHennessy]

als de hammer er is kunnen we dan ook pci-X en agp 8 x op ons plankje zien ?

[Anoniem: 40249]

Yup ik weet al bijna zeker dat ik een Hammer ga halen (heb nu een 1.4 athlon) over een jaartje haal ik het. Weetik 100% zeker

[Femme]

Op woensdag 20 maart 2002 23:02 schreef Nitrox_Infinity het volgende:
ik ben wel nieuwsgierig naar de FSB's van de hammer modellen. Zal die nou 2*133MHz of iets anders zijn?

De Hammer heeft geen FSB. De geheugencontroller is geïntegreerd op de processor, waardoor de functie van de northbridge is komen te vallen. Voor de verbinding met de AGP poort en de I/O controllers wordt gebruik gemaakt van een HyperTransport link met een snelheid van maximaal 6,4GB/s (ClawHammer). AMD heeft inmiddels drie componenten aangekondigd die op deze HyperTransport link aangesloten kunnen worden: een AGP3.0 (8X) tunnel, PCI-X tunnel en I/O hub. De I/O hub vervult de functie van de traditionele southbridge. Andere chipsetfabrikanten zullen waarschijnlijk een chip ontwikkelen die de I/O hub en de AGP controller integreren.

De Hammers zullen PC2700 geheugen gebruiken.

In dual ClawHammer systemen wordt de HyperTransport link gesplits zodat 3,2GB/s overblijft voor I/O en 3,2GB/s voor de verbinding tussen de processors. Multi-processor Hammer systemen zullen geen specifieke chipsetsupport vereisen! (logisch, de processors worden direct aan elkaar geknoopt ipv via point-to-point FSB's of een gedeelde FSB naar de northbridge.

Dankzij HyperTransport zal het ontwerp van een Hammer moederplank veel eenvoudiger en wellicht ook goedkoper zijn dan bij de conventionele CPU/northbridge/southbridge opstelling. Er is geen FSB meer nodig en geen interconnect tussen northbridge en southbridge. Alle I/O hangt aan de HyperTransport link (seriële packetized bus, relatief lage pincount, hoge frequentie, variabele breedte van 2 tot 32-bit).

De ClawHammer plank die wij in de private rooms van AMD op de CeBIT hebben gezien zag er voor een pre-productie bord erg netjes uit. Vooral het kleine aantal condensators was opvallend.

[Cookie]

[speculatie mode]

Het verhaal ging dat de Hammers SSE-2 support zouden krijgen en dat AMD de SSE-2 licenties pas met ingang van 2003 zou mogen toepassen. Aangezien 31 december bijvoorbeeld ook nog Q4 is, zou dat eventueel kunnen betekenen dat de eerste ClawHammers dus tegen Kerst bestelbaar, maar ná 31 december 2002 daadwerkelijk uitgeleverd gaan worden. De SledgeHamer volgt dan een tijdje later in Q1 2003. Ik zal overigens niet verbaasd opkijken als ten tijde van Intel's volgende Developer Forum (IDF Fall 2002), de eerste Hammers op full-speed werkend gedemonstreerd gaan worden. Please do correct me if I'm wrong.

[/speculatie mode]

[Femme]

Volgens de huidige roadmap moeten de Hammers eind vierde kwartaal op de markt komen. Aangezien AMD een slechte reputatie heeft wat betreft het nakomen van hun eigen voorspellingen, zal het mij weinig verbazen als de ClawHammer pas vanaf Q1'03 verkrijgbaar is (met shipments in het vierde kwartaal van dit jaar).

[BoerHarm]

op dit moment doet mijn athlon 1 ghz het nog goed genoeg, maar als de Hammer uitkomt, en hij is een beetje betaalbaar, dan koop ik een hammer..

[EaS]

Het mooiste nieuws over de hammer, zoals je in het artikel kunt lezen:

-Microsoft Support X86-64

-AMD is vrij (zonder restricties) alles van intels architectuur te gebruiken (dus ook SSE-2 in 2002), zo is Intel ook vrij (again: zonder restricties) x86-64 te gebruiken.

-De hammer heeft 67 Miljoen transistors

En nog meer interessant nieuws, rechtstreeks uit de mond van Jerry Sanders.

[Anoniem: 42000]

als de hammer geen fsb heeft ken je hem dan ook nie ocen ??

[NitroX infinity]

hmm, misschien een rare opmerking maar aangezien dit toch "het grote AMD hammer topic" is

Ik zou wel in de toekomst een hammer willen zien met Intel's Hyperthreading technologie. Volgens mij heb je dan een superprocessor.

[Anoniem: 23465]

Op donderdag 21 maart 2002 00:20 schreef Femme het volgende:

[..]

In dual ClawHammer systemen wordt de HyperTransport link gesplits zodat 3,2GB/s overblijft voor I/O en 3,2GB/s voor de verbinding tussen de processors. Multi-processor Hammer systemen zullen geen specifieke chipsetsupport vereisen! (logisch, de processors worden direct aan elkaar geknoopt ipv via point-to-point FSB's of een gedeelde FSB naar de northbridge.

Dit is iets wat niet kan, een Hypertransport link kan niet zomaar in 2 worden gedeelt, de nodige control/clock pins en dergelijke moeten dan vernaderd worden in de specs (wat niet gaat gebeuren)
Clawhammer DP gaat gewoon 2 6.4GB links krijgen
de gewone Clawhammer, misschien 1, misschien 2, dat is zo duidelijk niet

[Femme]

Op donderdag 21 maart 2002 20:16 schreef mrneo911nl het volgende:
als de hammer geen fsb heeft ken je hem dan ook nie ocen ??

We hebben dat gevraagd op CeBIT en ze konden er niet veel over zeggen. Het ziet er inderdaad naar uit dat de Hammers niet overklokbaar zullen zijn.

[NitroX infinity]

Op donderdag 21 maart 2002 21:34 schreef Femme het volgende:

[..]

We hebben dat gevraagd op CeBIT en ze konden er niet veel over zeggen. Het ziet er inderdaad naar uit dat de Hammers niet overklokbaar zullen zijn.

Da's balen, en tevens ook mooi voorpagina nieuws (nou ja nieuws? meer een gerucht)

[Femme]

Op donderdag 21 maart 2002 21:32 schreef GiGNiC het volgende:

[..]

Dit is iets wat niet kan, een Hypertransport link kan niet zomaar in 2 worden gedeelt, de nodige control/clock pins en dergelijke moeten dan vernaderd worden in de specs (wat niet gaat gebeuren)
Clawhammer DP gaat gewoon 2 6.4GB links krijgen
de gewone Clawhammer, misschien 1, misschien 2, dat is zo duidelijk niet

Dat lijkt me ook logisch, maar in de ClawHammer diagrammen die we op CeBIT hadden gezien was er maar één HyperTransport link (van 6,4GB/s). Toen we vroegen hoe ze dan twee ClawHammers aan elkaar gingen knopen werd er geantwoord met "we gaan de HyperTransport link splitsen".

ClawHammer moet twee HyperTransport links krijgen omdat dual processing anders niet mogelijk is. ClawHammer en ClawHammer DP zitten in hetzelfde package en zullen dus beide twee HyperTransport links moeten hebben. Wat wel denkbaar is dat AMD de tweede HyperTransport link van de desktop ClawHammer disabled zodat deze goedkopere processors niet in SMP configuraties gebruikt kunnen worden.

[NitroX infinity]

Op donderdag 21 maart 2002 21:59 schreef Femme het volgende:
[Femme gebrabbel]

Kan 't niet zo zijn dat die 6,4Gb gewoon 2* 3,2Gb is en werkt als 6,4Gb? want dan kun je 'm wel splitsen.

[Femme]

Volgens Ace's Hardware heeft-ie dus toch 2x 16-bit (6,4GB/s) HyperTransport.

Check http://www.aceshardware.com/read.jsp?id=45000312 , erg interessant artikel. Volgens AMD komen er in juni 2003 4-way SledgeHammer plankjes op de markt en zal er support zijn van grote OEMs.

[NitroX infinity]

Op donderdag 21 maart 2002 22:23 schreef Femme het volgende:
Volgens Ace's Hardware heeft-ie dus toch 2x 16-bit (6,4GB/s) HyperTransport.

Check http://www.aceshardware.com/read.jsp?id=45000312 , erg interessant artikel. Volgens AMD komen er in juni 2003 4-way SledgeHammer plankjes op de markt en zal er support zijn van grote OEMs.

zou hypertransport ook op videokaarten worden toegepast?

[Anoniem: 33946]

De hammer komt er vrij snel aan hoor, het laatste kwartaal van dit jaar stond in AMD's laatste newsmailing !
Verwacht worden speeds van rond de 3ghz voor het jaareinde, zowel bij Intel als AMD.

[SG]

Op donderdag 21 maart 2002 23:18 schreef sniper het volgende:
De hammer komt er vrij snel aan hoor, het laatste kwartaal van dit jaar stond in AMD's laatste newsmailing !
Verwacht worden speeds van rond de 3ghz voor het jaareinde, zowel bij Intel als AMD.

dat denk ik niet.

Intel heefd een core die optimized is voor hoge clock
AMD komt eind dit jaar met 'n core met een nog hogere IPC en redelijk hoge clocken.

Dat zal dus eerder 3Ghz vs 2Ghz worden.

want die Hammers krijgen ook zo'n speciale rating M3400+ zou de instap zijn.

[Scourger]

Vraagje:
Heeft iemand enig idee hoe het zit met de koelers voor de Hammer? Zullen de huidige koelers daarvoor bruikbaar zijn, of ben je gewoon de pineut als je nu besluit om een vette waterkoeler te kopen?

[Abbadon]

Op vrijdag 22 maart 2002 17:43 schreef Scourger het volgende:
Vraagje:
Heeft iemand enig idee hoe het zit met de koelers voor de Hammer? Zullen de huidige koelers daarvoor bruikbaar zijn, of ben je gewoon de pineut als je nu besluit om een vette waterkoeler te kopen?

Creatief modden en je komt al een heel eind

[SG]

Op donderdag 21 maart 2002 00:20 schreef Femme het volgende:

[..]

De Hammer heeft geen FSB. De geheugencontroller is geïntegreerd op de processor, waardoor de functie van de northbridge is komen te vallen.

Oh jazekers 'n ON-Die FSB

[Anoniem: 23465]

Op donderdag 21 maart 2002 21:34 schreef Femme het volgende:

[..]

We hebben dat gevraagd op CeBIT en ze konden er niet veel over zeggen. Het ziet er inderdaad naar uit dat de Hammers niet overklokbaar zullen zijn.

systeemklok en multiplier zullen nogaltijd moeten gebruikt worden om Hammer op clockpspeed te krijgen, dus met een beetje willende mobo/chipset fabrikanten moet toch zeker die systeemklok aanpasbaar zijn

hoe het met RAM enzo wordt...
ik meen te hebben gelezen dat iedere klokstep van Hammer een andere RAM-divider heeft, dus dat wordt ook raar

[martijn007]

Wat zouden jullie doen?

Wachten op de Hammer of nu een XP kopen?
Ik zit namelijk een beetje te tewijfelen...
Omdat, als ik een XP koop ik aan het eind van het jaar een update naar een Hammer wel kan vergeten.(qua money heb het namelijk niet zo breed...)
En waarschijnlijk kan ik met een moederbord voor een Hammer weer een tijdje vooruit niet? Of zijn er nog meer nieuwe dingen op komst binnen een jaar?
Socket A heeft het namelijk lang vol gehouden... hoop dat dit met de nieuwe moederborden weer zo is..

Wat is jullie mening hierover?

[Abbadon]

Op dinsdag 09 april 2002 18:15 schreef martijn007 het volgende:
Wat zouden jullie doen?

Wachten op de Hammer of nu een XP kopen?
Ik zit namelijk een beetje te tewijfelen...
Omdat, als ik een XP koop ik aan het eind van het jaar een update naar een Hammer wel kan vergeten.(qua money heb het namelijk niet zo breed...)
En waarschijnlijk kan ik met een moederbord voor een Hammer weer een tijdje vooruit niet? Of zijn er nog meer nieuwe dingen op komst binnen een jaar?
Socket A heeft het namelijk lang vol gehouden... hoop dat dit met de nieuwe moederborden weer zo is..

Wat is jullie mening hierover?

Wat ik zou doen? Een cpu kopen XP of P4, maar zeker niet op de Hammer wachten. Waarom? Wel, gezien AMD's ene delay op de andere (760MP, Palomino, Thoroughbred) kun je dan nog héél lang wachten, ik schat dat ze pas in 2003 makkelijk verkrijgbaar zijn (en dan ook nog eerder de 2^e helft dan de 1^e). Vervolgens is het maar afwachten wat de ondersteuning betreft (o.a. het OS dat er op kan draaien en dan natuurlijk alle software), hoewel hij compatible is met 32bit stuff koop je 'm daar natuurlijk niet alleen voor. Eer je er echt het volle potentieel uit kunt halen zijn we wel een paar jaartjes verder (hoe lang heeft de overstap 16bit -> 32bit wel niet geduurd?) Wat dat betreft ben ik niet zo optimistisch.

[Anoniem: 23465]

Op dinsdag 09 april 2002 18:30 schreef Abbadon het volgende:

[..]

Wat ik zou doen? Een cpu kopen XP of P4, maar zeker niet op de Hammer wachten. Waarom? Wel, gezien AMD's ene delay op de andere (760MP, Palomino, Thoroughbred) kun je dan nog héél lang wachten, ik schat dat ze pas in 2003 makkelijk verkrijgbaar zijn (en dan ook nog eerder de 2^e helft dan de 1^e). Vervolgens is het maar afwachten wat de ondersteuning betreft (o.a. het OS dat er op kan draaien en dan natuurlijk alle software), hoewel hij compatible is met 32bit stuff koop je 'm daar natuurlijk niet alleen voor. Eer je er echt het volle potentieel uit kunt halen zijn we wel een paar jaartjes verder (hoe lang heeft de overstap 16bit -> 32bit wel niet geduurd?) Wat dat betreft ben ik niet zo optimistisch.

De overstap 16=>32 was dan ook veeeel groter, met Paging, Protected mode,... al die soorte troep, 32=>64 is veel eenvoudiger op dat vlak eigelijk
daarnaast, wachten op een 64bits OS om Hammer te kopen zie ik ook niet als nuttig, want het punt van Hammer is net dat ge ook een 32bits OS kunt draaien aan full speed, zoda software dus geen probleem is.... en dat zal ook al een pak sneller zijn dan Athlon I'm sure

Ik wacht sowieso op Hammer, zien wat dan het voordeligst is, vind het de moeite niet om nu al te upgraden, (alles draait anyways), en ik doe enkel UT (en later UT2), maar UT2 is voor 2003, en dan is Hammer der, so I can wait

[Plague]

Ik ga iig voor de 0,09 micron hammer met SOI

Ik heb nu een 1,4, en die is nu non-oced, dus daar zit nog een klein rekje in, dus kan ik wel wachten tot de 0,09 uit komt... 1,5 jaar reken ik op.... Q3 2003....

Alleen ik vind het topic nog niet echt "groot" zeg maar

[Anoniem: 23465]

Op dinsdag 09 april 2002 23:41 schreef Plague het volgende:
Ik ga iig voor de 0,09 micron hammer met SOI

Ik heb nu een 1,4, en die is nu non-oced, dus daar zit nog een klein rekje in, dus kan ik wel wachten tot de 0,09 uit komt... 1,5 jaar reken ik op.... Q3 2003....

Alleen ik vind het topic nog niet echt "groot" zeg maar

mjah, die 90nm Hammer, 64mm² alst identiek aan claw zou zijn, kan dus gemakkelijk nog wat verbetering bij als dat nodig is , vermoedelijk zal daar ook wel een roelversie te vinden zijn, maybe met DDR-II tege de tijd ofzow

[Olaf van der Spek]

Op zaterdag 16 februari 2002 16:01 schreef BrZ het volgende:
Hmm.. ik krijg toch echt het idee dat hammers niet voor "normale" mensen zijn... net zoals eigenlijk bijna alle andere 64bit cpu's... denk dat ze voorlopig gewoon te duur worden... zelfs voor een idioot als ik

Binnen redelijke tijd kom je toch in de problemen met de adresruimte van 32-bit CPUs hoor. Zelfs voor 'gewone' consumenten.

[SG]

Op dinsdag 09 april 2002 18:30 schreef Abbadon het volgende:

[..]

Wat ik zou doen? Een cpu kopen XP of P4, maar zeker niet op de Hammer wachten. Waarom? Wel, gezien AMD's ene delay op de andere (760MP, Palomino, Thoroughbred) kun je dan nog héél lang wachten, ik schat dat ze pas in 2003 makkelijk verkrijgbaar zijn (en dan ook nog eerder de 2^e helft dan de 1^e). Vervolgens is het maar afwachten wat de ondersteuning betreft (o.a. het OS dat er op kan draaien en dan natuurlijk alle software), hoewel hij compatible is met 32bit stuff koop je 'm daar natuurlijk niet alleen voor. Eer je er echt het volle potentieel uit kunt halen zijn we wel een paar jaartjes verder (hoe lang heeft de overstap 16bit -> 32bit wel niet geduurd?) Wat dat betreft ben ik niet zo optimistisch.

Aangezien de desktop/home users eerst hun bestaande software en OS gebruiken dus 32bits IA32 koop je de eerste hammers voor 32bit IA32 performance.

Het is naamelijk ook de Follow up concurent tegen de desktop P4 die dan de K7 voorbijfiets en dan de Hammer tegen komt in de 32bit omgeving.

Dat 64bit is van latere zorg als MS met 'n 64bits variant komt en die zijn niet zo vlot als linux.

Dus Hammer is in den begin de High-end 32bit Ahlon vervanger.

Gebruik je geen MS maar linux en die zijn waarschijnlijk wel op tijd met X86-64 Os dan ben je meteen 'n 64Home-bitter.

Het is de Hammers sterkste troef 32/64 hybrid je kan hem dus ook voor 32bit kopen aangezien die hierin ook 'n vooruitgang in is.

Als je het kan uitzingen tot in 2003 zou ik wachten op de Hammer zo niet wachten op de T-bred die is eerder en nu P4/palomino.

[SG]

Op vrijdag 22 maart 2002 17:43 schreef Scourger het volgende:
Vraagje:
Heeft iemand enig idee hoe het zit met de koelers voor de Hammer? Zullen de huidige koelers daarvoor bruikbaar zijn, of ben je gewoon de pineut als je nu besluit om een vette waterkoeler te kopen?

Aangezien Hammers heatspreiders hebben moet de koeler hier ook voor ontworpen zijn.

AMD zou 'n P4 specifikatie variant hebben mits er geen verschillen zijn zijn die er toch dan krijg je 'n extra koeler spesifikatie er bij.

PIII
P4
K7
K8

Veel Socket A koelers die een speciale geprepareerde sweetspot hebben als HSF contact oppervlak, iets wat groter dan de core. de heatspreider zou dan veel te groot zijn voor dit HSF contact vlak waardoor deze socket A HSF ongeschikt zijn dus speciale heatspreider varianten nodig.
Met voldoende grote contact valk voor heatspreider.

[Abbadon]

Ik probeer het gewoon met een gezonde dosis scepsis te aanschouwen, er zijn ons tenslotte al genoeg gouden bergen beloofd door jan en alleman (o.a. AMD en Intel). In hoeverre zal de performance in een 32bit omgeving toenemen? Vergeet niet dat tegen die tijd de P4's al boven de 3GHz zitten en met FSB533 zijn uitgerust. De ClawHammer moet 't doen met een single channel PC2700 interface (later wellicht DDR-II, maar da's later), en dat vormt al een beperking. Het is mooie techniek hoor; on-die memory controller , HyperTransport, NUMA, alleen denk ik dat 'ie pas een vuist kan maken als het -64 gedeelte in x86-64 redlijk goed benut wordt. De P4 was in begin ook een draak van een product, en kijk tot wat die nu staat is. Zo'n soort ontwikkeling verwacht ik ook voor de Hammers, en da's an sich ook vrij logisch voor een totaal nieuwe processor met afwijkende architectuur. Maar misschien zit ik er wel naast, wie weet. Alleen mogen ze er om mij wel wat meer vaart achter zetten; de XP is in feite al een achterhaald product zonder al te veel rek (stapjes van 66MHz is met zulke kloksnelheden natuurlijk te belachelijk voor woorden).

[Anoniem: 37655]

Ik kijk gewoon wart de beste pw-config is en koop er gewoon 20... doh werkuh kwe nie waar me geld heen fgaat :=+

[SG]

Op woensdag 10 april 2002 21:07 schreef Abbadon het volgende:
Ik probeer het gewoon met een gezonde dosis scepsis te aanschouwen, er zijn ons tenslotte al genoeg gouden bergen beloofd door jan en alleman (o.a. AMD en Intel).

Ja dat denk ik ook de Hammer is nu onderhevig aan hype. Mensen met veelt te hoge verwachtingen van de Hammer. Ik doe er ook niet aan mee na al die overhypte produkten in het verleden, moet je ondertussen wel weten dat je op vele reviews moet wachten voor de harde feiten. Real-live Performance

In hoevere zal de performance in een 32bit omgeving toenemen?

K8 is gebaseerd op K7, dus K7+ performance door vele verbeteringen en omdat er zoveel verschillende verbeterinen of technieken worden gebruikt is het een grote vraagteken maar in ieder geval schaald deze weer wat beter op de clock dus zal zeker AMD snelste worden zelfs met gelijk of iets betere IPC, dus als AMD aanhanger zul je toch voor K8 moeten kiezen omdat dit de upgradepad bied voor de toekomst socket A is een doodlopend spoor, ongeacht weinig of grote performance verbetering.

Vergeet niet dat tegen die tijd de P4's al boven de 3GHz zitten en met FSB533 zijn uitgerust. De ClawHammer moet 't doen met een single channel PC2700 interface (later wellicht DDR-II, maar da's later), en dat vormt al een beperking.

Je bent wel van intel onder de indruk met zijn slappe(low IPC) hoge clocken en zijn O zo grote FSB.
Intels performance voorsprong ligt groten deels aan hun produktie procses voorsprong 0,13 vs 0,18.
AMD heeft over een lange periode met zijn low FSB CPU intel met performance kunnen verslaan op enkele bijzondere situatie na, FSB is niet zalig makend maar een van de factoren die invloed hebben op performance met een sterk gevarierende mate per applicatie. Waarbij 'n groot deel dus blijkbaar niet FSB dependend of negatief gevoelig voor de netburst architektuur.

De Hammer is tov de Athlon ook 'n FSB verbetering.
Geen FSB bottle neck doordat de FSB vervalt, alleen heeft het natuurlijk voordelen maar ook nadelen.

Het is mooie techniek hoor; on-die memory controller , HyperTransport, NUMA, alleen denk ik dat 'ie pas een vuist kan maken als het -64 gedeelte in x86-64 redlijk goed benut wordt. De

Tja in de HAmmer tijd lijkt het mee heel interresant voor DUAL AMD te gaan 'n OS met NUMA drivers heb je dan wel nodig, maar als ze aan bijde CPU geheugenbanken implementeren, dan is je Mem bandbreedte in een specifieke opzicht ook verdubbeld, this dus weer een duidelijke vooruitgang tov de point to point 760MP(x)
en eindelijk ook
+++ Heatspreider

P4 was in begin ook een draak van een product, en kijk tot wat die nu staat is. Zo'n soort ontwikkeling verwacht ik ook voor de Hammers, en da's an sich ook vrij logisch voor een totaal nieuwe processor met afwijkende architectuur.

Nee dit lijkt mee niet hetzelfde.
de P4 Netburst lijkt meer, het zelfde software probleem in mindermate, op de iTanium EPIC te hebben.
Bijde hebben gerecomplileerde software nodig en de ander emuleerd. omdat de bestaande oude software IA32 sterk negatief op netburst(EPIC ook) reageerde.
De P4 deed en doet nu nog in sommige extreme gevallen extreem slecht zelfs nu. P4 is dus sterk van software patching, recomplilatie, optimalisatie, SSE2 afhankelijk.
De P4 is een long term oplossing die in 2 á 4 jaar na software migratie zijn innoverende krachten laat zien zoals grote SSE2 support en P4 gecomplileerde software. Nu surfen ze puur op produktie prosces AMD voorbij.

De Hammer is gebasseerd op 'n oude techniek de ge-extendeerd( 64bits )is en geoptimaliseerd/tuned
En zal dus direct met bestaande software goed presteren omdat ze minder recompiler afhankelijk zijn op IA32 gebied.

En bij overstap naar x86-64 krijg je 'n extra boostje in sommige gevallen.

Maar misschien zit ik er wel naast, wie weet. Alleen mogen ze er om mij wel wat meer vaart achter zetten; de XP is in feite al een achterhaald product zonder al te veel rek (stapjes van 66MHz is met zulke kloksnelheden natuurlijk te belachelijk voor woorden).

AMD zou es wat meer onpar moeten lopen met hun produktie prosces. We hadden eigenlijk nu op de barton moeten wachten die T-bred aflosten ip van op T-bred dus ze lopen overduidelijk achter met hun 0,13 ben benieuwed hoe het ,met 0.09 gaat zal wel 0,09(intel) vs 0,13SOI(AMD) worden helaas.

Ik denk dat die ClawHammers als High-end Desktop CPU zal worden geleverd en T-Bred als midrange mainstream en zal nog wel 'n tijdje naast de C-Hammer lopen.

[Abbadon]

Op vrijdag 12 april 2002 19:28 schreef SuperG een heel verhaal:

Nader bekeken kan ik me wel vinden in jouw verhaal Alleen ben ik niet onder de 'indruk' () van de P4 door z'n IPC en hoge clock, maar door de 'total package'; snel, niet te warm, heatspreader, schaalbaarheid, hoge FSB, dikke L2 en natuurlijk de HS bevestiging. Deze voordelen vloeien idd deels voort uit het 0.13µ proces, dus AMD heeft wat te laten zien.
Alleen had ik de laatste tijd wat meer van AMD verwacht; zo'n voorsprong op Intel, en dat hebben ze het afgelopen half jaar gestaag uit handen gegeven door al die delays.

[SG]

Je kan het ook zo zien.
Intel had hiervoor geen echte concurent gehad en liep op zijn louweren bepaalden zelf de tempo van de ontwikkelingen en liepen dus ook, in mijn ogen misschien overdrijf ik, achter op de software. CPU's van tegenwoordig zijn bij de huidige versies van de software van toen echt overkill.

Nu er een Competitor is op gestaan en hun offgaurd te kijk heeft gezet. Houd intel de boel beter in de gaten en werkt dus nu wel voor omdat ze niet verrast willen worden door AMD die blijkbaar wel 'n dreiging kan zijn.
Ben dus ook wel benieuwd of die Yamill geruschten waar zijn.
iNtel is dus nu wel op zijn hoede en AMD zal dat ook merken en krijgt dus nu competitie die op rails loopt dan toen in het late PIII tijdperk.

[SG]

Abbadon, ik zie dat je 'n AMD Dual'er bent dus zal je ook wel benieuwed zijn naar DUAL Claw-Hammer MP.
Alleen is er nog zo weinig over bekent.

Ik had me de afgelopen tijd weloverwogen voor 760MPX platform maar dacht wacht maar effe op de T-bred MP scheeld vermogen maar met meer performance.

Maar omdat de Hammer dicht bij komt en al die platform bijzonderheden zeer interresant klinken zoals NUMA Mem-on-die-controler Hypertransport tov van DP & MP systemen lijkt mij het wel waard om op deze radicaal nieuwe MP technieken te wachten.

Vooral als de Reviews de MP schaling door die nieuwe technieken duidelijk weergeven zoals dat nu al met Shared vs Point to point al in 'n bepaalde mate, maar niet baan brekend, is aangetoond.

Ben ook benieuwed hoe betaalbaar of onbetaalbaar DUAL Sled-Hammer zal worden.

Dat wordt dan 'n CPU aan 128bits PC2700 en nog 'n keer het zelfde, dus 256bits PC2700 power voor de treads hppelijk scheeld dit ook werkelijk duidelijk iets in real-life op papier ziet het er zeer mooi uit. Mits er 'n DUAL sledge mobo komt of beginnen die vanaf 4waye mobo's

* Anoniem: 14616 is effen aan het dromen en zit al te trappelen van ongeduld, wat duurt het toch nog lang, en hopelijk zijn ze op schema.

[Femme]

AMD is zelf best wel zelfverzekerd dat ze Q4 gaan halen en dat ClawHammer sneller zal zijn dan de snelste P4 van dat moment. Volgende week worden de Q1 resultaten bekend gemaakt en wordt er een nieuwe TeamAMD tour in de VS en Canada gestart, dus waarschijnlijk komt er binnenkort weer nieuwe informatie over ClawHammer en SledgeHammer beschikbaar.

Dat AMD zijn voorsprong heeft kwijt geraakt is niet erg bijzonder. De K7 was veel schaalbaarder dan de P6 en dus het AMD het performance voordeel. De P4 is op zijn beurt veel schaalbaarder dan de K7, maar de IPC liep nogal achter. Dankzij de veranderingen in de Northwood heeft Intel de IPC wat kunnen verbeteren en lopen ze nu dankzij de goede schaalbaarheid voorop. Zostraks als de ClawHammer op de markt komt kan AMD weer de voorsprong pakken totdat Intel overgaat op 0,09 micron.

[Abbadon]

Op vrijdag 12 april 2002 21:46 schreef SuperG het volgende:
Abbadon, ik zie dat je 'n AMD Dual'er bent dus zal je ook wel benieuwed zijn naar DUAL Claw-Hammer MP.
Alleen is er nog zo weinig over bekent.

Ik had me de afgelopen tijd weloverwogen voor 760MPX platform maar dacht wacht maar effe op de T-bred MP scheeld vermogen maar met meer performance.

Maar omdat de Hammer dicht bij komt en al die platform bijzonderheden zeer interresant klinken zoals NUMA Mem-on-die-controler Hypertransport tov van DP & MP systemen lijkt mij het wel waard om op deze radicaal nieuwe MP technieken te wachten.

Vooral als de Reviews de MP schaling door die nieuwe technieken duidelijk weergeven zoals dat nu al met Shared vs Point to point al in 'n bepaalde mate, maar niet baan brekend, is aangetoond.

Ben ook benieuwed hoe betaalbaar of onbetaalbaar DUAL Sled-Hammer zal worden.

Dat wordt dan 'n CPU aan 128bits PC2700 en nog 'n keer het zelfde, dus 256bits PC2700 power voor de treads hppelijk scheeld dit ook werkelijk duidelijk iets in real-life op papier ziet het er zeer mooi uit. Mits er 'n DUAL sledge mobo komt of beginnen die vanaf 4waye mobo's

* Anoniem: 14616 is effen aan het dromen en zit al te trappelen van ongeduld, wat duurt het toch nog lang, en hopelijk zijn ze op schema.

toon volledige bericht

Oh ja, daar ben ik zeker benieuwd naar, met name naar het Non-Uniform Memory Acces aspect. Nagenoeg elke serieuze server (b.v. Sun) gebruikt die techniek. Als AMD het goed weet te implementeren kan het heel wat worden lijkt me Met de on-die memory controller zie ik overigens nog een verband met Sun, en ik heb 't wel op met Sun's (werk er ook mee). Ik ben dan ook erg nieuwsgierig hoe dit zich in de praktijk gaat gedragen qua snelheid, maar ook qua robuustheid (vereiste als ze deze techniek te gelde willen maken). En het voordeel is dat met de goedkopere Clawhammer (ik neem aan dat de Clawhammer duidelijk goedkoper zal worden dan de SledgeHammer) in DP opstelling de totale geheugenbandbreedte t.o.v. een dual Xeon niks minder is, zelfs beter .
Denk dat een dual Sledge wel erg in de papieren gaat lopen, maar dan heb je wel wat (10.8GB/s aggregate bandwith ). Heb iig weer iets om naar uit te zien.

[SG]

Op vrijdag 12 april 2002 23:02 schreef Femme het volgende:
AMD is zelf best wel zelfverzekerd dat ze Q4 gaan halen en dat ClawHammer sneller zal zijn dan de snelste P4 van dat moment. Volgende week worden de Q1 resultaten bekend gemaakt en wordt er een nieuwe TeamAMD tour in de VS en Canada gestart, dus waarschijnlijk komt er binnenkort weer nieuwe informatie over ClawHammer en SledgeHammer beschikbaar.

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.
Ze moeten die Hammer eerst afmaken en daar hebben ze nu 6 maanden voor dus d'r kan nog al wat misgaan. Zelfs iNtel haald vaak zijn roadmaps niet. Dus dan zou het een hele prestatie zijn als AMD deze laaste roadmap waarmaakt.
Ik zal pas echt zekerheid krijgen als de eerste officiele aankondiging is want dan is ie zeker al klaar en moet dan in massa produktie.

Dat AMD zijn voorsprong heeft kwijt geraakt is niet erg bijzonder. De K7 was veel schaalbaarder dan de P6 en dus het AMD het performance voordeel. De P4 is op zijn beurt veel schaalbaarder dan de K7, maar de IPC liep nogal achter. Dankzij de veranderingen in de Northwood heeft Intel de IPC wat kunnen verbeteren en lopen ze nu dankzij de goede schaalbaarheid voorop. Zostraks als de ClawHammer op de markt komt kan AMD weer de voorsprong pakken totdat Intel overgaat op 0,09 micron.

Dat AMD zijn voorsprong kwijt is in mijn ogen aan:
1)iNtels produktie prosces voorsprong. 0,13 vs 0,18
2)iNtels CPU krijgen nu al standaard 512KB cache
3) intel met de tijd ook een FSB bandbreedte verhoging door voerd. 400 naar 533 naar 666.

AMD loopt op al die drie punten met de Athlon XP achter.
Om verschillende redenen.
1) AMD CPU zijn afhankelijk van de DDR-Sdram ontwikkeling en die is op PC2700 blijven steken en zal het in de toekomst gaan maken als meenstraim EV6 kan ook 400FSB leveren maar de memory implementatie van nu niet DDRII is hier beter geschikt voor.
2) Socket A wordt binnenkort afgelost door socket C-Hammer dus FSB verhogen jaagd costumors op kosten ivm nieuwe mobo met nieuwe chipset en nieuwe reeks CPU met nieuwe FSB locking
3) Intel heeft meer fabrieken en dus voldoende produktie capaciteit waardoor extra L2 geen probleem is maar ook nodig omdat ondanks de FSB groot is tov de CLock loopt het ver achter.

[Anoniem: 23465]

met 0.09 gaat zal wel 0,09(intel) vs 0,13SOI(AMD) worden helaas.

Normaalgezien gaat dat niet het geval zijn, want zowel Intel als AMD hebben 90nm voor H2 2003 gepland, nuja, ik zeg gepland ;à

merk bijvoorbeeld ook op, Intel zit nu dan wel al op 130nm, en AMD moet 130nm nog introduceren, maar tegen einde van 2002 doet AMD enkel nog 130nm, en valt 180nm gewoon weg, terwijl Intel nog verderhopt op 180nm met bijvoorbeeld Celeron (Willamette-128)

nog een laatste: AMD was ook vrij laat met hun 250nm-process, maar 180nm was dan weer zeer snel gedaan, misschien dat de overgang naar 130nm en later 90nm een gelijkaardig effect geeft ?

[Abbadon]

Hmmm, heb me even wat verder verdiept in NUMA (voor zover het me lukt, 't is vrij moeilijk als je er het mijne van wil weten), maar in tegenstelling tot wat ik eerder zei maken de huidige Sun's er géén gebruik van (wel iets wat er wat op lijkt, COMA). Ik begin me nu ook af te vragen of NUMA voordelen biedt boven SMP in een dual opstelling, volgens mij wordt 't pas interessant als er meerdere cpu's gebruikt worden. Zal er binnenkort wat meer over opzoeken. Mensen die er meer verstand van hebben?

[Beaves]

Op zaterdag 13 april 2002 14:28 schreef GiGNiC het volgende:
terwijl Intel nog verderhopt op 180nm met bijvoorbeeld Celeron (Willamette-128)

Maar dat is dan ook hun budget CPU, hun mainstream CPU's worden al volledig op 0,13 micron gebakken (kan ook niet anders )

AMD hoeft ook maar een fabriek om te bouwen, Intel moet er veel meer, en dat hoeft niet allemaal tegelijk, de Celeron is op 0,18 micron ook goed genoeg.

[Anoniem: 23465]

Op zaterdag 13 april 2002 18:11 schreef Abbadon het volgende:
Hmmm, heb me even wat verder verdiept in NUMA (voor zover het me lukt, 't is vrij moeilijk als je er het mijne van wil weten), maar in tegenstelling tot wat ik eerder zei maken de huidige Sun's er géén gebruik van (wel iets wat er wat op lijkt, COMA). Ik begin me nu ook af te vragen of NUMA voordelen biedt boven SMP in een dual opstelling, volgens mij wordt 't pas interessant als er meerdere cpu's gebruikt worden. Zal er binnenkort wat meer over opzoeken. Mensen die er meer verstand van hebben?

Heb je ergens een link voor COMA ? NUMA kennek zo wel denkik

[Abbadon]

Op zaterdag 13 april 2002 19:04 schreef GiGNiC het volgende:

[..]

Heb je ergens een link voor COMA ? NUMA kennek zo wel denkik

Moet ik ff weer zoeken, maar ik moet nu weg.

[SG]

Op zaterdag 13 april 2002 18:11 schreef Abbadon het volgende:
Hmmm, heb me even wat verder verdiept in NUMA (voor zover het me lukt, 't is vrij moeilijk als je er het mijne van wil weten), maar in tegenstelling tot wat ik eerder zei maken de huidige Sun's er géén gebruik van (wel iets wat er wat op lijkt, COMA). Ik begin me nu ook af te vragen of NUMA voordelen biedt boven SMP in een dual opstelling, volgens mij wordt 't pas interessant als er meerdere cpu's gebruikt worden. Zal er binnenkort wat meer over opzoeken. Mensen die er meer verstand van hebben?

Ik denk dat het meer afhangt van de code dependentie van de applicaties.

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.

Hier zal Numa vs Dual CPU op shared bus weinig uitmaken.

SMP software, die CPU én geheugen bandbreedte afhankelijk is, zal met 'n shared bus steeds minder tot nauwelijks baat bij MP sytemen hebben bijvoorbeeld maar 25 á 40% winst bij dual en MP nauwelijks, NUMA systeem shaald dan beter door met meer dan 50% ook elk extra CPU zou toch een performance verbetering laten zien tov shared bus.

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.

Ik vraag me ook af of de applicatie ook Numa aware moet zijn? Ik hoop het niet.

Op de T.net frontpage staat 'n preview van de hammer's.

"AMD Hammer platform preview"
Hier worden de voor-na delen ook aangekaart van Hammer Numa platform en meer.

[Olaf van der Spek]

Ik denk dat een applicatie wel zo geschreven moet zijn dat het goed werkt met NUMA, omdat niet meer al het geheugen even snel benaderbaar is voor elke thread.

[Badger]

Wat ik mij afvraag is hoe heet deze krengen gaan worden en of ze er betere thermische veiligheden in gaan bouwen.

Ik geloof dat er bij het verslag van die show van amd er wat geheimzinnig over OC-en werd gedaan maar dat het wel mogelijk was. Niet dat ut veel boeit om te OC-en met zoveel geweld

Iig ga ik voor een dual config. Als het moment daar is ga ik kijken welk platform de beste prijs/prestatie verhouding heeft. AMD belooft veel maar Intel zit ook niet stil. Dus het wordt gewoon afwachten.

[Abbadon]

Zoals ik begrijp zit het zo: beide Hammers hebben hun eigen lokale geheugen, namelijk die DIMM's die aan de on-die geheugencontroller hangen (dat noemen we het 'L3 cache'). Stel cpu 0 heeft data nodig dat niet in het L3 cache staat, maar in de DIMM's die aan de controller van cpu 1 hangen (het 'remote geheugen'). 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. Er is dus een heel goed NUMA algoritme of wat dan ook nodig om er voor te zorgen dat de benodigde data in de juiste lokale geheugenbanken staat. Voor slechts een DP opstelling kan ik me voorstellen dat SMP toch de betere/snellere manier is; de verbinding met het gesharede geheugen zal niet snel verzadigd raken door twee cpu's. Dit laatste wel met meerdere cpu's, waardoor me dan NUMA beter tot z'n recht lijkt te komen. Dit is, heb ik gisteren gelezen, ook hét punt waarom bijvoorbeeld Sun (en die weten er ook wel wat van ) zo ageert tegen NUMA; de latentie issues zijn te groot, en waarom de nieuwste Sun dozen dus simple COMA, (cache-only memory architecture) gebruiken (wat ik nog moet uitzoeken wat dat nu weer precies betekend). Hmmm, in ieder geval brengt AMD op deze manier wel interessante nieuwe technieken naar de desktop

[Olaf van der Spek]

Het lijkt een beetje op de voodoo memory architectuur.
Maar volgens mij werkt NUMA alleen goed met speciale apps en is het dus niet zo interessant voor de thuisgebruiker.

[SG]

Op zondag 14 april 2002 13:37 schreef Abbadon het volgende:
Zoals ik begrijp zit het zo: beide Hammers hebben hun eigen lokale geheugen, namelijk die DIMM's die aan de on-die geheugencontroller hangen (dat noemen we het 'L3 cache').

Het lijkt op L3 Cache per CPU mem paar alleen het is geen Cache maar het werk geheugen er wordt hier niks traags gebufferd waar Cache functie voor staat.

Stel cpu 0 heeft data nodig dat niet in het L3 cache staat, maar in de DIMM's die aan de controller van cpu 1 hangen (het 'remote geheugen'). 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.

Dat valt misschien reuze mee door de memorry controller ondie te maken vervalt 'n Northbridge latancy en remote memory wordt aangesproken via 'n andere CPU die dan als northbridge voor de fungeerd.

dus vroeger en bij sharedbus:
CPU <FSB> ChipsetNB <Membus> Dimms

bij hammer
CPU <Membus> Dimms
en/of in remote geval
CPU <HTbus> RemoteCPU <Membus> Dimms

Dus in DUAL krijg je latency zoals in geval van northbridge(=nu buur CPU) en bij quad meestal ook maar bij acht CPU kunnen de buitenste wat meer latency hebben.

Je hebt performance verlies maar geen extreme misschien wel merkbaar. Bij meer dan Quad systemen speeld dit een grotere rol tenzij de NUMA drivers efficient en optimaal werken.

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.

Dat is omdat het shared memory al de penalty is wat men probeert op telossen met NUMA COMA methoden.

Er is dus een heel goed NUMA algoritme of wat dan ook nodig om er voor te zorgen dat de benodigde data in de juiste lokale geheugenbanken staat. Voor slechts een DP opstelling kan ik me voorstellen dat SMP toch de betere/snellere manier is; de verbinding met het gesharede geheugen zal niet snel verzadigd raken door twee cpu's. Dit laatste wel met meerdere cpu's, waardoor me dan NUMA beter tot z'n recht lijkt te komen. Dit is, heb ik gisteren gelezen, ook hét punt waarom bijvoorbeeld Sun (en die weten er ook wel wat van ) zo ageert tegen NUMA; de latentie issues zijn te groot, en waarom de nieuwste Sun dozen dus simple COMA, (cache-only memory architecture) gebruiken (wat ik nog moet uitzoeken wat dat nu weer precies betekend). Hmmm, in ieder geval brengt AMD op deze manier wel interessante nieuwe technieken naar de desktop

Het wordt dus in DUAL opstellingen NUMA vs Sharedbus reviews afwachten.

Mij lijkt dat AMD voor 'n On-die memory controller gekozen heeft, meer een vereiste aangezien NUMA hier wel gevoelig voor is.
BTW hebben die SUN CPU 's ook on-die mem controlers aangezien als dit niet het geval is de performance hit zwaarder is door hogere latency.

[SG]

Op zondag 14 april 2002 14:19 schreef OlafvdSpek het volgende:
Het lijkt een beetje op de voodoo memory architectuur.
Maar volgens mij werkt NUMA alleen goed met speciale apps en is het dus niet zo interessant voor de thuisgebruiker.

De enige overeenkomst die ik zie is dat elke chip zijn eigen mem heeft alleen wordt er erg verkwistend mee omgegaan aangezien die quad VSA-100 bord al 128MB nodig had om 32MB kaartjes te evennaren waarom omdat elke VSA-100 zijn eigen texture copy nodig heeft in zijn eigen dedicated memory pool.

zover ik weet.

Het NuMA SYSTEEM is hier 'n oplossing voor of singlechip GPU design wat nVidia groot heeft gemaakt aangezien ATI van hun MAXX variant ook is afgestaped aangezien bij GPU ook 'n Die schrink helpt aangezien 3DFX hierin ook achterliep de eerste VSA-100 concurreerden al tegen GPU op 'n kleinere dieshrink.
En multichip oplossingen zijn normaal veel duurder in kosten dan singlechip oplossingen.

Aangezien 3DFX produkten toen gericht waren op vooral gamers en daar is bij de massa het budged ook heel belangrijk en moet je kosten beperken om flexible op de markt eigenaardigheden te kunnen reageren.

Behalve waar geld geen rol speeld. zie proffessionele kaarten hebben vaak multichip en multi memory systemen.

Net als high end MP servers speeld poen geen hoofdrol dus multy CPU opplossingen is markt voor.

[Anoniem: 23465]

Dat valt misschien reuze mee door de memorry controller ondie te maken vervalt 'n Northbridge latancy en remote memory wordt aangesproken via 'n andere CPU die dan als northbridge voor de fungeerd.

dus vroeger en bij sharedbus:
CPU <FSB> ChipsetNB <Membus> Dimms

bij hammer
CPU <Membus> Dimms
en/of in remote geval
CPU <HTbus> RemoteCPU <Membus> Dimms

Dus in DUAL krijg je latency zoals in geval van northbridge(=nu buur CPU) en bij quad meestal ook maar bij acht CPU kunnen de buitenste wat meer latency hebben.

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.

[Anoniem: 14353]

lamaar

[Olaf van der Spek]

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?

[SG]

Misschien kunnen ze ook mekaars L2 cache benaderen

CPU0 < HTbus > CPU1

[Abbadon]

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)

[SG]

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.

[Anoniem: 23465]

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)

[Femme]

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.

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.

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.

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).

[Abbadon]

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).

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

[SG]

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.

[Abbadon]

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).

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.

[Olaf van der Spek]

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?

[Olaf van der Spek]

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.

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.

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

[Anoniem: 24441]

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

Kun je er nl. ook een spelletjuh met spelen?

[Abbadon]

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.

[Anoniem: 23465]

Direct connection to 8 registered DIMM's

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

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).

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 )

[Anoniem: 23465]

woops, messed up signature

[Femme]

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.

[SG]

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.?

[Anoniem: 23465]

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

[Femme]

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?.

[SG]

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.

[Femme]

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.

[Olaf van der Spek]

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?

[Anoniem: 23465]

LoLzZzz, Athlon = Clawhammer, Opteron = Sledgehammer

marketingsgewijs een mooie zet

[Anoniem: 43390]

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