Volgens mij zijn er grote misverstanden over 64-bits CPU's. Een 64-bits CPU is intrinsiek
niets sneller dan een 32 bits CPU. Het enige voordeel van een 64 bits CPU is een eventuele grotere preciesie en een grotere adresruimte.
Meer niet.
Het voordeel van 64 bits CPU's is dan ook voornamelijk van een marketingtechnische aard. D.w.z. totdat grote hoeveelheden geheugen [>4Gb] gangbaarbaar worden, dan wordt het wel prettig een 64 bits CPU te hebben. Maar tot die tijd heb je geen ene flikker aan een 64 bits CPU. Wel geil, maar niet sneller.
Dat een Hammer sneller zal zijn dan een XP geloof ik best, maar dat heeft met allerlei optimalisaties te maken
die los staan van het 64 bits zijn. Op dezelfde wijze had AMD de XP sneller kunnen maken. Het 64 bits maken van een XP processor stelt ook niet zo heel veel voor. Grotere registers, 64 bits ALU's, etc. No biggie. Kost ook slechts een paar procent extra die oppervlak.
Ik ben een fan van voorruitgang, en de tijd van 64 bits CPU's mag wel eens aanbreken ja. MAar sneller wordt het er niet van. Sommigen schijnen te denken dat omdat 64 twee keer zoveel is als 32, een 64 bits CPU dan ook wel 2 keer zoveel werk kan verzetten. Heeft het niets mee te maken. Zo, en nu stop ik.
justice strike:
Tuurlijk, als je met 64 bits FPs of INTs werkt, dan heb je er wat aan. Maar ik denk dat nog niet 0,0000001% van alle berekeningen die jouw CPU uitvoerd van dat type zijn... Wat denk je zelf? Daar heb je dus niet zoveel aan.
En wat AMD allemaal zegt... die zeggen wel meer. Ook AMD doet aan marketing.
Ik zei al dat de Hammer heus wel sneller zal zijn (klok voor klok) dan de XP. Dat zal alleen weinig tot niets met de 64 bits aard van de Hammer te maken hebben.
gast amd zegt toch zelf dat ze een 20% performance winst verwachten van het hercompileren van de code met een 64 bit's compiler tov 32 bit's code op dezelfde processor. Hoezo heeft dit dan NIET te maken met het feit dat de hammer 64 bit's is? ik denk echt niet dat amd zulke loze statements maakt als het niet waar is.
je kan wel degelijk performance winst verwachten. immers als je veel met 64 bit getallen werkt zal het sneller verwerkt kunnen worden met een 64 bit processor dan met een 32 bit's processor (waar je allemaal fratsen moet uithalen zoalse het splitsen van getallen) het voordeel van 64 bit's is niet alleen dat je meer geheugen kan aanspreken. maar er zijn ook andere voordelen!! en daar zit dus ook bij dat code sneller KAN draaien op 64 bit's dan op 32 bit's...
Een processor draait native altijd sneller, dit komt doordat "extra" stappen voor de compatibiliteitsmode dan kunnen overgeslagen worden.
Een voorbeeld: als je in een 64-bit register een 32 bit getal steekt moeten er twee extra stappen uitgevoerd worden als je ermee gaat rekenen:
1) voor de berekening moet de signbit moet doorgekopieert worden
2) na de berekingen moet de overflow extra gecontrolleerd worden
Waarschijnlijk heeft AMD deze stappen sterk geoptimaliseerd, maar ze geven toch toe dat native op 64-bit het sneller gaat.
Ik veronderstel dat AMD met hun optimalisaties ervoor gezorgd hebben dat het performancesaldo voor 32-bit code toch nog positief is, maw dat de efficiëntiewinst hoger is dan de 32-bit compatibiliteitsoverhead.
de 32 bit's code is native, het is niet alsof ze een processor emuleren ofzo (zoals de itanium dat moet doen) het is x86-64 extensie op de x86 architectuur, wat dus betekent dat hij 32 ook in zijn architectuur moet kunnen draaien, alsmede 16 bit code.
Ik denk niet dat er een performance verlies was bij het overstappen van 16 naar 32 bit's processoren (wel een performance winst), hoezo is dat dan wel het geval bij overstappen van 32 naar 64? dat zou toch onlogisch zijn?
//edit
overigens verdubbelt het aantal registers in 32 bits omdat de registers dan door tweeen gesplitst worden (dacht ik in iedergeval)
Netto is er inderdaad altijd voor gezorgd geweest dat er winst is, dat spreek ik niet tegen. Maar één processor twee gezichten geven met één core gaat niet zomaar en heeft AMD ook niet gedaan anders zou 64-bit code niet sneller zijn dan 32-bit code, dan zouden ze even snel zijn. Ik bedoel dus dat de IPC in 64-bit mode lager is dan in 32-bit mode. Wat mij betreft is de Hammer dus native 64-bit en semi-native 32-bit.
16-bit en 32-bit kun je in deze kwestie niet vergelijken, omdat enerzijds 16-bit singletasked was en 32-bit multitasked en anderzijds 32-bit cpu's sneller en efficienter waren gemaakt dan hun 16-bit voorgangers.
Maar één processor twee gezichten geven met één core gaat niet zomaar en heeft AMD ook niet gedaan anders zou 64-bit code niet sneller zijn dan 32-bit code, dan zouden ze even snel zijn. Ik bedoel dus dat de IPC in 64-bit mode lager is dan in 32-bit mode. Wat mij betreft is de Hammer dus native 64-bit en semi-native 32-bit.
De x86-64 ISA heeft het dubbele aantal general purpose registers als 32-bit x86. Deze extra registers zijn uitsluitend beschikbaar in de zogeheten 64-bit long mode (dwz: native 64-bit applicaties, de Hammer kan ook 32-bit applicaties in 64-bit legacy mode draaien zodat het mogelijk is om 32-bit software op een 64-bit OS te draaien). Die extra registers zorgen voor de winst omdat er minder cachebenaderingen nodig zijn. De Hammer is niet trager in 32-bit mode omdat-ie geen native 32-bit applicaties zou kunnen draaien.
Het enige voordeel van een 64 bits CPU is een eventuele grotere preciesie en een grotere adresruimte. Meer niet.
Dat klopt niet, registers zijn ook 64 bits breed wat in sommige gevallen veel kan schelen. B.v. voor RC5, voor RC5-64 had je 2 registers nodig, met 64 bit registers slechts één. Voor RC5-72 gaat dat van 3 naar 2. Vergelijk waarom de G4 met Altivec ca. 4x zo snel is per klok: 128 bit brede registers.
Daarbij komt ook nog dat de Hammer het aantal registers verdubbelt.
Tuurlijk, als je met 64 bits FPs of INTs werkt, dan heb je er wat aan. Maar ik denk dat nog niet 0,0000001% van alle berekeningen die jouw CPU uitvoerd van dat type zijn...
Wel als je 24/7 een of andere distributed client draait zoals RC5, in dat geval is het in absolute getallen zelfs nagenoeg 100% dat soort type berekeningen
Je zult er natuurlijk minder aan hebben als je de client pauseert voor een spelletje of iets dergelijks.
In de toekomst zullen dit soort projecten steeds meer gemeengoed worden, dus je hebt er wel degelijk wat aan. Er zijn nog meer toepassingen die er baat bij hebben zoals emulatie, de auteur van Amithlon b.v. (to the metal Amiga emulator) heeft gezegd dat Hammer een groot verschil zal gaan maken in emulatiesnelheid, puur door 64 bit omdat er veel met caching wordt gewerkt bij processoremulatie en verdubbeling van registerruimte op zich al een tastbare winst oplevert (zeker als de geëmuleerde CPU meer registers heeft), maar ook omdat er minder overhead is bij het uitlezen van een register, je krijgt gelijk de inhoud van 2 terug.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
HTT staat echter nog in de kinderschoenen, en het moet nog blijken hoe effectiek HTT geïmplementeerd zal gaan worden in de praktijk. Softwareoptimalisaties voor SSE/SSE2 zijn inmiddels meer en meer doorgevoerd en werpen al lang hun vruchten af, zoals tegenwoordig 3ds Max benchmarks bijvoorbeeld laten zien, voorheen het domein van de K7 processor met een 35 procent betere FPU dan de oude Pentium 4 Willamette. Inmiddels heeft de Pentium 4 daarin de koppositie overgenomen, mede door optimalisatie van de software. Daarnaast speelt ook het OS mee. Windows XP Home en Professional zullen HTT ondersteunen. Daarnaast doen er verhalen de ronde dat Intel misschien een tooltje uit zou kunnen brengen, wat er voor zorgt dat andere software tijdens installatie wordt aangepast aan de aanwezigheid van HTT. Dat laatste is echter tot nu toe slechts speculatie. Minder speculatief is dat HTT door Intel nog verder doorontwikkeld zal worden, en dat toekomstige Pentium 4 generaties, zoals de Prescott (desktop) en Nocona (Xeon) in 2003, deze doorontwikkelingen zullen bezitten.
15:56
15:09
Door 
, dus als je gemiddeld 1% neemt is je 134% precies 34% te optimistisch. Dit alles in het ideale geval voor beide architecturen natuurlijk.
