Het grote AMD Hammer topic

[SG]

Opteron and Itanium: Two Roads to 64-bit Computing

http://www.aceshardware.com/read.jsp?id=50000240

'N leuk artikeltje over 64bit computing voor de workstation markt waar het om Hammer vs Xeon&dearfield en nog meer.

[Verwijderd]

Op zaterdag 06 juli 2002 20:40 schreef SuperG het volgende:
Opteron and Itanium: Two Roads to 64-bit Computing

http://www.aceshardware.com/read.jsp?id=50000240

'N leuk artikeltje over 64bit computing voor de workstation markt waar het om Hammer vs Xeon&dearfield en nog meer.

indeed, lekker artikeltje.



terugkomen op die basisklok:

systeemklok is 1.19ennogwatMhz
klokgenerators draaien 14.nogwat Mhz, waarna dus PLL-multiplication optreed.

had ffjes wat doorheen gehaald

[SG]

Staat nu ook op de frontpage news van T.net

[Verwijderd]

Het blijkt weer kalm op het Hammer-front

/me can't wait till µPF

[SG]

Het meeste nieuws wat er uitrold is vaak het aankondigen van ondersteuning voor de hammer en dat is dus een goed teken voor markt acceptatie en dus kans vergroting voor sucses en floppen wordt dan wat moeilijker voor de hammer. Vooral als ze op schema blijven en er geen grote uitstelingen komen betreffende de roadmap.

[BalusC]

Even voor de overzicht nog alle (aangekondigde) Hammer chipsets met alle belangrijkste features:

naam	link	RAM	PCI	ATA
AMD8000 Lokar (8111 + 8151)	HT (800MB/s)	DDR PC2700	2.2 33MHz (8 slots)	ATA7 (133MB/s)
AMD8000 Golem (8111 + 8131 + 8151)	HT (800MB/s)	DDR PC2700	2.2 33MHz (8 slots) én PCI-X 133MHz (5 slots)	ATA7 (133MB/s)
VIA K8T400 (? + VT8235)	V-link (533MB/s?)	DDR PC3200	2.2 33MHz (? slots) én PCI-64 66MHz (? slots)	ATA7 én SATA1 (150MB/s)
VIA K8M400 met Zoetrope AGP (? + VT8235)	V-link (533MB/s?)	DDR PC3200	2.2 33MHz (? slots) én PCI-64 66MHz (? slots)	ATA7 én SATA1 (150MB/s)
VIA K8T400M mobile chipset (? + VT8235)	V-link (533MB/s?)	DDR PC3200	2.2 33MHz (? slots) én PCI-64 66MHz (? slots)	ATA7 én SATA1 (150MB/s)
SiS 755 (755 + 963)	MuTIOL (1066MB/s)	DDR PC3200?	2.2 33MHz (6 slots)	ATA7 (133MB/s)
SiS 760 met AGP (760 + 963)	MuTIOL (1066MB/s)	DDR PC3200?	2.2 33MHz (6 slots)	ATA7 (133MB/s)
nVidia Crush K8	HT (800MB/s)	DC DDR PC2700	2.2 33MHz (6 slots)	ATA7 én SATA1 (150MB/s) SW RAID?
nVidia Crush K8G met GF4MX	HT (800MB/s)	DC DDR PC2700	2.2 33MHz (6 slots)	ATA7 én SATA1 (150MB/s) SW RAID?
ALi M1687	HT (800MB/s)	DDR PC2700	2.2 33MHz (? slots)	ATA7 én SATA1 (150MB/s)
ALi M1688 met Trident XP4	HT (800MB/s)	DDR PC2700	2.2 33MHz (? slots)	ATA7 én SATA1 (150MB/s)

Ze hebben allemaal AGP 8x ondersteuning en zes USB 2.0 poorten.

Tot zover ziet de nVidia Crush K8(G) IMHO het lekkerst uit: DC DDR en Serial ATA

[ Voor 0% gewijzigd door BalusC op 19-08-2002 16:56 . Reden: tabel bewerkt (AGP en USB eruit) - edit2: GF4MX ipv GF4Ti bij K8G - edit3: oops.. 150MB/s ipv 1,5GB/s - edit4: VIA chipsets aangepast ]

[Brent]

BalusC schreef op 16 augustus 2002 @ 09:29:
Tot zover ziet de nVidia Crush K8(G) IMHO het lekkerst uit: DC DDR en Serial ATA

mee eens. als die nvidia een beetje snel uit is, dan neem ik die chipset.

btw, de K8G, daar zit dus een gf4ti in. weet iemand al hoe snel die is (ti4200/ti4400/ti4600)? en hoe goed werken trouens Ati kaarten op nvidia chipsets?

[BalusC]

Ik heb effe research gedaan en het blijkt dat ik de info over de Crush K8 moet bijstellen. Er wordt namelijk vaker vermeld over een integrated GF4MX dan GF4Ti.. Tabel is aangepast

Hieronder nog ff een picje van de eerste release van zo'n Crush K8 plankje

[Verwijderd]

Ik moet er u op wijzen dat geen enkele Clawhammer chipset dual channel memory gaat hebben.

De memory controller zit namelijk in de CPU, en die doet enkel single channel DDR333 (PC2700) bij release, dus pas uw tabel al maar weer aan

edit:

Tenzij een van die bedrijve zo stoem is van on-chip controller af te zetten en ene in hun northbrdige te gebruike

[Brent]

BalusC schreef op 16 augustus 2002 @ 12:46:
Er wordt namelijk vaker vermeld over een integrated GF4MX dan GF4Ti.. Tabel is aangepast

hmm, nou dan wordt die het iig niet dan maar de 'gewone' crush. en is het waar wat de reactie van GiGNiC betreft, heeft nvidia de memcontroller idd uitgeschakeld? want ik zie maar 1 chip(set) dus lijkt me niet dat nvidia opeens een single-chip-architecture+memcontroller heeft bedacht.

Verwijderd schreef op 16 augustus 2002 @ 14:35:Tenzij een van die bedrijve zo stoem is van on-chip controller af te zetten en ene in hun northbrdige te gebruike

en dat zal nvidia wel gedaan hebben of ze hebben er iets op gevonden.

[BalusC]

Verwijderd schreef op 16 augustus 2002 @ 14:35:
Ik moet er u op wijzen dat geen enkele Clawhammer chipset dual channel memory gaat hebben.

Inderdaad.. Maar de Sledgehammer ondersteunt daarentegen wél DC DDR

[Brent]

BalusC schreef op 16 augustus 2002 @ 15:26:
[...]
Inderdaad.. Maar de Sledgehammer ondersteunt daarentegen wél DC DDR

maar dan kan die nVidia K8-chipset toch nooit DC DDR zijn?

[Aham brahmasmi]

Ja jemig, wat is dat nouw voor boelsjit!! S-ATA werkt in de eerste instansie toch gewoon op 150 MB/s en niet 1,5 GB/s???

En dat de Clawhammer geen DC DDR zou ondersteunen is ook iets wat ik me uit vroege posts op T.net over de Hammer herinner, maar of dit ook onmogelijk is als de on-die memcontroler uitgeschakeld is heb ik nog niet gelezen.
Als dit niet mogelijk is, dan heeft DDR en zelfs DDR-II niet zo'n supermooi perspectief... dual channel technologie lijkt mij toch iets wat nodig is om voor de beperkte schaalbaarheid (MHz op de geheugenbus) van DDR(II) te compenseren (ook t.o.v. RDRAM).
Ik vind dat ze bij AMD toch wel een beetje stom zouden zijn als ze de Clawhammer bij de release geen DDR-II zouden ondersteunen (333 MHz fsb zou IIG moeten ), eventueel via een (off-die) mobo-chipsetje.

[BalusC]

Thermo man schreef op 16 augustus 2002 @ 16:02:
Ja jemig, wat is dat nouw voor boelsjit!! S-ATA werkt in de eerste instansie toch gewoon op 150 MB/s en niet 1,5 GB/s???

Oops.. dumb van me.. Het is nu alweer gecorrigeerd, thnx

En wat betreft de Crush K8: hoogstwaarschijnlijk slaat die DC DDR bus eerder op de 128bits geheugenbus van de geïntegreerde GF4MX bij de Crush K8G. Maar ik zou niet vreemd opkijken als dit later ook kan worden gebruikt in combinatie met de DC DDR capaciteiten van de Sledgehammer.

[Brent]

BalusC schreef op 16 augustus 2002 @ 17:31:
[...]
Oops.. dumb van me.. Het is nu alweer gecorrigeerd, thnx

En wat betreft de Crush K8: hoogstwaarschijnlijk slaat die DC DDR bus eerder op de 128bits geheugenbus van de geïntegreerde GF4MX bij de Crush K8G. Maar ik zou niet vreemd opkijken als dit later ook kan worden gebruikt in combinatie met de DC DDR capaciteiten van de Sledgehammer.

bij de nVidia Crush K8G staat nu trouens SATA 150GB/sec. en die 128bit membus is alleen bij die chipset met geïntegreerde videokaart?

[Verwijderd]

Voor Crush K8:

De latency die een of-die controller met zich meebrengt zal waarschijnlijk de extra bandbreedte niet compenseren (en je zit zowiezo maar met 3.2GB leessnelheid, en 3.2GB schrijven), dus met PC2700 zal je met on-die controller verder geraken.

