AMD werkt aan twee verschillende 64 bit platformen

In een artikel van Extreme Tech komt wat interessante informatie naar boven over de verschillen tussen de ClawHammer en SledgeHammer processors. Volgens Mark Bode, product marketing manager bij AMD, zijn er meer verschillen tussen deze twee dan eerder werd aangenomen. SledgeHammer zou volgens de informatie die tot nu toe voorbij is gekomen namelijk alleen betere SMP mogelijkheden en grotere caches hebben dan ClawHammer. Het antwoord op de vraag of x86-64 slechts een uitbreiding op de K7 core is of een echte nieuwe K8 was erg onduidelijk.

Uit de nieuwe informatie blijkt echter dat beide opties waar zijn; ClawHammer moet namelijk een 32 bit chip worden die ook enkele 64 bit instructies kan verwerken en SledgeHammer zou een echte 64 bitter worden. Volgens Bode moeten de chips echt als verschillende platformen worden gezien, hij vergelijkt het zelfs met de overstap van 16 naar 32 bit tussen de 286 en de 486. Beide processors worden in de tweede helft van 2002 uitgebracht, tegelijk met het 0,13 micron SOI procédé:

Some thought that ClawHammer might be a development platform for SledgeHammer, just like the current Merced processor of Intel's Itanium family is thought to be a tool for Itanium software developers, not a production part. If that was true, then OEMs would have to choose between the "development" and the "real" version of the Hammer, both due out at about the same time. Analysts said it's not that simple.

"It's not a neat market segment arrangement," said Dean McCarron, analyst with Mercury Research Corp. in Scottsdale, Ariz. "That's not the (Hammer's) fault or even AMD's fault. If you look at where the market is now, (AMD's) got minimal inroads into the corporate market. Right now everything they've got goes into consumer. So, over time, that's going to get hashed out."

Bode declined to discuss the speeds or cache sizes of the forthcoming cores. Sources said it's reasonable to speculate that cache sizes may range from 256 Kbytes on up to about 2 Mbytes, but that they haven't yet been set in stone. The limiting factor will be die size, they said; Bode reiterated, as other AMD executives have said, that the ClawHammer will be less than 100 sq. mm on a 0.13-micron process.

Reacties (41)

[stok]

Betekent dit dat AMD de strijd aan kan gaan met de Itanium?? Of is de Itanium nog weer een klasse hoger

[Verwijderd]

Itanium is nog altijd een klasse hoger dmv EPIC.

[Femme]

Op dit moment is alleen de FPU performance van de Itanium goed te noemen. Integer performance is erg mager, slechter dan de Ultrasparc III, MIPS R14000, HP PA-8600, Alpha EV68, Athlon MP en P4. Integer performance lijkt me toch wel erg belangrijk voor een server CPU aangezien de meeste servers niets anders doen dan integer bewerkingen. De SledgeHammer gaat hier iig scoren dankzij z'n hoge kloksnelheid.

Het is de bedoeling dat McKinley veel sneller wordt dan Merced. Een vergelijking tussen de SledgeHammer en huidige Itanium heeft daarom al niet zoveel zin, ook al omdat SledgeHammer een segmentje lager zit. AMD zal het in het begin waarschijnlijk vooral moeten hebben van de kleinere Linux server bouwers zoals Penguin Computing (VA Linux is gekapt met hardware).

[Verwijderd]

[off-topic]

(VA Linux is gekapt met hardware).

hmmmm was dat geen ingestuurd nieuws......
[/off-topic]

waarom zou AMD dan zich moeten richten op de kleinere linux servers?
<font color=#786562>* dioser@work begrijpt ff niet wat T.net goeroe bedoeld B-)</font>

[Femme]

hmmmm was dat geen ingestuurd nieuws......

Ik zie net dat je het om 9:05 in de nieuwssubmit hebt gezet, maar gisteren stond 't al op Slashdot.

[Paitor]

Itanium is idd nog een klasse hoger.

MAAR: AMD is wel zo slim om een tussenstap te maken met de 64 bit. De Itanium is onbetaalbaar voor de thuisgebruiker iig, en wat AMD dus weer flikt, een goede proc die bijna even goed, misschien niet merkbaar slechter is, voor een lagere prijs.

Dat is erg handig, want ik was echt bang dat AMD dankzij de minder snelle R&D op achterstand zou komen en weggedrukt zou worden.

[Beaves]

