AMD K8 Hammer micro-architectuur preview

EaS wees ons op een diepgaand artikel dat door Hans de Vries is geschreven voor de site Chip Architect. Het artikel begint met de opsomming van maar liefst 16 patenten die rechtstreeks op de K8 architectuur betrekking hebben, die voor het eerst zal verschijnen in de Hammer processors en uiteindelijk de huidige K7 architectuur, bekend van Athlon en Duron, moet gaan opvolgen. De K8 chips zullen 64 bits processors worden die kunnen concurreren met de Itanium van Intel, maar de Hammer blijft in tegenstelling tot de Itanium zonder emulatie compatible met de huidige software.

Wat het meest opvalt aan SledgeHammer, de eerste K8 voor servers, zijn de twee CPU-cores waaruit de chip bestaat. Men kan bijna spreken over een dual processor systeem op een chip, maar dat is niet het geval. De SledgeHammer is net zoals de huidige x86 processors een single-threaded processor. Met andere woorden, hij kan maar één instructiestroom tegelijkertijd uitvoeren. Door enkele gepatenteerde mechanismen om de instructiestroom over de twee CPU-cores te verdelen, kan men echter wel een hoge graad van parallellisme bereiken. Daarnaast heeft elke core zijn eigen registerset, wat betekent dat het draaien van twee threads tegelijkertijd in feite mogelijk zou moeten zijn, hoewel hier niks over staat in de patenten. Uiteraard is een nieuwe processor niets zonder de chipset die erbij hoort en daar schrijft Hans de Vries het volgende over:

A number of ClawHammer chipsets have now been placed on the roadmaps. These chipsets use Hyper Transport to communicate with ClawHammer at a presumable speed of 800 MHz and a total bandwidth of 6.4 Giga Byte/s. Three times that of the current 266 MHz EV6 bus. Hyper Transport is said to scale to 1.6 Giga Hertz and 12.8 Giga Byte/s. The Memory Controller is still integrated on the Chipsets with support for 266 and 333 MHz DDR SDRAM. One should hope that these chipsets support 128 bit busses to memory to take advantage of the higher bandwidth.

Reacties (70)

[tweakerbee]

Klinkt revolutionair. Hopen dat het net zo'n knaller wordt als de K7 serie.
Ik snap alleen niet dat ze gelijk die 64-bits proc op de thuismarkt richten. Daar heeft de consument toch nog helemaal geen behoefte aan?
En moet je dan apart gecompileerde programma's hebben wil je de snelheidswinst meepakken?
Natuurlijk is dat niet compatible met de Itanium...
Krijg je bij je Hammer OEM systeempje dan een 64bits WindowsXP versie of zo?

[apa]

Als je kijkt naar de concurrentie (Intel dus), dan begrijp je wellicht al sneller waarom AMD ASAP 64-bit mainstream wil maken.

De Itanium (en IA64 in het algemeen) zal nog wel een poosje high-end blijven. Uiteindelijk wil Intel ervoor zorgen dat Itanium DE 64-bit processor wordt.

Als AMD snel genoeg is en zijn 64-bit CPU meteen mainstream kan maken (en ervan uitgaande dat IA64 nog een paar jaar langer zuiver high-end blijft), dan is het mogelijk dat Hammer door de mainstream gezien wordt als DE 64-bit processor. AMD rekent er dan op dat ontwikkelaars van mainstream-apps snel hun apps naar x86-64 code compileren om de beste performance op mainstream te kunnen bieden.

Wanner Intel dan IA64 in de mainstream wil doorduwen, dan zal snel blijken dat de 64-bit apps er minder sterk op presteren dan op de Hammer. Dit is zeker wat AMD hoopt!