in een chipset met graphics zou maybe die DC memcontroller enkel voor de GPU kunnen gereserveerd worden, maybe nog niet zo'n slecht idee, al neemt dat dan weer plek in op je mobo (vergeet slots), SiS 755 reference bord heeft dat al denkik

[SG]

Het is ook van belang hoe groot die latency is van die HyperTransportBus (HTB) vs Ondie controlee.
En dan is het ook 3,2GB/s één richting op dus het is bidirectioneel met in het ideale geval 6,4Gb/s

[Verwijderd]

ja idd, da wilde ik dus uitleggen

[SG]

Het is ook mogelijk met Ondie en Nortbridge me controler te werken.
CPU en GPU hebben dan dedicated memory
dus 'n mobo met 3 á4 Dimm sloten 2 voor de CPU 1 á2 voor de GPU in de Northbridge

Ook is mogelijk hybride bordjes te maken maar of daar vraag naar is? dus DDR-CPU voor Hybride bordt met DDR Dimms aan CPU en DDRII dimms aan Northbridge.

Movht DDRII-mem er sneller komen dan DDRII-CPU

[apa]

Ze kunnen misschien dezelfde weg opgaan als met hun mobiele GPU's. Daar hebben ze 1 PCB die ze standaardiseren en waar 1 GPU op steekt met eventueel extra RAM (op dezelfde, kleine, PCB). Aangezien de "northbridge" geen memory controller meer bevat, kan het goed zijn dat ze een hele kleine die kunnen bouwen voor de northbridge waarin ook de GPU steekt. Dat geheel zouden ze op 1 PCB kunnen steken en in verschillende vormen uitbrengen (bv. 1 met SDR, 1 met DDR SC, 1 met DDR DC en 1 zonder RAM).

[Verwijderd]

als ik hem maar in me huidige mobo kan prikken haal ik hem misschien ook wel ze zullen wel nooit zo duur worden als pentiums

[apa]

als ik hem maar in me huidige mobo kan prikken haal ik hem misschien ook wel ze zullen wel nooit zo duur worden als pentiums

De Hammer? In je huidige mobo? Da's zowieso onmogelijk. Geen enkele bestaande CPU gebruikt op dit moment HyperTransport als link met de rest van je systeem. De Hammer-reeks doet dat wel. Praktisch gezien zal het ook niet mogelijk zijn omdat ze nieuwe socket-formaten gebruiken. De ClawHammer (die zal wellicht zoiets als Athlon64 heten) zal meer dan 700 pinnen tellen (ik dacht 752) en de SledgeHammer (die Opteron zal heten) zal meer dan 900 pinnen tellen (954?). De SocketA beschikt over 462 pinnen.

Zodus: je zal zeker een nieuw bord moeten kopen. Goed nieuws is echter dat de borden wellicht goedkoper kunnen geproduceerd worden dan de huidige K7-borden. De reden is dat de chipsets wellicht wat goedkoper kunnen worden omdat ze geen memory-controller meer bevatten. Langs de andere kant zal de CPU ook wel duurder zijn dan de huidige K7's: Dat komt doordat ze nu ook een memory-controller geïntegreerd hebben. In totaal is het wel mogelijk dat een K8-platform goedkoper wordt dan een K7-platform: ze kunnen de vaste kosten van de memory-controller immers verdelen over veel meer eenheden (over alle verkochte systemen daar waar ze die vroeger enkel konnen verdelen over de verkochte moederborden met eenzelfde chipset).

[Brent]

Verwijderd schreef op 18 augustus 2002 @ 18:04:
als ik hem maar in me huidige mobo kan prikken

100% uitgesloten. athlon = 462 pins, clawhammer = 754 pins, opteron = 940 pins

apa schreef op 18 augustus 2002 @ 17:54:
Ze kunnen misschien dezelfde weg opgaan als met hun mobiele GPU's. Daar hebben ze 1 PCB die ze standaardiseren en waar 1 GPU op steekt met eventueel extra RAM (op dezelfde, kleine, PCB). Aangezien de "northbridge" geen memory controller meer bevat, kan het goed zijn dat ze een hele kleine die kunnen bouwen voor de northbridge waarin ook de GPU steekt. Dat geheel zouden ze op 1 PCB kunnen steken en in verschillende vormen uitbrengen (bv. 1 met SDR, 1 met DDR SC, 1 met DDR DC en 1 zonder RAM).

en waar heb jij het nou weer over? de hammer is een cpu, geen gpu.

[ Voor 0% gewijzigd door Brent op 18-08-2002 19:48 . Reden: effe de pinnetjes goed :) ]

[SG]

CHam zou 754 pins worden
SHam zou 940 pins worden.

tov 462 van Socket A

[XWB]

Welke southbridge heeft de crush K8 chipset?

[BalusC]

De Crush K8 is zowat de southbridge

Omdat de geheugencontroller in de Hammers is geïntegreerd, scheelt dat ruimte in de Northbridge. Hierdoor zien fabrikanten kans om de rest van de Northbridge met de Southbridge te combinieren.. Lees eens dit hele draadje door, dan weet je veel meer

[XWB]

BalusC schreef op 16 augustus 2002 @ 09:29:
Even voor de overzicht nog alle (aangekondigde) Hammer chipsets met alle belangrijkste features:

naam	link	RAM	PCI	ATA
AMD8000 Lokar (8111 + 8151)	HT (800MB/s)	DDR PC2700	2.2 33MHz (8 slots)	ATA7 (133MB/s)
AMD8000 Golem (8111 + 8131 + 8151)	HT (800MB/s)	DDR PC2700	2.2 33MHz (8 slots) én PCI-X 133MHz (5 slots)	ATA7 (133MB/s)
VIA K8HTA	V-link (533MB/s?)	DDR PC3200?	2.2 33MHz (? slots) én PCI-64 66MHz (? slots)	ATA7 én SATA1 (150MB/s)
VIA K8M333 met Zoetrope AGP	V-link (533MB/s?)	DDR PC3200?	2.2 33MHz (? slots) én PCI-64 66MHz (? slots)	ATA7 én SATA1 (150MB/s)
SiS 755 (755 + 963)	MuTIOL (1066MB/s)	DDR PC3200?	2.2 33MHz (6 slots)	ATA7 (133MB/s)
SiS 760 met AGP (760 + 963)	MuTIOL (1066MB/s)	DDR PC3200?	2.2 33MHz (6 slots)	ATA7 (133MB/s)
nVidia Crush K8	HT (800MB/s)	DC DDR PC2700	2.2 33MHz (6 slots)	ATA7 én SATA1 (150MB/s) SW RAID?
nVidia Crush K8G met GF4MX	HT (800MB/s)	DC DDR PC2700	2.2 33MHz (6 slots)	ATA7 én SATA1 (150MB/s) SW RAID?
ALi M1687	HT (800MB/s)	DDR PC2700	2.2 33MHz (? slots)	ATA7 én SATA1 (150MB/s)
ALi M1688 met Trident XP4	HT (800MB/s)	DDR PC2700	2.2 33MHz (? slots)	ATA7 én SATA1 (150MB/s)

Ze hebben allemaal AGP 8x ondersteuning en zes USB 2.0 poorten.

Tot zover ziet de nVidia Crush K8(G) IMHO het lekkerst uit: DC DDR en Serial ATA

En de VIA K8UMA ?

edit
De K8HTA, K8HTB en K8UMA chipsets worden omgetoverd in respectievelijk K8T400, K8T400M en K8M400.
nieuws: VIA en SiS presenteren strategie voor Hammer chipsets

Nogal verwarend, welke chipsets komen er nu juist?

[BalusC]

Ik heb wat research gedaan:
http://news.zdnet.co.uk/story/0,,t269-s2110585,00.html
http://www.theinquirer.net/?article=3603

K8HTA = K8T400 = desktop chipset zonder integrated Zoetrope AGP
K8HTB = K8T400M = mobile chipset zonder(?) integrated Zoetrope AGP
K8UMA = K8M400 = desktop chipset mét integrated Zoetrope AGP

Verder is het kennelijk een feit dat ze allemaal PC3200 DDR ondersteunen, ik heb de vraagtekentjes daarbij maar weggehaald (tabel hier ergens boven is dus ge-update )

[XWB]

Ondersteuning voor PC3200? Wat voor zin heeft dat?
De on-die memory controller van de Hammer ondersteunt max PC2700, en het is toch enkel deze die gebruikt wordt?

[BalusC]

Dat heb ik eigenlijk opgemaakt uit de typeaanduidingen: K8T400, wat dus op 200MHz DDR slaat, mits VIA dezelfde naamgevingen hanteert als met haar huidige chipsets. Misschien is dit gewoon de "maximale" bussnelheid voor deze chipsets en draait het boeltje gewoon op FSB@166MHz. Of is de geheugenbus van de Hammers misschien toch wel overklokbaar tot FSB@200MHz? Of loopt de snelheid van de geheugenbus van de Hammer asynchroon met de interne klok van de Hammer?

[XWB]

Maximale bussnelheid? Hammer heeft geen FSB en de verbindingen zijn met hypertransport.

[Brent]

Hacku schreef op 19 augustus 2002 @ 17:59:
Maximale bussnelheid? Hammer heeft geen FSB en de verbindingen zijn met hypertransport.

als er iemand dat weet, is BalusC het. je moet beter lezen want hij heeft het over GEHEUGENBUS!!!

Hacku schreef op 19 augustus 2002 @ 17:11:
Ondersteuning voor PC3200? Wat voor zin heeft dat?
De on-die memory controller van de Hammer ondersteunt max PC2700