MAAR: AMD is wel zo slim om een tussenstap te maken met de 64 bit.

Er gaan geruchten dat Intel ook bezig is met een x86-64 variant als tussenstap voor de Itanium, zie www.tweakers.net/nieuws/16932?highlight=Intel

De Itanium is onbetaalbaar voor de thuisgebruiker iig, en wat AMD dus weer flikt, een goede proc die bijna even goed, misschien niet merkbaar slechter is, voor een lagere prijs.

De Itanium is ook niet voor de thuisgebruiker, alleen voor de hele zware servers. Ik geloof dat Intel pas in 2005 ofzo de Itanium klaar vindt voor de thuismarkt.

edit:

Sorry Ik zie nu pas dat hier boven ook al iets staat over het gerucht.

[Ritch]

64bit procs zijn nou niet echt gemaakt voor de consument (zeker niet atm), alleen hele dikke servers zullen eeen itanium krijgen, daar zal de prijs niet zo heel veel uitmaken.

Nou gaat ook nog het gerucht dat intel ook bezig is met een soort tussenstap, dus ook een 64bit x86 idee...

[Verwijderd]

Precies, net zoals 640kB genoeg geheugen is dat nodig is voor een computer...

[slacksoff]

ik denk dat de itanium dus echt een maatje te groot is. het is natuurlijk een ander platform dus wie weet zijn deze proccy's voor hele andere doelen geschikt dan itanium.

ik verwacht dat in ieder geval 1 van deze 2 een k7 core is met wat extra instructies. waarom? AMD heeft volgens mij echt het geld niet om steeds nieuwe architecturen te ontwikkelen uit het niets. [intel wel]

[justice strike]

zoals al eerder gezegd kan de sledge hammer wel degelijk iets doen tegenover de (veel snellere) itanium omdat de ittanium maar een maximum aantal gekoppelde cpu's kan hebben zal er toch een limiet zijn.. dat en de duurdere prijs zullen voor sommige bedrijven toch de optie van de sledgehammer openhouden omdat er gewoon meer cpu's aan elkaar gekoppelt kunnen worden en nog goedkoper is ook.

(prijs maakt wel degelijk uit tenzij je het over die megabedrijven hebt....)

[Eelke Spaak]

itanium omdat de ittanium maar een maximum aantal gekoppelde cpu's kan hebben zal er toch een limiet zijn

64 om precies te zijn, dus dat lijkt mij wel redelijk voldoende .

[Sharky]

ik verwacht dat in ieder geval 1 van deze 2 een k7 core is met wat extra instructies. waarom? AMD heeft volgens mij echt het geld niet om steeds nieuwe architecturen te ontwikkelen uit het niets.

een K7 core in een 64 bits processor? nee ik denk ik niet dat dat gaat werken.
een K7 is 32 bits en het lijkt me stug dat je die core terugvind in een heel ander soort proc.

[[Shadow]]

Tuurlijk wel... je kunt de K7 core uitbreiden met 64-bit extensies, 64-bit registers en extra 64-bit instructies.

Net zoals je de proc kunt uitbreiden met MMX of SSE kun je hem uitbreiden met 64-bit extensies. Het is iets ingewikkelder dan ik het hier doe voorkomen, maar hier komt het wel op neer...

Vraag is alleen of het zinvol is om de x86 architectuur die ondertussen al meerdere decennia heeft overleefd dit aan te doen... ik denk dat Intel met de Itanium/EPIC architectuur een goede zet heeft gedaan.

[mister X630]

de claw-hammer is een uitgebreide X86, zodat deze een aantal 64-bits functies aan kan. en de Sledge-hammer is een complete nieuwe 64-bits CPU.

uit het verhaal:

...ClawHammer moet namelijk een 32 bit chip worden die ook enkele 64 bit instructies kan verwerken en SledgeHammer zou een echte 64 bitter worden....

[Verwijderd]

Rijst bij mij toch de vraag hoeveel toekomst er nog is voor die grote,extreem dure servers. Vaak is een cluster (Beowulf) met gewone hardware goedkoper en ik denk dat daar ook een groeimarkt in zit.
Bij ons op Shell staat dat IBM cluster (1024 x-servers) en dat is sneller en veeeeel goedkoper dan de grote SUN's die er ook nog staan.

[Verwijderd]

Lijkt erop dat zowel Intel (zie overname Alpha) en AMD toch een nog een goede markt zien voor dit soort proc's.