Ironisch is dat AMD kan te weten komen of dit een werkende strategie is uit de verkopen van de P4. De P4 presteert immers veel beter als de code er speciaal voor geschreven is. Een aantal apps werden nu speciaal ge-recompiled om de maximale performance te kunnen bieden: dat gaat dan in eerste instantie om apps die erg reken-intensief zijn (zoals FlaskMPEG, ...), later volgen dan o.m. games en grafische apps. Ik spreek hier dus enkel over mainstream he... server apps (DB's, CAD-apps, ...) worden vaak nog vroeger omgezet.

Ik dacht eerder dat dit geen werkende strategie zou zijn (bij de lancering van de P4), maar blijkbaar werkt het wel (de P4 wordt door de grote meerderheid van de mainstream wel degelijk aanzien als de top-CPU). De strategie zou dus zeker zinvol zijn.

[PuzzleSolver]

Ten eerste IA64 en x86-64 zijn twee hele verschillende concepten en de naamgeving is maar al te verwarrend. IA64 is een nieuwe (EPIC)instructieset en een nieuwe manier van instructies afhandelen terwijl bij x86-64 er alleen maar sprake is van een manier om 64bit te kunnen adresseren (>4Gb). Dit lijkt mij ook een nodige stap omdat binnen een paar jaar 4Gb geheugen wel eens heel normaal zou kunnen worden.

Waarschijnlijk zijn er ook 64 bit data registers bijgekomen maar 64 bit databewerking (en ook 128 bit) zijn al mogelijk met MMX SSE SSEII 3DNow. De databus van de huidige processoren is al sinds de Pentium 64 bit.

De optimalisaties waar de P4 het van moet hebben zijn de SSE2 optimalisties en deze hebben betrekking tot de FPU performance (Dus CAD en Flask in floating point mode).

Waarschijnlijk wordt het voor de AMD x86-64 oplossing niet nodig om de software opnieuw te compileren of optimaliseren (tenzij je meer dan 4Gb geheugen in je applicatie wilt kunnen gebruiken of veel gebruik maakt van 64 bit berekeningen). Ik denk dat het OS gewoon beschikking heeft over de 64 bit adressering en daarvan een stukje geheugen aan de 32 bit applicatie geeft die gewoon binnen z'n eigen (max 4Gb) addresspace blijft en gewoon op de oude manier kan blijven werken.

Bij de IA64 zullen de applicaties echt opnieuw gecompileerd moeten worden om der goed op te kunnen draaien. Tevens omdat de snelheidswinst die met EPIC te behalen is voor een heel groot deel afhankelijk is van de intelligentie in de compiler.

[apa]

Hmz... Heb er nog nooit eerder van gehoord dat de Pentium een 64-bit CPU zou zijn... Geheugenadressering is natuurlijk 1 zaak... Maar is het niet zo dat ook de databus (het bus waarover de communicatie tussen CPU en de rest van het systeem over verloopt) eveneens 64-bit wordt op 64-bit CPU's? Is dat nu dan niet (slechts) 32-bit?

Dat MMX, SSE en SSE2 64- en zelfs 128-bit bewerkingen kunnen uitvoeren is misschien wel mogelijk... dat maakt de CPU echter nog niet noodzakelijk 64-bit (of 128-bit).

Of zie ik dat verkeerd (kan best zijn hoor; ik ben zelf geen ingenieur in de electronica: al wat ik weet, weet ik van het lezen uit interesse)? Is het dan wel zo dat de definitie van een 64-bit CPU is: "64-bit geheugen adressering ondersteunen"?

Dat IA64 (of gebaseerd op EPIC) een volledig nieuwe instructieset is, wist ik wel... Toch moeten progs hercompileerd worden om van x86-64 gebruik te maken. De Hammer ondersteunt in feite 2 modi: 1 mode in 32-bit en 1 mode in 64-bit. Switch tussen beide is dynamisch en behoeft geen reboot, ... De app moet echter wel in x86-64 code gecompileerd worden in de 64-bit mode te kunnen werken.

[PuzzleSolver]

De databus tussen geheugen en CPU is al sinds de pentium 64 bits. Intern op de processor komen zelfs nog bredere bussen voor naar bv. de cache. De term 32 bits en 64 bits processor is een beetje vaag omdat hier niet bij gezecht wordt of het om de databus gaat of om de adresbus. De huidige processoren beschikken over zoveel verschillende data en adrespaden dat het moeilijk wordt om over een x-bits processor te spreken. In de huidige pentium zijn zowel de adres als de dataregisters 32 bits verder heb je nog 16 bits selector (in vroegere x86 segment) registers. Deze selector registers worden tegenwoordig gebruikt om een programma te kunnen laten beschikken over een eigen 32bits adressering. Dit komt omdat de selector een stuk geheugen beschrijft en de adressen die het programma aanspreekt gebruikt worden voor een offset binnen dit geheugen. Dus zou je kunnen zeggen dat we sinds de 386 een 48bit processor hebben (16+32).

Wat vroeger gedaan werd bij de stap van 16 naar 32 bit is dat de omschrijving van het geheugen, waar de selector naar verwijst, bestaat uit een 32 bits adres terwijl er nog steeds gewerkt kan worden met de oude manier van adresseren nl. 16bits segment/selector + 16 bits offset. Ik zou me voor kunnen stellen dat als ze de omschrijving van het geheugen alleen hebben veranderd naar 64bit (iets wat alleen door het OS gebrukt wordt) dat ze dus de oude programma's nog steeds op dezelfde manier zouden kunnen starten binnen hun eigen max 4Gb adres ruimte. Het OS zou dan wel over meer dan 4Gb geheugen beschikken.

Een hercompilatie zal over het algemeen wel nuttig zijn maar meer ivm met het beter kunnen benutten van de gehele x86-64 bit architectuur en het kunnen aanspreken van grotere hoeveelheden geheugen en beter om kunnen gaan met grotere hoveelheden data(meer dan 4Gb). Maar volgens mij heb je het dan al over vrij specialistische dingen zoals b.v. videobewerking.

De IA64 architectuur is veel afhankelijker van het OS en de compiler. Ik ben benieuwd of dit het gaat halen in de consumenten markt. Die zal het niet zo gauw slikken dat al hun oude applicaties op hun nieuwe computer langzamer draaien als op de oude. Maar gode dit hangt er ook een beetje vanaf wat de software fabrikanten gaan doen.

[Ralph Smeets]

Een 64bits microprocessor heeft instructies die 64bits zijn. Dat wil zeggen de code voor de instructie bestaat uit 64bits. Daarnaast moet een 64bits microprocessor met 64bitjes tegelijkertijd kunnen werken. Dus 64bits registers.

De Pentium is dus een pseudo 64bits processor. Intern heeft hij een aantal 64bits registers, maar hij heeft geen instructies die 64bits in lengte zijn. Dus het is geen echte 64bits processor.

De IA64 architectuur is in feite ook geen echte 64bits processor architectuur, daar deze architectuur niet een maar drie instructies per opcode beschrijft. Ik heb me niet echt verdiept in de x86-64 architectuur, dus ik kan zo niet zeggen of dat een echte 64bits architectuur is, of een architectuur waarbij er simpel weg twee x86 instructies in een instructie zitten....

[Anoniem: 35845]

Een 64 bits processor heeft GEEN 64 bits instructies!
vb1 Itanium heeft een VLIW (Very Long Instruction Word) van 128 bits, die intern opgedeeld is in 3 41 bits instructies
vb2 x86 kent instructies met een VARIABELE lengte (intterrupt calls zijn slechts 2 bytes groot!)
"Het is een xx bit processor" zegt alleen maar iets over de grootte van de registers (general purpose registers, dus NIET MMX/SSE/FPU/etc). Dus ook niet de databus/adresbus breedte.

Hercompilatie is bij omschakelen van 32 op 64 bits ALTIJD nodig, maar bovendien moet vaak ook een groot deel ge-herprogrammeerd worden. C-integers zijn namelijk 4 bytes groot op een 32 bit proc, en 8 bytes op een 64-bitter. Ook de pointers naar de geheugenadressen worden twee keer zo groot. Dat dit tot ongewenst gedrag van een programma kan leiden, is iets wat iedere software developer je kan vertellen. Niet dat al deze zaken nieuw zijn, deze problemen zijn al eens eerder aan de orde geweest (16->32bit)

[Wouter Tinus]

Ik snap alleen niet dat ze gelijk die 64-bits proc op de thuismarkt richten.

Dat doen ze ook niet. ClawHammer is wel goedkoper dan SledgeHammer, maar de Athlon en Duron blijven nog een hele poos bestaan naast de Hammer chips.

En moet je dan apart gecompileerde programma's hebben wil je de snelheidswinst meepakken?

Waarschijnlijk niet, AMD wil dat de K8 gewoon de snelste x86 core ter wereld wordt.

Krijg je bij je Hammer OEM systeempje dan een 64bits WindowsXP versie of zo?

Verwacht dus geen Hammer OEM systeempjes. Maar inderdaad, Windows XP 64 bit edition ondersteunt x86-64.

[RG]

Maar inderdaad, Windows XP 64 bit edition ondersteunt x86-64.

Owja?? Dat wil dus zeggen dat in de 64 bits versie alle libraries 2 keer zijn opgenomen, want de instructieset van de Itanium en de Hammer zijn totaal verschillend. Nou is dit natuurlijk niet onmogelijk, en anders kun je altijd nog de standaard x86 versie nemen...

[apa]

Op zich is dat zeker te doen hoor:

de NT4 installatie CD-ROM bevatte ook verschillende installaties voor verschillende platformen (i386 natuurlijk, maar ook Alpha, PowerPC, ...). Het zou dus niet nieuw zijn. Bij *NIX OS'en zie je dat ook he: Linux kan je draaien op x86-32, Sun Sparc, RISC, Alpha, ...

NT was oorspronkelijk geschreven in een extreem gelaagde structuur: de HAL (Hardware Abstraction Layer) van NT was het enige dat systeem-afhankelijk was. Als je NT wou porten naar een ander platform, dan moest je enkel de HAL herschrijven. Deze HAL was in een eerste versie ongeveer 53 KBytes groot naar verluid.

Er waren natuurlijk wel wat problemen met deze extreem gelaagde structuur (vooral performantie; maar ook compatibiliteit met DirectX die rechtstreekse hardware-toegang vereist) waardoor het in latere versies bijgeschaafd werd: naast de HAL is nu ook (beperkt) rechtstreekse hardware toegang nodig.

XP is gebaseerd op Win2000, die op zich gebaseerd is op NT: er blijven dus ook in XP behoorlijke brokken NT over.

[durkagain]

Wat maakt dat nou uit?
Tis toch prachtige marketing? Wie wil nou geen 64 bit processor als consument. Of ie er ook echt wat aan heeft tsja... Maar dat geldt ook voor de vele mhz'en marketing. Het zegt allemaal nix, maar ziet er mooi (en snel) uit.
Denk maar hoe het ging met de N64.

edit:


oke wouter heeft ook gelijk, ze richten die proc niet gelijk op de consumenten markt. Maar aan de roadmaps te zien wil AMD toch redelijk gauw een clawhammer voor desktops introduceren..

[xiphoid]

Lekker duidelijk.

Ik had enkele vraagjes over hoe zoiets nou zou werken en welke voordelen aanpassingen hadden enzo, maar dit is wel tof om even door te nemen. Ik heb er verder helaas geen verstand van, maar heb het wel vergeleken met gelijksoortige posts op andere hardware sites van amd cpu's. Ik vraag me nu alleen af, als consument, welke voordelen heb ik ?
Twee cores is echt stoer trouwens, ik verbaas me er alleen over dat die cache altjid maar 256 blijft en nooit es 512 wordt. Hoe komt dit nou? Ik heb achter xeon servertjes gezeten die hadden 1mb zelfs en dat was echt tof om mee te werken.

[Anoniem: 32081]

De l2 cache voor dit ding gaat varieeren van 256k tot 2MB dus je kan gaan kiezen tussen klein en groot.
Een belangrijke reden voor kleine caches is onder andere de prijs. Veel cache = veel transistoren = veel oppervlak = hogere uitval bij productie = gewoon duur. Nu heb je in ieder geval dus de mogelijkheid om voor een typisch AMD prijsje (nou ja prijsje, maar ongetwijfeld goedkoper dan Intel - no flame intended) een 64 bitter aan te schaffen.

[TheGhostInc]

Toch zou jet verwachten met de yields van tegenwoordig dat de prijsstijging mee zou moeten vallen, een ook met de .13 micron technologie wordt de oppervlakte kleiner, dus de kans op fouten zou dan ook af moeten nemen.
Dan zou bv. Intel op die manier zijn eventuele overcapaciteit om kunnen zetten in een extra hoeveelheid cache on die.

* 786562 TheGhostInc

[Anoniem: 32049]

Dat is dus ook de reden dat DURON en CELERON een stuk goedkoper zijn, die hebben maar 64kB L2-cache.

[EaS]

Over die cache's, wat me ook nog opviel:

Een level 0 cache met een latency van maar 1 cycle !!

[D-RiSe]

level 2 cache tot 2 mb, onderaan het plaatje

[porn*]

Veel cache is meestal duurder om te maken omdat de yields dan veel lager worden. Kijk maar naar de Xeon's en vroeger de PPro's met veel cache.

[R Kuipers]

Als dit trucje met 2 cores werkt, werkt het ook met meerdere lijkt me. Dan kun je heel makkelijk de snelheid opschroeven: K8x2 K8x4 K8x8 ofzo.

Of denk ik nu te makkelijk?

[Ralph Smeets]

Zo gemakkelijk als dat gaat dat niet. Om ervoor te zorgen dat de twee cores bezig worden gehouden, is er een igenieus prefetch en branchprediction systeem bedacht. Ook wordt er heel wat in de instructie stroom gereorderd om zoveel hoe mogelijk instructies parallel uit te kunnen voeren. Maar ergens houdt het op. Waarom dacht je anders dat Intel de Itanium heeft uitgevonden?

Zonder hulp van een besturings systeem is het trouwens onmogelijk om threads op verschillende cores te laten draaien. Ik kan me een mechanisme voorstellen waarbij elke thread in z'n eigen virtual memory space draait. Maar dat betekent wel dat het besturings deze virtual memory space moet initialiseren in de adres translatie tabellen. Als je dan op de een of andere manier ervoor zou kunnen zorgen dat beide threads vanuit het L1 cache kunnen runnen....

[apa]

Zonder hulp van een besturings systeem is het trouwens onmogelijk om threads op verschillende cores te laten draaien

Dat klopt wel... Je hebt een OS nodig die multi-threading ondersteunt om threads ook maar te kunnen definiëren.

Bij de Hammer is het echter zo dat het niet meer het OS is die beslist op welke core (van 1 enkele CPU) de thread gaat draaien: het is de CPU zelf die dat beslist! Dus i.p.v. software-matige multithreading wordt bij de Hammer overgestapt op een vorm van hardwarematige multithreading (of is het nu "multiprocessing"?! ).

[apa]

Als dit trucje met 2 cores werkt, werkt het ook met meerdere lijkt me.

Zo simpel is dat niet. Zoals in het artikel gezegd wordt, is de x86 instructieset niet uiterst geschikt voor parallelisme: dit wellicht omdat parallelisme niet expliciet in de instructieset ondersteund wordt.

De Hammer duwt het parallelisme van x86 een eind verder dan waar het nu stond door allerhande erg doordachte truukjes (hoewel ik dit een te kleinerend woord vind). Toch kan je de performance niet zomaar 4x hoger maken door 4 cores op 1 chip te planten vergeleken met slechts 1 core op 1 chip. Je kan het vergelijken met een put graven: als je met 2 een put graaft, dan gaat het ongeveer (maar iets minder dan) 2 keer zo snel. Met 4 gaat het niet 4 keer zo snel als alleen, omdat je meer werk moet verrichten om de verschillende helpers te coördineren. Erg vereenvoudigd is dat ook zo bij CPU's.

EPIC staat voor Explicit Parallel Instruction C (ik weet niet meer waarvoor die C staat, sorry... maar dat maakt hier ff niet uit) In plaats van x86 in parallelisme te forceren gaat Intel met EPIC ervan uit dat het het programma is die bepaalt welke instructies parallel mogen worden uitgevoerd. Daar gaat men dus uit van de compiler om aan te duiden welke instructies parallel mogen worden uitgevoerd.

Zoals je in het artikel verder kan lezen kan de Hammer in sommige gevallen beter het parallelisme bepalen dan de compilers dat kunnen! Het *kan* dus zijn dat de Hammer in bepaalde gevallen efficiënter blijkt dan Itanium. Pas op: ik beweer zeker niet dat de Hammer beter zal presteren dan Itanium... beide architecturen zijn vrijwel geheel verschillend en dus niet rechtstreeks vergelijkbaar!

[Wouter Tinus]

Wordt wel heel erg groot / heet / duur allemaal, heel veel pinnetjes -> moeilijk moederbord bakken. Ik denk dat de nadelen groter zijn dan de voordelen.

[silentsnow]

Deze Hammers maken gebruik van NUMA. NUMA staat voor Non-Uniform Memory Access en dit nieuwe bussysteem zou in staat zijn om acht of meer processors met elkaar te verbinden. Door middel van LDT (Lightning Data Transport) controllers worden het geheugen en I/O bussen in een groep van processors aangesproken. Dus misschien is een 8proc systeem niet eens zo'n gek idee...

[procyon]

Ik denk dat je idd te makkelijk denkt, zoals je kan zien in de tekeningen delen de twee cores dezelfde L2 cache..
Het lijkt me sterk dat een l2 Cache verdeeld kan worden onder meer dan 2 cores..

Wel kan je spreken van een dual (4cores) en quad (8 cores) systeem, straks dan he?

Maar misschien heb je juist wel gelijk, de tijd zal het leren.

[RobT]

Interessante preview, met leuke speculaties.

Niet meer niet minder: speculaties.

Je kunt van een patent afleiden wat een bedrijf zou kunnen implementeren, wat ze werkelijk gaan doen is een tweede.

Wel heel erg goed afgeleid overigens, die Hans de Vries weet wel waar hij het over heeft (was al eerder gebleken met zijn preview over de K7).

De bandbreedte van de bus is veelbelovend, en ook de architectuur om een hogere ILP te halen.

Wat mij een beetje ontgaat is hoe AMD kan zeggen dat dit slechts zo'n 10% aan het aantal transistoren zal toevoegen van het K75/palomino ontwerp. Met al die extra parallelle pipes erin, zou ik eerder denken dat dat ding 50% toeneemt oid...

[Anoniem: 15714]

Kan ik deze nou straks(in de toekomst) ook op mijn asus A7V266 zetten??

[Wouter Tinus]

Nee, Claw en SledgeHammer gebruiken geen Socket A meer.

[xipetotec]

Uiteraard is een nieuwe processor niets zonder de chipset die erbij hoort en daar schrijft Hans de Vries het volgende over:

A number of ClawHammer chipsets have now been placed on the roadmaps. These chipsets use Hyper Transport to communicate with ClawHammer at a presumable speed of 800 MHz and a total bandwidth of 6.4 Giga Byte/s. Three times that of the current 266 MHz EV6 bus. Hyper Transport is said to scale to 1.6 Giga Hertz and 12.8 Giga Byte/s. The Memory Controller is still integrated on the Chipsets with support for 266 and 333 MHz DDR SDRAM. One should hope that these chipsets support 128 bit busses to memory to take advantage of the higher bandwidth.

Ik denk van niet, wat denk jij?

[Dennizz]

denk niet dat je chipset er mee om kan gaan, omdat ie o.a. 64 bit is etc

correct me if in wrong

[procyon]

HUH? De Itanium kan toch ook op een BX chipset?

[Dexter]

Ik zou eigenlijk best wel eens willen weten hoe zo'n patent er in het echt uit ziet. Wat er in beschreven staat etc... Lijkt me best interessant. Alleen een feature noemen is in het geval van dit artikel wel voldoende, maar hoe staat die dan omschreven in een patent?

Dex

[silentsnow]

Ik zou eigenlijk best wel eens willen weten hoe zo'n patent er in het echt uit ziet. Wat er in beschreven staat etc... Lijkt me best interessant. Alleen een feature noemen is in het geval van dit artikel wel voldoende, maar hoe staat die dan omschreven in een patent?

Dex

<a href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=3&f=G&l=50&co1=AND&d=ft00&s1='6,112,293'&OS=\\"6,112,293\\"&RS=\\"6,112,293\" target="_blank">hier</a> kan je er eentje vinden. Het gaat hier om het patent: Processor configured to generate lookahead results from operand collapse unit and for inhibiting receipt/execution of the first instruction based on the lookahead resul
Pics en zo kan je hier vinden.

Veel plezier, en ik hoor het wel over 3 jaar als je het hele artikel gelezen hebt

[Anoniem: 36255]

Deze K8 is echt een beest van een CPU. Ik ben erg benieuwd naar de normale gebruikstemperatuur...

De athlons zijn al snel op temperatuur (heet). Ik verwacht dat het bij deze CPU alleen maar heter wordt.

Deze CPU heeft echt een vette koeler nodig!

[silentsnow]

De Hammer gebruiken 40% minder energie dan de Athlon! Dus misschien zo je daaruit kunne concluderen dat ie minder warmte omzet. Aan de andere hand -> twee cores!!

[Cookie]

De Hammer gebruiken 40% minder energie dan de Athlon! Dus misschien zo je daaruit kunne concluderen dat ie minder warmte omzet. Aan de andere hand -> twee cores!!

Hehehe, is dat waar van die -40%? => Blijft 60% + 60% = 120%

[Anoniem: 29047]

Hehehe, is dat waar van die -40%? => Blijft 60% + 60% = 120%

Dat is dan toch maar 20% meer (terwijl 't 2 cores zijn

[SG]

Hammer komt uit op 0,13 SOI twee hitte verminderende productie processen verder dan de huidige palomino 0,18 -> 0,13 -> 0,13SOI

[Professor_Botje]

ik kan nergens terug vinden hoeveel Ghzen deze chip gaat produseren

en dat is voor het simpel vergelijk werk wel leuk natuurlijk

en 64Bit?
Win9x of 2k of XP?
32Bit dus...

of kan je Linux op 64bit draaien
XP moest IDD uitkomen voor 64bit maar dat laat zig ook nog w8ten denk ik

[Beaves]

Het is volgens dit artikel nog helemaal niet zeker of Windows XP de Hammer serie gaat ondersteunen.

Kleine copy/paste:

Microsoft werkt ook aan aparte 64 bit versies van Windows XP, één voor werkstations en één voor servers. Deze worden volgend jaar verwacht en het zijn de enige versies van Windows XP waarvan de Europese prijzen nog niet bekend zijn. Het is nog onbekend of deze 64 bit versie van Windows en de 64 bit versies van Windows XP de Clawhammer en Sledgehammer processoren van AMD (zullen) ondersteunen.

De Itanium wordt dus al wel ondersteund door Windows XP, maar de Hammer (nog?) niet, wat ik zeer vreemd vind.

De Hammer serie is ook voor thuisgebruik bedoeld en de Intanium serie nog lang niet, waardoor ik had verwacht dat MS in ieder geval een workstation versie zou afhebben, want wie gaat er nou een workstation met een Itanium uitrusten, die zijn juist voor de high-end servers bedoeld.

[RobT]

De Itanium wordt dus al wel ondersteund door Windows XP, maar de Hammer (nog?) niet, wat ik zeer vreemd vind.

Van de Itanium is allang silicium, de hammer is nog in een veel vroeger stadium.
Ik denk dat dat best zal komen, zodra blijkt dat er een markt voor de hammer is, zal MS ook daar geld willen/gaan verdienen..
Dat ze voor de Itanium WinXP al klaar hebben zegt verder alleen dat Intel en MS goeie vriendjes zijn, Intel wil natuurlijk ook dat men ziet dat hun processor nu al geaccepteerd is ed..

[Ralph Smeets]

AMD heeft voor klanten een platform dat met de Hammer x86-64 bits instructies compatible is. Dit platform is gebaseerd op de TransMeta Crusoe CPU. Door middel van code-morphing is the Hammer instructionset geimplementeerd. AMD biedt dit platform aan, aan iedereen die serieus software wil ontwikkelen voor de Hammer.

SuSE heeft dit platform gebruikt om hun Linux te testen. Ik kan me indenken dat Microsoft ook een TransMeta Crusoe 'Hammer' platform heeft om hun Windows XP x86-64 te testen.

[RG]

Linux ondersteund al een tijdje de Hammer 64 bits instructies. heeft AMD in samenwerking met SuSE gedaan. Zoveel aanpassing vergt dat gelukkig niet, want er zijn al een heleboel ports naar 64 bits processors (Alpha en SPARC, bijvoorbeeld) dus veel programma's zullen zo gecompileerd kunnen worden. En vergeet niet dat 32 bits x86 nog steeds gewoon werkt, dus kan het sowieso.

[Dennizz]

als je nou een dual sledgehammer neemt heb je een "bijna" quad proccessor systeempie

[apa]

Toch niet hoor... Eigenlijk is het systeem met 2 cores op 1 chip interessante. Om voordeel te halen uit een MP systeem (2 CPU's of meer) moeten de programma's speciaal geschreven worden; om voordeel te halen uit de 2 cores op 1 chip moeten de programma's niet herschreven worden! Alle programma's zullen er voordeel uit halen en het is het systeem zelf dat de multiprocessing bepaalt.

Je kan beiden dus zeker niet vergelijken.

[tweakerbee]

Hmm...dan zou het mogelijk moeten zijn een chipset te bouwen die ditzelfde truckje uithaalt, maar dan op een "echt" dual systeem. Heb je geen apart OS meer nodig.

Lekker windows 3.11 op je dual 2Ghz!

[Beaves]

De K8 chips zullen 64 bits processors worden die kunnen concureren met de Itanium van Intel,

Ja..en?, mijn P3 ook

FF serieus, ik denk niet dat de Hammer kan concureren met de Itanium en helemaal niet met de McKinley, die op gelijke kloksnelheid 1,7x zo snel is als een Itanium en daarnaast veel hoger te klokken is.

Waarom ik denk dat de Itanium serie sneller is/blijft als een x86-64 CPU? Omdat EPIC , de gebruikte instructieset) zo anders in elkaar zit waardoor de Itanium zeer snel is, zeker met grote databases aangezien EPIC speciaal ontwikkeld is om veel parallel uit te kunnen voeren. En aangezien Intel nog amper ervaring heeft met de compilers (het meest belangrijke aan EPIC), zal de Itanium serie steeds sneller worden.

De x86-64 instructie set is ook heel ingenieus, zeker de dubbele core in de SledgeHammer is zeer mooi, maar zal nooit de performance van een Itanium kunnen evenaren.

Alleen is de high-end markt waar de Itanium voor bedoeld is denk ik ook niet de markt waar AMD zijn pijlen op heeft gericht.

Ik denk dat ze meer op de markt waar 32-bit compability een vereiste is richten, waar een x86-64 CPU zeer sterk in is (op gelijke kloksnelheid 2x sneller als een huidige x86 core als we vroege benchmarks mogen geloven).

Aangezien de markten net onder de high-end markt zeer groot zijn, denk ik dat AMD het juiste heeft gedaan, ze hebben straks een CPU die zeer snel is, ook in x86 modus, want ook al hadden ze een concurent voor de Itanium willen maken, dat had AMD toch nooit gekund, het had te veel geld en tijd gekost.

Verder is het ook mooi voor ons als consument, we kunnen straks genieten van snelle x86 performance en we kunnen rustig op 64-bit software overgaan.

[RG]

Ben ik helemaal met je eens alleen Intel moet wel een beetje opschieten met hun compilers. Ze beginnen al aardig in de buurt te komen, maar ze zijn allerminst perfect.
Wat een voordeel is van het hele IA64 gebeuren (een van de belangrijkste reden dat ik het zo goed vind) is dat de hele architectuur vernieuwd is, dus geen gekloot meer met een BIOS zoals we dat nu hebben, geen ouwe bussen meer, geen genzeur meer met IRQs, geen ouwe zooi. Ze zijn compleet opnieuw begonnen met nieuwe standaarden met het oog op de toekomst en ik denk dat dat de sleutel gaat worden. Die ouwe x86 architectuur met aller wat er is bijbedacht is gewoon oud en inefficient. Zeg maar een zwaar opgevoerde lada, terwijl de Itanium een gloednieuwe ferrari in aanbouw is...

[Ralph Smeets]

Ehh, heel veel van de dingen die je daar op noemt zijn niet door Intel ontwikkeld, maar door IBM....

Gekloot met een BIOS zul je blijven hebben. Of denk je dat de processor zelf het OS op een harddisk kan vinden?

IRQ's zul je ook blijven houden. Of wil je device-drivers zo gaan schrijven dat het besturings systeem iedere miliseconde effe alle devices in je PC af moet gaan om te pollen of ze iets willen doen? Da's nou net het mooie van IRQ's, je stuurt data naar een FPU die effe later met een IRQ terug komt om te zeggen dat het resultaat klaar staat. Of je zegt tegen een timmer dat hij je over 1msec moet waarschuwen. Hoef je niet zelf te wachten. Het zijn trouwens niet de IRQ's die voor problemen zorgen, maar de programeurs van de drivers die deze IRQ's afhandelen.

En over die Lada-Ferari vergelijking.... Tja, probeer maar eens een nuttig werkje te vinden voor een Ferari. Boodschappen doen bijvoorbeeld.... Koffer? Koffer? Wat is dat?

Dus als je je gaat ontdoen van alles wat er op dit moment beschikbaar is voor het PC2001 platform om ze te vervangen door dingen voor het IA64 platform, dan zou je nog wel eens bedroggen uit kunnen komen. Snelle proc maar je kunt er niks mee.

[apa]

Ik weet niet of je dat zo kunt stellen hoor. De IO bus, memory bus; etc. heeft uiteindelijk niks te maken met de CPU die je erop plugt. Het is wel waar dat Intel (en andere bedrijven ook!) bezig is met ontwikkelingen rond die andere aspecten, maar ze zijn niet specifiek gericht op IA64 he!

3GIO zal bv. uitkomen vóór IA64 op de mainstream. Zelfde verhaal voor Serial-ATA overigens.

IRQ's zullen ook blijven bestaan: al zal je er minder last van hebben dankzij verbeterde P&P (in win2k heb je bv. al veel minder last van je IRQ's; hoewel het zeker niet 100% achter de rug is).

En wat bedoel je dat je geen BIOS-gekloot meer zult hebben? Een IA64 CPU zal zeker en vast ook op een mobo geplugd worden en dat mobo zal zeker en vast ook een BIOS nodig hebben hoor! De BIOS bevat o.m. bug-fixes (microcode updates) voor de CPU die opgeladen worden in de CPU. Als je geen BIOS meer zou hebben, dan kan je bug-fixes dus niet meer opladen in je CPU en kan je ze bijgevolg ook niet meer fixen... of zou dat dan anders gaan gebeuren?!