O? Hij ondersteund gewoon DDR geheugen en het lijkt me dat je in die bios (of via jumpers) je snelheid vaststelt (PC2100/PC2700/PC3200).

[XWB]

Nou snap ik er niks meer van ...

[BalusC]

Hacku, de verbinding tussen de Hammer en de chipset is 166MHz (FSB) en het protocol die daarop loopt is dus de 800MB/s 6,4GB/s snelle Hypertransport

[XWB]

Aha, das duidelijker.
En de memory controller? Die gaat direct naar het geheugen, dat is dan ook met hypertransport?

[BalusC]

Die memory controller van de Hammers gaat idd direct naar het geheugen, zoals je zegt. Maar dat is niet met HT, het is gewoon een 64bits DDR lijntje op 166MHz

64bit (8B(yte)) * 166MHz (166²/₃ miljoen x per seconde) * 2 (DDR) = 2700MB/s

[ Voor 0% gewijzigd door BalusC op 19-08-2002 20:19 . Reden: berekening wat duidelijker gemaakt ]

[XWB]

Ik dacht dat ie naar het geheugen ging met hypertransport. (800MB/s)
Niet dus.

Na het bekijken van deze screens wordt hypertransport me duidelijk.

In dual systemen (of zwaarder) staan de cpu's in verbinding met elkaar via hypertransport met snelheden van 800 MB/s (dual) tot 6.4 GB/s (8-way).

Hypertransport wordt ook gebruikt als verbinding tussen de chipsets (bv verbinding tussen de 8111 en 8151 chipset) en om de cpu met de chipset te verbinden.

Van cpu naar memory gaat dus aan 166 mhz.

Klopt dit? Of ben ik fout?

[SG]

BalusC schreef op 19 augustus 2002 @ 19:40:
Hacku, de verbinding tussen de Hammer en de chipset is 166MHz (FSB) en het protocol die daarop loopt is dus de 800MB/s snelle Hypertransport

Nogaltegen strijdig 166Mhz of 800Mhz kan niet beide zijn?

Nou dat lijkt mij Fanta of kom op met links aangezien hier zogenaamd BAlusC weet hoe de link tussen OnDie-Memcontroler of Ondie HTbus logic en Core logic in mekaar zit. Naar mijn weten is hier nog niks door AMD public over gemaakt.

Dan de HTBus controler naar de Core ,d'r is nog niks bekend hoe AMD dit opgelost heeft en en 'n Bidirectionele HTBus op 800Mhz die in elke richting 3,2Gb/s kan genereren verbinden met de core met 'n 166?266 == 2,7GB/s hoe wil dat bidirectioneel 2*3,2 GB/s aankunnen ???
Dat is creupele HTBus naar core toe op de chip dus ondie.

En het zijn er ook nog es 2 HTBusen en Sledge 3 van die bussen.

Dit is dus fout of kom met officiele berichten.