Je hoeft ze natuurlijk niet als 16 of zelfs 64 way te configureren, 4 way kan al genoeg zijn voor bepaalde toepassingen.

Tot nu toe is de investering voor dit soort procs voor Intel e.a. het waard geweest vanwege de enorme marges op dergelijke procs, AMD gelooft daar dus blijkbaar ook in.

[Beaves]

Rijst bij mij toch de vraag hoeveel toekomst er nog is voor die grote,extreem dure servers. Vaak is een cluster (Beowulf) met gewone hardware goedkoper en ik denk dat daar ook een groeimarkt in zit

Wat je gemakshalve even vergeet is dat zo'n cluster misschien wel goedkoper is in aanschap maar dat de ruimte waar zo'n cluster moet staan veel groter en veel beter gekoeld moet zijn, wat dus ook zeer veel geld kost. Dan lijkt het me handiger om het met de helft van de computers af te kunnen.

[raymondw]

Iedereen heeft het bij Itanium over "dikke" servers...
Gaat niet helemaal op als je de markt een beetje kent

1. Itanium word (nog) geen High-end CPU bij de groote bedrijven. De servers worden ook niet als echte high-end gepromoot, dit blijft voorbehouden aan de 4 en 8-way Xeon beestjes.

2. Er zijn diverse fabrikanten die de Itanium voor hun zwaardere werkstations gaan gebruiken. Dit in plaats van de Xeon modellen.

BV Dell, die hebben nu een Dual Xeon (Workstation 620) die word vervangen voor de Dual P4 Xeon en gaat 530 heten. Daarboven komt de 730 met ..... iid Itanium.

Op het server gebied gaat dit niet gebeuren, daar komt de Itanium niet bovenaan. Word ergens als high-end tussenklasse (wat een plek..) server neergezet.

Zo My 2 cents

[Verwijderd]

hij vergelijkt het zelfs met de overstap van 16 naar 32 bit tussen de 286 en de 486

Dat moet tussen de 286 en 386 zijn. Nou is het wel zo dat de 386SX maar gedeeltelijk 32-bits was, maar laten we dat ff niet meerekenen omdat de DX toch ouder was...

Maar 't is wel fijn dat AMD op alle lagen van de CPU-markt actief wil zijn met x86-64 want ik wel er ook wel een!

[x-wolf]

De SledgeHammer wordt dan vergelijkbaar met de 386DX en de ClawHammer vergelijkbaar met de 386SX. Nu maar afwachten of de SledgeHammer ook eerder uitkomt dan de ClawHammer

Verder ben ik benieuwd of de huidige software draait hierop, dus of deze proc. ook downwards compatible is? Anders moet er eerst weer nieuwe software geschreven worden speciaal hiervoor, dan duurt het wel ff. Als dit wel mogelijk is dan kan deze proc. snel de plaats innemen van de huidige serverprocs. Natuurlijk moet de prijs dan niet veel hoger zijn dan de huidige serverprocs, anders vindt de consument dit natuurlijk niet interessant, of hoogstens op het allerhoogste niveau waarin het alleen draait om rekenkracht en niet om geld vindt men het dan interessant. Wanneer zou dit komen voor de gewone consument of voor de tweakers?

[GeeBee]

De SledgeHammer wordt dan vergelijkbaar met de 386DX en de ClawHammer vergelijkbaar met de 386SX.

Dat lijkt me toch niet?
De 386SX was toch gewoon een gemankeerde DX zonder FPU-gedeelte? Volgens geruchten waren het zelfs afgekeurde DX-en waar alleen de FPU van kaduuk was. Prima te gebruiken dus voor andere zaken...

Het verschil 32-bits <-> 64 bits lijkt me groter dan met FPU <-> zonder FPU

[MeNTaL_TO]

De 386SX was toch gewoon een gemankeerde DX zonder FPU-gedeelte? Volgens geruchten waren het zelfs afgekeurde DX-en waar alleen de FPU van kaduuk was. Prima te gebruiken dus voor andere zaken...

Dat is een gerucht die ging over de 486dx /sx

De SX ontbeerde de fpu, verder was ie exact hetzelfde.

[Verwijderd]

Verder ben ik benieuwd of de huidige software draait hierop, dus of deze proc. ook downwards compatible is

Dat lijkt me voorlopig nu juist de kracht van amd. De procs blijven gebaseerd op de x86 architectuur, dus x86 geoptimaliseerde software gaat vast en zeker goed draaien. Maar zoals ik zei: voorlopig. Zodra al die ia64 software doorgedrongen is zal dat voordeel eerder een nadeel worden.

De reden dat amd geen compleet nieuwe architectuur ontwikkelt lijkt me duidelijk: het kost te veel tijd, geld en moeite. Tegend de tijd dat ze dat zou lukken zou ia64 al wijd en breid verspreid zijn.

[Bobco]

Wat wil jij in godsnaam dan op een 64bit cpu draaien? Of wil je thuis een dikke server neerzetten?

Praktische overwegingen zijn niet zo belangrijk, het is gewoon leuk om er een te hebben. Wat doet iedereen hier met al die extra MHz'en na OC'en?

Bijna niemand heeft dat echt nodig, behalve de echte D.net fanaten natuurlijk

[Verwijderd]

Tegenwoordig ben ik continue aan het divx-encoden etc. Daarvoor is elke extra MHz meegenomen.

(Heb al een HD-RAID 0, extra RAM en Overgeklokte Athlon, maar kan nog steeds niet real-time encoden )

[PuzzleSolver]

Wat wil jij in godsnaam dan op een 64bit cpu draaien? Of wil je thuis een dikke server neerzetten?

Meer dan 4Gb virtual adress space hebben voor programma's.

De vergelijking van 16 naar 32 in de 286 en met de 486 klopt ook wel aardig. De 286 was 32 bit door middel van een patch (protected mode) hierbij was geen volwaardig 32 bits aanwezig maar een verkapte vorm die comptible was met de oude geheugen adresering. De 386 en 486 waren wel volwaardig 32 bit.

De 386sx by the way was een volwaardige 32 bitter die op een 16bit bus werd aangesloten (hierdoor waren alleen altijd 2 clockcycles nodig voor elke data fetch en dat maakt hem soms trager dan een 286 op dezelfde clock)

[PuzzleSolver]

Dus een 286 kan volgens jouw maar 16 bit is 64Kb geheugen adreseren?

Zucht, nou dan toch maar de hele uitleg

******** X86 voor 286

Seg : Offset
XXXX : XXXX
1234 : 1234

Deze twee zijn beide 16 bits en de Seg werd 4 bits naar links geshift en de offset er bij opgeteld om samen een 20 bits adres te vormen. Dit stond voor 1MB adres ruimte waarvan alles boven de 640KB gereserveerd was voor de hardware.

******** X86 protected mode (sinds 286)

Sel : Offset
XXXX : XXXX
1234 : 1234

De segment is veranderd in een Selector die een index vormt naar een Selector table. Dit is gewoon een array ergens in het geheugen die een blokken geheugen beschrijft. In deze array staat een 32BIT base address en bij deze wordt de 16 bit offset opgeteld om een echt geheugen address te vormen. Er was dus wel degelijk spraken van 32bits adressering hoe dit naar buiten aangesloten werd weet ik niet maar de processor was in ontwerp in ieder geval 32bits. Het kan best zijn dat er maar 24 bits aan de buitenkant beschikbaar waren. Dit was bv ook het geval bij de 68000 in die tijd (ook een 32 bits proc) met 24 bits heb je nl. 16MB geheugen, zat voor die tijd.

******** X86 32bits protected mode, virtual mode (sinds 386)

Sel : Offset
XXXX : XXXXXXXX
1234 : 12345678

Dit ga ik niet helemaal uitleggen maar vooruit een beetje. De offset is 32 bits geworden zodat ook blokken groter dan 64K in een keer geadresseerd kan worden (zonder trucjes). Dit geeft in princiepe een 48bits adressering maar goed we noemen het geen 48 bits processor. De tabbellen om de geheugen blokken te omschrijving beschikken nog steeds over een 32 bits address dus er is max 4 GB address space (Zelfs al gebruik je de selector registers waar NaioN het over heeft) Verder wordt de uitkomst nog eens door een page table gehaald waardoor geheugen zich ook op schijf kan bevinden en geladen wordt als het nodig is en kunnen dezelfde programma's met verschillende addressen naar hetzelfde geheugen verwijzen. Deze address space is nog steeds 32bits.

******************** Wat ik vermoed