Het oude systeem CPU naar Northbridge bus, dat is de FSBus hier wordt door de Northbridge de CPU('s) met de rest verbonden.

Hammer heeft HTBus(sen) naar chipset(North & south) en Membus naar Memory.
Het is dus FSB vs HTB & MEMbus

Hoe dat on Die met de core logic verbonden is kan met hele snelle bussen hier zal men geen bottleneck creeren, ook is er nu mogelijk dat dit meer op de Core clock loopt

Core mem controler & HTB logic on die kan verbonden zijn met Core speed. dus lage latency's.en hoge bandbreedte

Het zijn geen chips(CPU chip naar NorthBridge CHIP via Mobo traces gelinkt moet worden dus Mhz beperking.), die verbonden moeten worden.
Maar logic ciruits die onderdeel van 'n chip zijn dit gaat dus meer volgens het L2 syteem misschien wat minder krachtig maar kan makkelijk met zeer hoge bandbreedte verbonden worden bijvoorbeeld met een vergelijkbare L3 ondie logic connectie voor memcontroler en HTBussenLogic.

Denoods met 'n clockdivider maar dan nog zal het veel sneller zijn dan elke externe FSB.

FrontSide Bus slaat op de Clasieke externe éne bus van de CPU de GTL+ of EV6 bus Shared of point to point ig van Dual CPU.

Hammer heeft als meerdere externe bussen de MemBus naar de dimms.
en meerdere HyperTranport bussen.
In dit opzicht is de FSB iig gesplits
Bij GTL(+) & EV6 is de Northbridge het centralepunt voor CPU/Memory/AGP/Southbridge
Bij HtB en K8 architektuur heeft de CPU 'n meer Centrale punt taak gekregen.

Waar is die FSB bij de Hammer nou? In dit opzicht nogal heel anders dat de defenitie van FSB heel belangrijk wordt iig is die opgesplits en worden er de onderdelen totaal anders gelinkt. dus spreken over FSB lijkt mij hier erg verwarrend aangezien deze gesplits en andere komponenten linkt maar ook de component routing is anders UMA vs NUMA en AGPMEmory verbinding is anders.

Dus ik wacht maar liever op officele technische specifikaties van al die ondie verbindingen dan hier met verkeerde kreten zoals FSB de boel te verwarren.

Dan zul je eerst de Term FSB moeten definieren en dan zoeken waar die in het hammer platform zit.

* SG vind de FSB op de hammer nogal verminkt en radical verandert in mijn ogen is FSB verledentijd en gebruik liever Membus en HTBussen in de plaats ervan.

* SG is benieuwd hoe AMD dat FSBbeestje gaat noemen!

[SG]

Hacku schreef op 19 augustus 2002 @ 20:28:
Ik dacht dat ie naar het geheugen ging met hypertransport. (800MB/s)
Niet dus.

Nee tuurlijk niet dat is een exclusieve verbinding
Maar aGP gaat via tunnelchip of Northbridge via
HTbus naar CPU en dan via membus naar memory.

Na het bekijken van deze screens wordt hypertransport me duidelijk.

In dual systemen (of zwaarder) staan de cpu's in verbinding met elkaar via hypertransport met snelheden van 800 MB/s (dual) tot 6.4 GB/s (8-way).

HTBussen zijn er met verschillende bit breedtes dus meerdere gebundelde lijnen en met de hammer platform wordt op die manier alles verbonden behalve geheugen die zit direct op de CPU.

Hypertransport wordt ook gebruikt als verbinding tussen de chipsets (bv verbinding tussen de 8111 en 8151 chipset) en om de cpu met de chipset te verbinden.

Van cpu naar memory gaat dus aan 166 mhz.

Klopt dit? Of ben ik fout?

Klopt 166DDR(266) voor PC2700
De Membus dus, tussen CPU(ondieMemControler) naar de memory(Dimms)

Niks te FSB dus

[BalusC]

Ja, die 800MB/s HT is de link tussen de NB en de SB van de AMD chipset. VIA gebruikt hier de V-Link (533MB/s?), terwijl SiS hier een 1066MB/s snelle MuTIOL voor gebruikt. De verbinding tussen de Northbridge en de processor is dus een veel bredere 6,4GB/s HT bus. De bus van de "Northbridge" (AGP tunnel), de Hammer en het geheugen loopt op 166MHz. Ik weet niet precies op welke snelheid de bus tussen AGP tunnel en I/O hub loopt..

^{hmm.. moet mijn eerdere post maar eens herzien: chipset <-> CPU = 6,4GB/s ipv 800MB/s}

Hmm².. 6,4GB/s en 166MHz DDR? .. 6,4GB/s / 16bit / 8-way = 200MHz DDR

* BalusC raakt ook confused

Of is dat nou gewoon de theoretische Maximumsnelheid

[SG]

Zal ik je dan verder confusen.

Waar zal de Hammers Multyplier op gebasseerd zijn?
Memory kan niet of wel want dan zou ie unlocked moeten zijn. aangezien ie 100Mhz en 133Mhz en 166Mhz MEm Clock ondersteund.

Aangezien het vroeger op de FSB ruste komt de HTBus Clock hier in aanmerking voor of een grond clock hiervan. Die Clock is konstant 800Mhz onafhankelijk van de rest. De bandbreedte wordt bepaald of dit een 1/2/4/8/16/32bits HTBus is.
Aangezien AMD Mp met stappen van 0,5 gebruikt.

is de 3400+ 2Ghz= 2,5MP*800Mhz of gebasseerd op een grondfrequntie van 100/200/400Mhz * 20/10/5MP
dus de volgende is dan 3*800= 2,4Mhz 3,5*800= 2,8Ghz
Hier is helaas ook nog niks officieels bekend over en aangezien OCén wel volgens AMD mogelijk is?

Zijn er ook andere mogelijkheden.
Op Membus

2Ghz is dus mogelijk is dit senario maar de 1,5Ghz van de opteron niet, krijg je een rare MP of het moet 'n lagere grond frequntie zijn want mij lijkt die 800Mhz alleen puur voor transport doel einden dus van HTzender naar HTOntvanger denk eerder een lagere grondfrequentie die van het mobo wordt afgegeven 100Mhz ofzo waar HTClock op gebasseerd is.

Wat ook wel interresant lijkt is de CPU Clock onafhankelijk van de Membus. Dus hoe zijn die verschillende clocken met elkaar gelinkt ?

[Verwijderd]

BalusC schreef op 19 augustus 2002 @ 21:05:
Ja, die 800MB/s HT is de link tussen de NB en de SB van de AMD chipset. VIA gebruikt hier de V-Link (533MB/s?), terwijl SiS hier een 1066MB/s snelle MuTIOL voor gebruikt. De verbinding tussen de Northbridge en de processor is dus een veel bredere 6,4GB/s HT bus. De bus van de "Northbridge" (AGP tunnel), de Hammer en het geheugen loopt op 166MHz. Ik weet niet precies op welke snelheid de bus tussen AGP tunnel en I/O hub loopt..

^{hmm.. moet mijn eerdere post maar eens herzien: chipset <-> CPU = 6,4GB/s ipv 800MB/s}

Hmm².. 6,4GB/s en 166MHz DDR? .. 6,4GB/s / 16bit / 8-way = 200MHz DDR

* BalusC raakt ook confused

Of is dat nou gewoon de theoretische Maximumsnelheid

Waar heb jij leren rekenen ?

800Mhz DDR per richting op een 16bit bus => 3.2GB/sec in iedere richting ofte 6.4GB/sec totaal.

En wat doet die 8-way tussen je berekeningen ?? Fat slaagt toch helemaal op niks meer ? Wil je misschien een 8-processor SledgeHammersysteem bedoelen ? Heeft 'in se' niks te maken met de bandbreedte van een HT-link.


En Clawhammer ondersteunt op lancering enkel tot PC2700 (DDR333 ofte 166Mhz double pumped). VIA mag zijn chipsets dan wel K8T400 en dergelijke noemen, tenzij ze belachelijk gaan wezen en de on-die controller van Clawhammer gaan uitschakelen en hun eigen controller gaan gebruiken (wat uit de lay-out van referentie-borden duidelijk niet het geval is) blijft dus de maximum geheugen-bandbreedte nog steeds 2.7GB/sec.

Ik denk dat ik alles heb gezegd wat ik wilde zeggen at thes time

[BalusC]

OK, GiCNiC & SuperG, thanx voor de verheldering!

Het lijkt erop dat ik me in dit topic voorlopig maar in de achtergrond moet houden..

[XWB]

Nu nog een vraagje over de AMD 8000 chipset.
Bestaat deze nu uit 3 delen? Waar is dat goed voor?

http://www.amd.com/us-en/...,30_118_4699_4741,00.html

[Femme]

De PCI-X tunnel zul je waarschijnlijk alleen tegenkomen op dual en quad Opteron moederborden. Met alleen de AGP tunnel en I/O hub kom je op een chipset van twee componenten.

[XWB]

En de Crush van nvidia bestaat uit 1 deel.
Via en Sis 2 delen (N & S).
Juist?

[Brent]

Hacku schreef op 20 augustus 2002 @ 12:52:
En de Crush van nvidia bestaat uit 1 deel.
Via en Sis 2 delen (N & S).
Juist?

AFAIK ja. ik weet trouens niet of de crush met geintegreerde video ook 1 chip is, die zou weleens 2 chippig kunnen zijn.

[Verwijderd]

ik heb net het hele topic zitten doorlezen (alle 14 pagina's, was wel leuk dat stukje over multiply'ers met 4,77 Mhz, thanks), en ik vraag me nog steeds 1 ding af:

De hammer kan intern werken met 32 bits & 64 bits instructie. In 1 klokslag van de CPU kan deze proc dus 32 bits of 64 bits aan gegevens verwerken door zijn extra pipelines aan het eind van de oude, op de K7 gebaseerde pipelines (zo heet dat toch, laatst gelezen in een linkje van FP, waar ik btw. ook een fijn linkje naar de werking van DDR, RD & DDR-II heb gevonden, aan te raden voor sommige tweakers hier ) .

Nu vraag ik me af: Als je een programma nu 'slim' port van 32 bits instructies naar 64 bits instructies. zal het programma dan ook een factor (max 2x) sneller kunnen lopen, of moet ik dat '32/64 bits verhaal' in een geheel andere context zien?
Zo ja, heeft iemand een duidelijk linkje (ik heb wel gezocht, maar kom alleen op wel HEEL vergevorderde pdf'jes etc.).

Als dit allemaal opgaat voorzie ik een probleempje met:
Intel: 32 bits, Ghz race
Clawhammer: quantispeed, 32 bits prog of 64 bits prog, en dat baseren op de TB dat geen 64 bits proc is, waarbij de snelheid van de Clawhammer ook nog van het prog afhangt (64 of 32 b)?

weet iemand hier iets meer van?

[Verwijderd]

Je interpreteerd het 32/64 bit inderdaad verkeerd .

Die nummers slagen in hoofdzaak op adresruimte, 32bits kan 4GB adresseren, 64bits kan ettelijke terrabytes aan. Daarbij komt nog dat registers en gelijken langer kunnen zijn, wat houd dat in ? Nummers waarmee gewerkt kunnen worden kunnen nu veel groter zijn, maar dat is vooral van nut in wetenschappelijke software, explosiesimulaties en dergelijke.

Een nadeel van die 64bit's, is dat code groter wordt (dubbbel zo lange nummers in theorie), maar daar heeft AMD aan gedacht. Aangezien weinig mense echt 64bits-data nodig hebben (64bits adressering is voor meer mansen handig) is de standaard data-size in 64bits mode nog steeds 32bit, maar, die kan worden uitgebreidt met een prefix tot 64bit per instructie, naargelang nodig. Op deze manier wordt bandbreedte efficienter gebruikt en blijft de code-density hoger.

Je kan enkel 2 keer een 32bits waarde uitvoeren in 1 64bits blok als je met SSE/2 of 3DNow! en aanverwante werkt, iedere SIMD-instructie-set eigelijk, op voorwaarde dat je dezelfde operatie op die 2 delen gaat uitvoeren. (vandaar SIMD, Single Instruction Multiple Data).

[Verwijderd]

SuperG schreef op 19 augustus 2002 @ 21:33:
Zal ik je dan verder confusen.

Waar zal de Hammers Multyplier op gebasseerd zijn?
Memory kan niet of wel want dan zou ie unlocked moeten zijn. aangezien ie 100Mhz en 133Mhz en 166Mhz MEm Clock ondersteund.

Aangezien het vroeger op de FSB ruste komt de HTBus Clock hier in aanmerking voor of een grond clock hiervan. Die Clock is konstant 800Mhz onafhankelijk van de rest. De bandbreedte wordt bepaald of dit een 1/2/4/8/16/32bits HTBus is.
Aangezien AMD Mp met stappen van 0,5 gebruikt.

is de 3400+ 2Ghz= 2,5MP*800Mhz of gebasseerd op een grondfrequntie van 100/200/400Mhz * 20/10/5MP
dus de volgende is dan 3*800= 2,4Mhz 3,5*800= 2,8Ghz
Hier is helaas ook nog niks officieels bekend over en aangezien OCén wel volgens AMD mogelijk is?

Zijn er ook andere mogelijkheden.
Op Membus

2Ghz is dus mogelijk is dit senario maar de 1,5Ghz van de opteron niet, krijg je een rare MP of het moet 'n lagere grond frequntie zijn want mij lijkt die 800Mhz alleen puur voor transport doel einden dus van HTzender naar HTOntvanger denk eerder een lagere grondfrequentie die van het mobo wordt afgegeven 100Mhz ofzo waar HTClock op gebasseerd is.

Wat ook wel interresant lijkt is de CPU Clock onafhankelijk van de Membus. Dus hoe zijn die verschillende clocken met elkaar gelinkt ?

Je ziet een kleinigheidje over het hoofd .

de HT-bus is inderdaad het waarschijnlijkste als basisfrequentie, omdat die constant is (in tegenstelling tot inderdaad de memory-bus), maar 800Mhz is wat hoog om degelijk mee te multiplien als je enkel halfjes gaat gebruiken.

Ziehier het concept "Divider" . Het is vrij vermoedelijk dat de 800Mhz basisklok eerst door een divider tot 200Mhz of maybe 100Mhz wordt gereduceerd, en pas daarna wordt multiplied tot de gewenste clocksnelheid, kwestie dat jet wat meer speed-grades kan aanbieden.

Opteron 1.5Ghz is dus zeer mogelijk met eerst een divider 8, en dan een multiplier 15 (of /4 en *7.5). Ten tijde van de Cyrixjes op 225Mhz enzow werden er ook mulitpliers met 1/4 spacing gebruikt, dus alles kan hier .

[Rannasha]

Verwijderd schreef op 20 augustus 2002 @ 14:16:
ik heb net het hele topic zitten doorlezen (alle 14 pagina's, was wel leuk dat stukje over multiply'ers met 4,77 Mhz, thanks), en ik vraag me nog steeds 1 ding af:

De hammer kan intern werken met 32 bits & 64 bits instructie. In 1 klokslag van de CPU kan deze proc dus 32 bits of 64 bits aan gegevens verwerken door zijn extra pipelines aan het eind van de oude, op de K7 gebaseerde pipelines (zo heet dat toch, laatst gelezen in een linkje van FP, waar ik btw. ook een fijn linkje naar de werking van DDR, RD & DDR-II heb gevonden, aan te raden voor sommige tweakers hier ) .

Nu vraag ik me af: Als je een programma nu 'slim' port van 32 bits instructies naar 64 bits instructies. zal het programma dan ook een factor (max 2x) sneller kunnen lopen, of moet ik dat '32/64 bits verhaal' in een geheel andere context zien?
Zo ja, heeft iemand een duidelijk linkje (ik heb wel gezocht, maar kom alleen op wel HEEL vergevorderde pdf'jes etc.).

Als dit allemaal opgaat voorzie ik een probleempje met:
Intel: 32 bits, Ghz race
Clawhammer: quantispeed, 32 bits prog of 64 bits prog, en dat baseren op de TB dat geen 64 bits proc is, waarbij de snelheid van de Clawhammer ook nog van het prog afhangt (64 of 32 b)?

weet iemand hier iets meer van?

64 bits betekent niet 2x zo snel, het betekent dat er meer geheugen geadresseerd kan worden (wat nu nog niet interessant is) en daarnaast heeft de Hammer ook nog enkele 64 bits registers, die de boel wel versnellen bij geoptimaliseerde progsels.

Verder heeft Intel ook wel 64 bits technologie, alleen die is niet backwards compatible op de manier dat de Hammer is, de overgang wordt dan veel heftiger, en daardoor dus moeilijker.

[Verwijderd]

Hacku schreef op 20 augustus 2002 @ 12:35:
Nu nog een vraagje over de AMD 8000 chipset.
Bestaat deze nu uit 3 delen? Waar is dat goed voor?

http://www.amd.com/us-en/...,30_118_4699_4741,00.html

Het is een modulaire chipset (voordeel van HyperTransport)

je kan onderdelen gebruiken zoveel en welke dat je (als moederbord maker toch ) kiest.

Een desktop-bord zal meestal een AMD-8151 AGP bridge en een AMD-8111 IO bridge bevatten, waar een serverbord eerder voor de combinatie AMD-8131 PCI-X bridge met AMD-8111 gaat. Een super-end workstation kan bijvoorbeeld alle 3 de onderdelen gaan gebruiken. Een ander type server kan bijvoorbeeld meerdere AMD-8131's gaan gebruiken, of bijvoorbeeld enkel een AMD-8111 voor IO.

Alles naar wens met Hypertransport .

[Verwijderd]

ken je er ook goed mee gamen?

[XWB]

Verwijderd schreef op 05 maart 2002 @ 22:24:
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

Om op de transistors terug te komen : Clawhammer krijgt er "maar" 63 miljoen, Sledgehammer 100 miljoen.

[Verwijderd]

bedankt GiGNiC & species5618,

ik denk dat ik het nu snap. Maar is die x86-64 instructieset dan niet een beetje toekomstpraat voor de desktopmarkt, aangezien velen nog niet aan 4 GB geheugen beginnen, en die ellenlange registers ook nog niet nodig zijn? Ik bedoel, voor servers & serieuze workstations (sledgehammer & clawhammer DP)leuk en zo, maar de clawhammer SP is/wordt toch vooral een desktop cpu?

offtopic:
ik weet ondanks dit wel wat mijn nieuwe cpu wordt begin volgend jaar... Intel had mijn inziens zijn P3 verder moeten ontwikkelen...

[styno]

Verwijderd schreef op 20 augustus 2002 @ 18:19:
Maar is die x86-64 instructieset dan niet een beetje toekomstpraat voor de desktopmarkt, aangezien velen nog niet aan 4 GB geheugen beginnen, en die ellenlange registers ook nog niet nodig zijn? Ik bedoel, voor servers & serieuze workstations (sledgehammer & clawhammer DP)leuk en zo, maar de clawhammer SP is/wordt toch vooral een desktop cpu?

Een tijdje terug (+/- 15 jaar) dacht men dat 640 kB RAM en een 8 bits adres bus meer dan genoeg was "voor elke applicatie dan ook". Daarom is het een goed idee om ruimschoots op tijd dit soort dingen in te voeren, vooral als je toch met een 'nieuwe' processor architectuur begint.

Bovendien, door het NUMA concept van de Hammer, is het wel degelijk mogelijk om binnen 1 systeem (met bijv. 8 procs) meer dan 4GB aan RAM te hebben. Wanneer alle 8 proc's de beschikking hebben over 2GB lokaal RAM, dan beschikt elke processor uiteindelijk over 16GB RAM.

[SG]

Verwijderd schreef op 20 augustus 2002 @ 14:41:
[...]


Je ziet een kleinigheidje over het hoofd .

Ik denk dat jij mijn hersenspinsel niet grondig gelezen hebt.

de HT-bus is inderdaad het waarschijnlijkste als basisfrequentie, omdat die constant is (in tegenstelling tot inderdaad de memory-bus), maar 800Mhz is wat hoog om degelijk mee te multiplien als je enkel halfjes gaat gebruiken.

zie mijn text":

is de 3400+ 2Ghz= 2,5MP*800Mhz of gebasseerd op een grondfrequntie van 100/200/400Mhz * 20/10/5 MP
dus de volgende is dan 3*800= 2,4Mhz 3,5*800= 2,8Ghz

Ziehier het concept "Divider" . Het is vrij vermoedelijk dat de 800Mhz basisklok eerst door een divider tot 200Mhz of maybe 100Mhz wordt gereduceerd, en pas daarna wordt multiplied tot de gewenste clocksnelheid, kwestie dat jet wat meer speed-grades kan aanbieden.

Ik noem dat grond frequentie.
Dividing of Multiplying is een detail net als bij d e486DX100 (3X33Mhz)
Maar die gedachte heb ik ook al aangekaart maar niet met voorbeelden toegepast.

Opteron 1.5Ghz is dus zeer mogelijk met eerst een divider 8, en dan een multiplier 15 (of /4 en *7.5). Ten tijde van de Cyrixjes op 225Mhz enzow werden er ook mulitpliers met 1/4 spacing gebruikt, dus alles kan hier .

DAt zij ik al in die orginele reply van mezelf.

[XWB]

Breepee schreef op 20 augustus 2002 @ 13:17:
[...]

AFAIK ja. ik weet trouens niet of de crush met geintegreerde video ook 1 chip is, die zou weleens 2 chippig kunnen zijn.

Hier zie je er 2 :

[SG]

Verwijderd schreef op 20 augustus 2002 @ 14:16:
ik heb net het hele topic zitten doorlezen (alle 14 pagina's, was wel leuk dat stukje over multiply'ers met 4,77 Mhz, thanks), en ik vraag me nog steeds 1 ding af:

De hammer kan intern werken met 32 bits & 64 bits instructie. In 1 klokslag van de CPU kan deze proc dus 32 bits of 64 bits aan gegevens verwerken door zijn extra pipelines aan het eind van de oude, op de K7 gebaseerde pipelines (zo heet dat toch, laatst gelezen in een linkje van FP, waar ik btw. ook een fijn linkje naar de werking van DDR, RD & DDR-II heb gevonden, aan te raden voor sommige tweakers hier ) .

? pipelines? hij heeft er 3 net als de K7 maar en zijn 2 stages toegevoegd en de drie pipes zijn 64bits breed gemaakt
Die 2 stages hebben niet veel met 32 naar 64bit te maken maar bied een andere feature van pipe switchen zodat de pipes efficienter gebruikt worden en er dus geen pipe onnodig idle is dus effectiever paralelisme.

Nu vraag ik me af: Als je een programma nu 'slim' port van 32 bits instructies naar 64 bits instructies. zal het programma dan ook een factor (max 2x) sneller kunnen lopen, of moet ik dat '32/64 bits verhaal' in een geheel andere context zien?
Zo ja, heeft iemand een duidelijk linkje (ik heb wel gezocht, maar kom alleen op wel HEEL vergevorderde pdf'jes etc.).

Dit is puur code afhankelijk en aangezien de totale code van een app nogal een grote mix is ook van taken die totaal geen 64 bit nodig hebben zal het nooit of nauwelijks 200% sneller lopen.

Wel kunnen sommige routines die nu per 64 ipv per 32bit data verwerken tegen de 200% winst halen de winst is groot als die routines heel intensief gebruikt worden.

Bijvoorbeeld 'n Assembly bitblit van een 16Bit surface. Ipv per 32bits dus per 2 pixel, nu per 4*16bit ophalen en wegschrijven naar de destination surface. Hier haal je redelijk bijna de 200 % minus wat assembly routine overhead.

Je krijgt nu ook 64bit alignment ipv 32bit dus structuren worden dan voor efficientie passend in een veelvoud van 64bit gebruikt dus een 48 bit data structuur wordt voor alignement tot 64bit gemaakt 'n 96bit wordt 128(2*64 )
voor een efficentere snellere adressering daarom waren de 24bit kleur diepe op sommige gewoon 32bit dus 24Color met 8bits dontcare dus puur voor alignment later is dat gebruikt voor alfa info

En nu gaat dat truckje per 64bit voor Syteem meory data structuren en variablen

Als je 20% winst hebt is dat mooi megenomen de ene sooftware kan er meer voor geoptimaliseerd worden dan andere dus verwacht geen wonderen en hier over heeft AMD al bericht gemaakt weer enkel % winst maar bij lange na geen 2 x.

Als dit allemaal opgaat voorzie ik een probleempje met:
Intel: 32 bits, Ghz race
Clawhammer: quantispeed, 32 bits prog of 64 bits prog, en dat baseren op de TB dat geen 64 bits proc is, waarbij de snelheid van de Clawhammer ook nog van het prog afhangt (64 of 32 b)?

weet iemand hier iets meer van?

Het nadeel van 64 bit is dat het tijd kost net zoals SSE2 HTT PNI het kost tijd eer er de applicaties versies voor beschikbaar zijn dus fixeer maar is op de hammer IA32 performance aangezien je dat eerst gaat gebruiken.

Verwijderd schreef op 20 augustus 2002 @ 14:36:
Je interpreteerd het 32/64 bit inderdaad verkeerd .

IIg de core architektuur. Pipis en stages zijn niet hetzelfde

Die nummers slagen in hoofdzaak op adresruimte, 32bits kan 4GB adresseren, 64bits kan ettelijke terrabytes aan.

Dit is de Server en heavy Workstatien markt daar speeld dit een rol in de desktop markt nog enkele jaren niet daar gaat het on de 64bit ALU en FPU kracht met SSE2

Daarbij komt nog dat registers en gelijken langer kunnen zijn, wat houd dat in ? Nummers waarmee gewerkt kunnen worden kunnen nu veel groter zijn, maar dat is vooral van nut in wetenschappelijke software, explosiesimulaties en dergelijke.

Denk aan data bewerking bijvoorbeeld grafische data bv.jpegs BMP Dibs op poetsen dat gaat nu dus per 64bit ipv 32bit.
Sommige Routines kunnen nu per slag 64bit verwerken dus op sommige plaatsen in de code is er winst te behalen net zoals we toen van 286 naar 386 gingen van 16bit naar 32bit het was eerst ook wachten op software

Een nadeel van die 64bit's, is dat code groter wordt (dubbbel zo lange nummers in theorie), maar daar heeft AMD aan gedacht. Aangezien weinig mense echt 64bits-data nodig hebben (64bits adressering is voor meer mansen handig) is de standaard data-size in 64bits mode nog steeds 32bit, maar, die kan worden uitgebreidt met een prefix tot 64bit per instructie, naargelang nodig. Op deze manier wordt bandbreedte efficienter gebruikt en blijft de code-density hoger.

Dat heb ik ook gelezen de 64bit modus standaart integer is gewoon 32bit
Aangezien int's vaak als teller gebruikt worden is tellen tot 10 maar 4bits van toepassing dus tot 1000 wat meer tot 10000 ook hier is 32bit voldoende en dan zijn die extra 32bits belasten voor de memory footprint.

Maar voor speed wordt soms wel ruimte opgeoffert is een soort treade off Alignment of space. afhankelijk van de eisen en limieten
Het geheugen limiet probleem is tegenwoordig niet een groot probleem dat was vroeger anders met die 640KB

Je kan enkel 2 keer een 32bits waarde uitvoeren in 1 64bits blok als je met SSE/2 of 3DNow! en aanverwante werkt, iedere SIMD-instructie-set eigelijk, op voorwaarde dat je dezelfde operatie op die 2 delen gaat uitvoeren. (vandaar SIMD, Single Instruction Multiple Data).

in integer en FP proscessing wel ja maar data rondpompen niet je kan nu 8*bytes tegelijk rond pompen.

Klopt maar zie het zo in IA32 worden ook 64bit variablen gebruikt en die werden tot nu toe is 2 stappen gedaan en kunnen met 64bit X86-64 dus een een keer

Ook worden in gevallen van grote waarden 64bit int gebruikt nou daar werden vaak truckjes voor gebruikt is met 64bit niet nodig.
Maar dit is dus gewoon code eisen afhankelijk.

De ene app heeft totaal niks aan 64bit de andere weer wel.

Zijn er hier codekloppers of assembler programeurs.
mijn ASM ervaring zijn zo uit een ver verleden(6800X).

[SG]

Hacku schreef op 20 augustus 2002 @ 19:02:
[...]


Hier zie je er 2 :

[afbeelding]

Uit eerdere pics was goed te zien dat bij de Crush memory aan de CPU hangt dus ondie memcontroler dus de GPU in de Northbridge benaderd het geheugen via de HTbus dan via de membus

Als nVidia daarvoor kies zal de trade off redelijk mee vallen.

Ik verwacht wel dat het niet zo'n geweldige high reso performance kan geven maar ja als je onboard GPU wil gebruiken om het budged lekker er ver naar beneden te druken dan krijg je er vanzelf natuurlijk consesies bij.

[Verwijderd]

Verwijderd schreef op 20 augustus 2002 @ 18:19:
bedankt GiGNiC & species5618,

ik denk dat ik het nu snap. Maar is die x86-64 instructieset dan niet een beetje toekomstpraat voor de desktopmarkt, aangezien velen nog niet aan 4 GB geheugen beginnen, en die ellenlange registers ook nog niet nodig zijn? Ik bedoel, voor servers & serieuze workstations (sledgehammer & clawhammer DP)leuk en zo, maar de clawhammer SP is/wordt toch vooral een desktop cpu?

offtopic:
ik weet ondanks dit wel wat mijn nieuwe cpu wordt begin volgend jaar... Intel had mijn inziens zijn P3 verder moeten ontwikkelen...

Omdat x86-64 ook meer registers inhoud (16, ipv en dat is al een hele goede vooruitgang.

[Verwijderd]

SuperG schreef op 20 augustus 2002 @ 18:41:
[...]

Ik denk dat jij mijn hersenspinsel niet grondig gelezen hebt.

Te rap geweest en niet helemaal hetzelfde geinterpreteerd als jij bedoelde blijkbaar.

Als jij daar bv. zegt dat er een andere basisfrequentie van pakweg 100Mhz wordt genomen, ging ik ervan uit dat je bedoelt dat je ervan uitgaat dat er een extra signaal ergens wordt gemaakt dat met HT niks te maken heeft wat wel voor core wordt gebruikt.

Nujah, unimportant, 2x is beter dan 1x voor wie nog niet snapte

[Verwijderd]

SuperG schreef op 20 augustus 2002 @ 19:24:
[...]

IIg de core architektuur. Pipis en stages zijn niet hetzelfde

Ik bedoelde dan ook enkel het x86-64 feature van Hammer

[...]

Dit is de Server en heavy Workstatien markt daar speeld dit een rol in de desktop markt nog enkele jaren niet daar gaat het on de 64bit ALU en FPU kracht met SSE2

Inderdaad, maar het is er wel.

[...]

Denk aan data bewerking bijvoorbeeld grafische data bv.jpegs BMP Dibs op poetsen dat gaat nu dus per 64bit ipv 32bit.
Sommige Routines kunnen nu per slag 64bit verwerken dus op sommige plaatsen in de code is er winst te behalen net zoals we toen van 286 naar 386 gingen van 16bit naar 32bit het was eerst ook wachten op software

Ik stel mij voor dat dit enkel is op plaatsen waar anders voor grotere blokken 2 passes (of hoe moet ik het noemen) over een langer stuk data moeten worden uitgevoerd. Want naar mijn weten konden SSE/MMX en aanverwanten al op 2 verschillende data-blokken in 1 register (een 64 bits MMX-register bv.) een gelijke operatie uitvoeren. (En ik vermoed dat ik mezelf nu half aan het tegenspreken ben met eerder).

[...]

Dat heb ik ook gelezen de 64bit modus standaart integer is gewoon 32bit
Aangezien int's vaak als teller gebruikt worden is tellen tot 10 maar 4bits van toepassing dus tot 1000 wat meer tot 10000 ook hier is 32bit voldoende en dan zijn die extra 32bits belasten voor de memory footprint.

Maar voor speed wordt soms wel ruimte opgeoffert is een soort treade off Alignment of space. afhankelijk van de eisen en limieten
Het geheugen limiet probleem is tegenwoordig niet een groot probleem dat was vroeger anders met die 640KB

Ik heb op Aceshardware forum al een paar mensen horen kankeren over die 4GB, al zijn dat inderdaad meestal grafisch ontwerpers en dergelijke.

Alignment kan inderdaadhandig zijn, als Hammer in 64bits-blokken denkt. Aangezien default integer dus 32bit is kan ik me voorstellen dat er misschien wel een mechanisme is dat dit gemakkelijker maakt om per 32bits aan te spreken (DDR ondersteunt dan toch al "critical word first", dat is al iets). In het andere geval moeten we een beetje hopen op goede Spacial Locality van de software, die goed 2 bundels van 32bit bijeen probeert te houden.

[...]


in integer en FP proscessing wel ja maar data rondpompen niet je kan nu 8*bytes tegelijk rond pompen.

Klopt maar zie het zo in IA32 worden ook 64bit variablen gebruikt en die werden tot nu toe is 2 stappen gedaan en kunnen met 64bit X86-64 dus een een keer

Ook worden in gevallen van grote waarden 64bit int gebruikt nou daar werden vaak truckjes voor gebruikt is met 64bit niet nodig.
Maar dit is dus gewoon code eisen afhankelijk.

De ene app heeft totaal niks aan 64bit de andere weer wel.

Welja, sommige integercode die anders 64 (of in een freak-occasion 128)bit tegelijk wilde verwerken maar het in 2 stappen moest doen zal dus inderdaad vooruit gaan. SSE en SSE2 hebben echter geen vooruitgang gemaakt, tenzij de 16 registers in 64bit modus, de register-lengte is nog steeds even groot (128bit voor SSE 2 als ik me niet vergis, SSE heb ik geen idee meer van)

Data rondsturen weet ik zo niet, maar het verbaast me niet dat dat al met grotere blokken kan tegenwoordig.

Zijn er hier codekloppers of assembler programeurs.
mijn ASM ervaring zijn zo uit een ver verleden(6800X).

[SG]

Verwijderd schreef op 21 augustus 2002 @ 00:21:

Ik stel mij voor dat dit enkel is op plaatsen waar anders voor grotere blokken 2 passes (of hoe moet ik het noemen) over een langer stuk data moeten worden uitgevoerd. Want naar mijn weten konden SSE/MMX en aanverwanten al op 2 verschillende data-blokken in 1 register (een 64 bits MMX-register bv.) een gelijke operatie uitvoeren. (En ik vermoed dat ik mezelf nu half aan het tegenspreken ben met eerder).

Nou er zijn allemaal verschillende opties maar waar het verschil zit is dat
MMX is single intruction Mutiple DATA op integer basis
SSE hetzelfde maar dan op FP basis
64bit is een instruction en een grote variable.

Dus ik denk zoals je ook al zegt dat SSE(2) en MMX de 64bitarchitektuur overlapt maar niet helemaal dus de vooruitgang tussen IA32 en x86-64 zal niet zo groot zijn als tussen de 286 en 386
aangezien SSE2 zelfs 128bits data verwerkt.

Ik heb op Aceshardware forum al een paar mensen horen kankeren over die 4GB, al zijn dat inderdaad meestal grafisch ontwerpers en dergelijke.

Ja ik ook maar dat zijn extreme gevallen de zware jongens van de zware jongens

Workstation is van 1GByte tot over de 4GByte nou dat groepje van die meute die meer dan 4GByte nodig heeft is er bij gebaad voor die normale profies is IA32 voldoende

Alignment kan inderdaadhandig zijn, als Hammer in 64bits-blokken denkt. Aangezien default integer dus 32bit is kan ik me voorstellen dat er misschien wel een mechanisme is dat dit gemakkelijker maakt om per 32bits aan te spreken (DDR ondersteunt dan toch al "critical word first", dat is al iets). In het andere geval moeten we een beetje hopen op goede Spacial Locality van de software, die goed 2 bundels van 32bit bijeen probeert te houden.

Zo zullen er wel meer mogelijkheden zijn waar we niet opkomen maar ja AMD zegt ook al iets dat je met 64 code 10 á 20% gemiddeld verbetering kan verwachten en das altijd megenomen.

Welja, sommige integercode die anders 64 (of in een freak-occasion 128)bit tegelijk wilde verwerken maar het in 2 stappen moest doen zal dus inderdaad vooruit gaan. SSE en SSE2 hebben echter geen vooruitgang gemaakt, tenzij de 16 registers in 64bit modus, de register-lengte is nog steeds even groot (128bit voor SSE 2 als ik me niet vergis, SSE heb ik geen idee meer van

Ja ik vraag me af hoe die registers worden gevuld per 32bitdus 4 x haal en plaats in register en dan 'n 5-20CPU cycle bewerking er op los laten en resultaat per 32bit wegschrijven in geval van IA32 met x86-64 wordt er per 64bit gehaald geplaaats dus misschien heeft de FPU SSE(2) en MMX units er ook wat aan.

Data rondsturen weet ik zo niet, maar het verbaast me niet dat dat al met grotere blokken kan tegenwoordig.

in sommige C++ boeken die ik oa heb ,staan er soms ASM optimalisatie routines en die maken vaak ook gebruik van 32bit alignment voor als de data een heden kleiner zijn dus 8bits of 16bits dan is er aardig wat snelheid te halen.

HEt rondpompen van 'n 8 of 16 of 32bits variable gaat evensnel alleen worden de rest van de bits geignored en niet gebruikt daarom het truckje vab 8*4 of 4*8 of 2*16bits rondpompen waar mogelijk die truck is toe te passen en dan kan dat dan met 64bits ipv 32bits.

Tuurlijk kan dat met nog grotere blokken verwerktworden als je de hardware er voor hebt 'n 512bits GPU die kan dat of een gebufferde 128bits databus of 256bits L2bus maar dat is om de memory traagheid te kompenseren de core verwerkt gewoon per 32bit of 64bit.

[XWB]

Mensen, volgend bericht van X-Bit Labs klinkt niet gezond :

* Current AMD ClawHammer processors have some problems with reaching the necessary clock-speeds. At the moment AMD tries to redesign the core and add another metal-layer (like it was done with Thoroughbred) in order to increase stability when working at higher frequencies.
* 0.13 micron SOI technology is not as stable as AMD desires it to be. The yield is low, as a result, the price is high. IBM also has the same problem with their Power4 processors, but they are not as concerned about the final price as AMD is. The California based semiconductor maker now even considers all the pros and cons of introducing the ClawHammer CPUs without SOI used in manufacturing.
* Present version of memory controller is also not as stable as a rock and cannot be launched on the market. AMD also works on the matter, according to the source.

Blijkbaar toch warmte problemen?
En SOI & die ondie memory controller maken de boel niet echt stabiel.

http://www.xbitlabs.com/news/story.html?id=1031964793

[JeroenNietDoen]

At the moment AMD tries to redesign the core

Ai, dat kon nog wel eens een half jaartje duren voordat die klaar is. Dan nog produceren en mischien eind 2003 op de markt?

[XWB]

Ze hebben al een kwartaal uitstel gedaan ...

[NexuZ]

Zo krijgen ze alleen nog maar meer achterstand op Intel.

[Abbadon]

Ik zei het al in April

Abbadon schreef op 09 april 2002 @ 18:30:
[...]


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). ...Wat dat betreft ben ik niet zo optimistisch.

Maar dit is idd nogal belabberd voor de markt; Intel heeft zometeen een beste voorsprong en de prijzen zullen er gedurende die periode dan ook wel naar zijn

Trouwens hier nog een technisch tecchannel.de verhaal over de Hammer (als Duits geen probleem is, ander gooi je 'm door een translator ).

[XWB]

http://www.theinquirer.net/?article=5542

And he claims that the Hammer processor, using around 100 million transistors, will operate at the same 70 watts as an Athlon XP, using SOI.

Hoe warm zullen die wel niet worden?

[Verwijderd]

Verwijderd schreef op 20 maart 2002 @ 23:06:
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

Me To mischien ook de Nv30

[Verwijderd]

Hacku schreef op 25 september 2002 @ 07:19:
http://www.theinquirer.net/?article=5542


[...]


Hoe warm zullen die wel niet worden?

dan maar een Ultimate cooler

[EaS]

Hacku schreef op 25 september 2002 @ 07:19:
http://www.theinquirer.net/?article=5542


[...]


Hoe warm zullen die wel niet worden?

ff van mezelf gequote:

"In het artikel wordt vermeld dat een 40 miljoen transitoren tellende AMD processor (Athlon) op een gegeven snelheid 70 Watt verbruikt. Daarnaast word vermeld dat het SOI process ervoor zorgt dat een processor met 100 miljoen transitoren (Sledgehammer) opdezelfde snelheid het verbruik terug brengt tot ook 70 Watt.
Dus: De slegdehammer (o.a. 1 Mb Cache) verbruikt op dezelfde kloksnelheid als een Athlon evenveel energie (ondanks 2,5 x zoveel transistoren) !
Daarnaast is de die van de Hammer groter, en kan er dus meer warmte per oppervlakdeel afgevoerd worden.
Al met al zorgt SOI dus voor een gigantische reduktie in opname van energie en warmte afgifte !"

[XWB]

reviews: Prescott: is Pentium 5 het antwoord op Hammer?

De SOI technologie die AMD gaat toepassen in de Hammer is bedoeld om weglekkende stroom te voorkomen. Strained silicon daarentegen is bedoeld om de weerstand te verminderen. De reden dat Intel niet voor 'de andere' methode (of een combinatie van beide technieken) heeft gekozen is dat volgens het bedrijf nog duidelijke nadelen kleven aan SOI, die pas over een aantal jaar opgelost zullen zijn.

Dat er ook productieproblemen zijn door SOI hebben we al gemerkt aan het uitstel van de K8.
Waarom kiest AMD dan voor SOI en geen Strained silicon?

[SG]

Connecties
ze kunnen zelf wegens resources gebrek voor R&D niet zelf alles doen dus kopen in bij
IBM Mororola ?

Bij iNtel kan natuurlijk niet dus.
dus houd in dat niet alle technieken beschikbaar zijn en dus een partner overweging is.

Misschien omdat sommige oplossingen gedekt zijn door patenten en daardoor minder aantrekkelijk zijn.

[Verwijderd]

of misschien vindt AMD SOI nu eenmaal een beter alternatief dan Strained Silicon.

We zulle het hen is moete vragen

[Tachyon]

*Kick*

Misschien moet iedereen hier toch wat langer wachten op de Hammer als gedacht:

http://www.eetimes.com/semi/news/OEG20021017S0029

Originally the Athlon desktop Hammer was slated to be introduced in Q4 '02 and then slipped to the first quarter of 2003, and now won't come to market until late next year.

[Verwijderd]

achjah, als ik in de zomer mijzelf een degelijk PCtje kan bouwen ben ik tevreden

btw: SPEC voor een 2Ghz Hammer (vermoedelijk sledge): 1200 int en 1100 fp, very fancy IMO

[XWB]

Hij heet dus Athlon 64.
nieuws: AMD onthult naam ClawHammer: Athlon 64

Wat vinden jullie van de naam?

[Verwijderd]

Hacku schreef op 20 November 2002 @ 16:37:
Hij heet dus Athlon 64.
nieuws: AMD onthult naam ClawHammer: Athlon 64

Wat vinden jullie van de naam?

Athlon 64? N64 Hmm niet zo bijpassend naam. Naam maakt eingelijk voor mij niks uit , - de snelheid en kwaliteit.

BTW Hoe snel is die AMD Hammer ca. ??

[XWB]

De 3400+ moet aan 2GHz draaien.

[Verwijderd]

hoeveel gaat dat ding kosten?

[Verwijderd]

en als je nou eens kon kiezen tussen een Clawhammer DT met 256KB L2 Cache maar wel dus met een 16 bit hypertransport link,
of een Clawhammer DP met 512KB Cache en met "maar" een 8bit hypertransport link, voor een configuratie met 1 processor.

wat zou dan de betere optie zijn als het prijsverschil tussen de twee niet al te groot is (relatief, maar goed)

[XWB]

Een Clawhammer DP heeft 2x 8-bit hypertransport links, de DT 1 van 16 bit.
Lijkt me hetzelfde.

En misschien is het beter om één met 1 MB cache te nemen.

Weet iemand wat MT/s is?

[Verwijderd]

jup, die het liefst, maar die komt hoogstwaarschijnlijk een tijd later, dat staat ook in dat artikel, en als dat ongeveer tegelijkertijd met de prescot is, dan is dat dus eind 2004, en daar ga ik niet op wachten.

ja, die twee links zijn samen hetzelfde, maar worden niet tesamen gebruikt als 1 link

[Verwijderd]

Hacku schreef op 20 November 2002 @ 19:27:
Een Clawhammer DP heeft 2x 8-bit hypertransport links, de DT 1 van 16 bit.
Lijkt me hetzelfde.

En misschien is het beter om één met 1 MB cache te nemen.

Weet iemand wat MT/s is?

MT/s = Million transmission/sec

1600MT/s is dus in casu 800Mhz DDR, maar zou ook in theorie 400Mhz QDR ofzo kunnen zijn.

[XWB]

Op nieuws: AMD ClawHammer core krijgt versie met 1MB L2 cache

De ontwikkeling van de Hammer core is inmiddels aanbeland bij B0 silicium. Dit is de derde revisie van de Hammer core. De eerste A0 samples werden in februari van dit jaar gebakken en de revisie, die halverwege oktober naar de beta-testers werd gestuurd, lag op A2-niveau.

Wat is het verschil tussen al die niveau's? Welke is de final? B0?

[XWB]

Meer nieuws, zie http://www.vr-zone.com/#2775

"Hammer" processor will contain up to about 100 million transistor when emerge in the first half of 2003. The chip will have about 2.5 times as many transistors as the current Athlon chip. The Athlon has about 38 million transistors, so the total for Hammer would be approximately 95 million. The chip will debut at around 2GHz and come out with a performance rating number in the mid-3,000s. The ratings correspond roughly to the speed of Intel chips so an AMD Athlon XP 2800+ would perform like a 2.8GHz Intel Pentium 4.

SledgeHammer will have 1MB of secondary cache, as well as an integrated memory controller for connecting the processor to a PC's memory. The 1MB version will contain 100 million transistors and will mostly be sold into servers and be marketed under the Opteron name. A smaller version with 256KB or more of cache and an integrated memory controller will be marketed to desktops under the Athlon 64 name. The 1MB version of Hammer will likely sport a surface area of 180 square millimeters and Athlon 64 will take up around 105 square millimeters.

Wow, de Opteron (sledgehammer, 1MB L2) heeft een core grootte van 180mm². Benieuwd wat de prijs zal worden.

De Athlon 64 (clawhammer, 256 & 512 kb L2) heeft een core grootte van 105mm².
Later komen ook 1MB versies van de clawhammer, de core zal dan toch groter zijn dan 105mm² en de prijs toch hoger? Of komen die 1MB clawhammers enkel met de 90 nanometer hammers?

En hoe kan de core van de clawhammer DT evengroot zijn als die van de clawhammer DP als de DP meer L2 cache heeft?

[XWB]

[edit]
weer online

[ Voor 86% gewijzigd door XWB op 30-11-2002 16:00 ]

[Verwijderd]

ik denk dat die 105mm² enkel slaagt op de 256KB L2 variant, en dat de 512kb L2 versie iets van een 130mm² gaat halen, wetende dat Barton iets meer dan 100mm² zou worden, en Sledghammer 180mm² doet.

[Verwijderd]

Weet er iemand er toevallig welke technology-beurzen (genre Comdex, ...) er nog voor Maart/April(Juni in het slechtste geval) komen ? Met de nu vernoemde lanceerdatum zou ik voor die tijd toch ietwat concretere info verwachten over cache-implementaties (bandbreedte, latency), vermogenopname,... en eventueel benchmarks op een ietwat degelijke clocksnelheid. Naar goede gewoonte leveren van die beurzen goede momenten om info prijs te geven.

[Mental T]

Zal mijn huidige socket-A koeler die vast zit op de gaten van het moederbord ook te gebruiken zijn op de Hammer-moederborden?

Zullen de afstanden van de gaten hetzelfde zijn?

[XWB]

Mental T schreef op 12 December 2002 @ 11:16:
Zal mijn huidige socket-A koeler die vast zit op de gaten van het moederbord ook te gebruiken zijn op de Hammer-moederborden?

Zullen de afstanden van de gaten hetzelfde zijn?

Als ik me niet vergis zullen er geen gaten meer zijn.
En socket A coolers zullen niet op de hammer cpu's passen.

Meer nieuws:
http://www.xbitlabs.com/news/story.html?id=1039655680

Volgens xbitlabs zal er in maart/april enkel een paper-launch zijn en zullen alleen reviewers een cpu krijgen.
Wij moeten nog wachten tot de 2de helft van 2003.
Hoop dat het niet waar is.

[EaS]

De hammer krijgt een nieuwe manier van coolers installeren:



Gaat op de volgende manier, dit doe je onder het moederbord:



Daarna komt dit aan de bovenkant van het moederbord er boven op:



En daarna bevestig je de cooler zo:



Met schroeven dus......geen link gedonder meer veel te strakke clips etc.

[Mental T]

Hacku schreef op 12 December 2002 @ 12:26:

Als ik me niet vergis zullen er geen gaten meer zijn.
En socket A coolers zullen niet op de hammer cpu's passen.

Op diverse moederborden die getoond zijn op de Comex waren toch echt wel gaten te vinden. Soms twee naast de socket en soms vier rond de socket.

Ik vraag me af of de afstanden tussen deze gaten hetzelfde zijn als nu bij socket A. Dan zou ik mijn bij Tha_Mafkees bestelde waterblok ook in de toekomst kunnen gebruiken.

[XWB]

Mental T schreef op 12 december 2002 @ 13:49:
[...]


Op diverse moederborden die getoond zijn op de Comex waren toch echt wel gaten te vinden. Soms twee naast de socket en soms vier rond de socket.

Ik vraag me af of de afstanden tussen deze gaten hetzelfde zijn als nu bij socket A. Dan zou ik mijn bij Tha_Mafkees bestelde waterblok ook in de toekomst kunnen gebruiken.

nieuws: Niet langer heatsink-gaten in AMD moederborden

[EaS]

Er zijn ook weer nieuwe hammer benchmarks verschenen. In de nieuwe Duitse versie van de c't....las ik op het messageboard van de aceshardware. Hier de resultaten:

code:

                    Cache     Memory
1,2 GHz Athlon64     1  MB    PC-2700
1,2 GHz AthlonXP    256 kB    PC-2700
2,2 GHz Pentium4    512 kB    PC-2100

code:

                   Quake III           Aquamark
                  High-Quality       1024x768x16
1,2 GHz Athlon64     225.3              49.5
1,2 GHz AthlonXP     172.4              48.3 
2,2 GHz Pentium4     218.9              51.5

code:

                   DivX5.02       Xvid
1,2 GHz Athlon64     569s         750s
1,2 GHz AthlonXP     709s         929s
2,2 GHz Pentium4     497s         717s

code:

                      Memory     Memory     32 bit
                    Bandwidth    Latency     read
1,2 GHz Athlon64    2306 MB/s    87  ns    1922 MB/s
1,2 GHz AthlonXP    2041 MB/s    112 ns    1250 MB/s
2,2 GHz Pentium4    2080 MB/s    227 ns    1888 MB/s

code:

                    3DMark2001         Comanche 4
                  800x600 H/W T&L      1024x768x32
1,2 GHz Athlon64      8753                36.6
1,2 GHz AthlonXP      7601                28.4
2,2 GHz Pentium4      9008                36.3

[ Voor 33% gewijzigd door EaS op 14-12-2002 13:52 ]

[Olaf van der Spek]

Dat is de Opteron toch met 1 mb L2 cache? De memory-latency van de P4 is wel erg hoog. Is daar een verklaring voor?
En met welke kloksnelheid wordt de Hammer gereleased?

[EaS]

OlafvdSpek schreef op 14 december 2002 @ 14:03:
Dat is de Opteron toch met 1 mb L2 cache? De memory-latency van de P4 is wel erg hoog. Is daar een verklaring voor?
En met welke kloksnelheid wordt de Hammer gereleased?

Nee de Athlon64 komt ook in versies met 1 MB cache.

[XWB]

EaS schreef op 14 december 2002 @ 13:40:
Er zijn ook weer nieuwe hammer benchmarks verschenen. In de nieuwe Duitse versie van de c't....las ik op het messageboard van de aceshardware. Hier de resultaten:

code:

                      Memory     Memory     32 bit
                    Bandwidth    Latency     read
1,2 GHz Athlon64    2306 MB/s    87  ns    1922 MB/s
1,2 GHz AthlonXP    2041 MB/s    112 ns    1250 MB/s
2,2 GHz Pentium4    2080 MB/s    227 ns    1888 MB/s

Die on-die memory controller doet goed zijn werk.