Bij de ClawHammer komt er waarschijnlijk een trucje via de pagetable of via de selector table om 64 bit adressering mogelijk te maken. Maar tegelijk blijft hierbij de geheugen adressering per programma beperkt tot 4Gb. Bij de SledgeHammer wordt het waarschijnlijk volledig mogelijk om 64 bits te gebruiken (Net als het verschil tussen de 286 en 386 in 32 bits). Dat bedoelde ik dus in iets minder woorden duidelijk te maken

[.oisyn]

De 286 was 32 bit door middel van een patch (protected mode) hierbij was geen volwaardig 32 bits aanwezig maar een verkapte vorm die comptible was met de oude geheugen adresering

ummm de 286 was dus helemaal niet 32 bit. Wat ie wel had was de protected mode waar je het over hebt, maar dat maakt m niet 32 bit. Die protected mode zorgde ervoor dat ie geheugen op een andere manier geheugen kon adresseren (selector : offset ipv segment : offset) en er zaten een zooi debug features in

.edit: spaties tussen : en offset, anders werd het een

[NaioN]

Meer dan 4Gb virtual adress space hebben voor programma's

Huidige 32 bits processoren kunnen dat ook al, dit doen ze met extra registers. Ik weet niet hoe het precies werkt, maar ik dacht ongeveer zoals de oudere intels (8068 etc) met segmentering werkten. Het OS moet dit trouwens wel ondersteunen (die extra registers)

De vergelijking van 16 naar 32 in de 286 en met de 486 klopt ook wel aardig. De 286 was 32 bit door middel van een patch (protected mode) hierbij was geen volwaardig 32 bits aanwezig maar een verkapte vorm die comptible was met de oude geheugen adresering. De 386 en 486 waren wel volwaardig 32 bit.

Naja ik mis dus de 386, die was intern volledig 32 bits, alleen de sx versie had een 16 bits databus naar buiten. Dus er had moeten staan: overgang van 286 naar 386.
Verder was de 286 volgens mij volledig 16 bits, protected mode zorgt niet voor extra adreslijnen. Onder die mode kon je echter wel het geheugen lineair aanspreken

[RG]

Dat hoeft niet hoor. Ik denk dat binnen afzienbare tijd er wel een Linux distributie zal komen die geschikt is voor die processor. AMD is al samen met SuSE bezig met het gereed maken van de kernel voor deze processor. GlibC en GCC werken er volgens mij al mee. Dan is het een kwestie van alles opnieuw compileren en dan heb je een desktop voor je neus. Volgens mij is SuSE hier al aan bezig.

[Atmosphere]

Stoer mogelijkheden die deze imformatie geeft .. Nu is het volgens mij toch wel duidelijk dat Clawhammer en Sledgehammer codenamen zijn, Over de uiteindelijke werking van de processor valt natuurlijk niets te zeggen. Daarom vind ik het voorlopig nog wat overtrokken om te zeggen dat de Itanium een maatje te groot is voor de 64Bits proc van AMD. Ik wil eerst resultaten van beide zien, zoals in database preformance e.d. Als het inderdaad een verschil is wat Mark Bode (overgang als 286->486) aangeeft zouden we bijna over een nieuw platform kunnen spreken, en is er dus geen zinnig woord te zeggen over de prestaties. Overigens mag ook de gebruikte procedes voor het produceren van die chip niet vergeten worden (SoI en 0,13 micron copper-interconnects). Hierdoor kan de kloksnelheid flink opgedreven worden, en zou het kunnen zijn dat, ondanks de EPIC architectuur (die zeer compiler afhankelijk is), de Sledgehammer sneller is.

[bobsnl]

Gewoon een socket A bord op basis van KT133A, KT266, AMD 760(of AMD761+VIA), ALi MAGiK 1, nVidia Crush, SIS 735 , .....dus borden met 266 MHz FSB ondersteuning.

[Atmosphere]

de 286 was dus 16 bits, vanaf de 386 werd er gebruik gemaakt van een 32 bits adresbus... *echter in de 386SX was de databus 16 bit, echter door een memory manager kon dit geheugen opgedeelt worden in pagina's ..

[arjenk|IA]

Lees eens wat hier een stukje boven al over de 286 gezegd is.

De 16 bit databus van de 386SX was transparant voor de software, die de SX gewoon als een DX zag. Op die bus werden 32 bits gewoon in twee brokjes van 16 bit getransporteerd, maar dat werd volledig door hardware gedaan.

* 786562 arjenk