Intel publiceert benchmarks 32- vs. 64-bits Nocona

Intel heeft een aantal benchmarks gepubliceerd waarin het verschil in snelheid tussen de 32- en de 64-bits mode van de Nocona wordt geïllustreerd. Hiervoor werd er gebruik gemaakt van een systeem dat is opgebouwd rondom een moederbord met de E7520-chipset en een 3,6GHz Xeon Nocona-processor. In 32-bits mode werd dit moederbord voorzien van 4GB aan geheugen, terwijl in 64-bits mode het moederbord werd voorzien van 8GB aan geheugen. In eerste instantie lijkt dit dus geen eerlijke vergelijking, daar het 64-bits platform het voordeel van meer geheugen heeft. Vergeet echter niet dat er in 32-bits mode maximaal 4GB aan geheugen kan worden geadresseerd. Het grote voordeel van 64-bits is dan ook de mogelijkheid om meer dan 4GB aan geheugen te adresseren. De benchmarks van Intel lijken er dus vooral op gericht om dit verschil aan te tonen.

De eerste benchmark van Intel laat zien dat er complexere problemen met EM64T aangeschakeld kunnen worden opgelost. Dankzij het extra geheugen waarvan het EM64T-platform profiteert kan een grotere matrix worden opgelost dan in 32-bits mode. Hoewel er nog geen 64-bits versie van Maya is, blijkt deze applicatie toch 8% sneller te werken als er gebruik wordt gemaakt van Windows XP 64-bits Edition. Het bouwen van een nieuwe Linux-kernel gaat 13% sneller met EM64T aangeschakeld en modelleren in de 64-bits versie van Amber gaat maar liefst 32% sneller dan in de 32-bits versie. De combinatie van 64-bits besturingssysteem en HyperThreading blijkt ook een stuk efficiënter dan de combinatie van een 32-bits besturingssysteem met HyperThreading. Dit komt waarschijnlijk omdat er meer registers beschikbaar zijn in 64-bits mode, waardoor er efficiënter gebruik kan worden gemaakt van HyperThreading.

Deze eerste benchmarks van Intel zelf zijn dus veelbelovend. Toch moet er ook niet teveel waarde aan worden gehecht, daar het hier vooral om de marketing van de Xeon Nocona draait. Wat wel interessant is, is het feit dat er in sommige benchmarks gebruik is gemaakt van Windows XP 64-bits Edition. Dit zou kunnen betekenen dat Microsoft vergevorderd is met de ondersteuning van EM64T.

Reacties (36)

[Verwijderd]

Soms snap ik niet hoe jullie aan informatie op de frontpage komen, dit keer was 't echter te bont, heb maar geregistreerd. De uitleg voor dit commentaar:

> Vergeet echter niet dat er in 32-bits mode maar maximaal 4GB aan geheugen kan worden geadresseerd

Wat bullshit is. In 32-bit modus kun je nog steeds 64GB geheugen benaderen. Dit kunnen processors vanaf de Pentium Pro (Pentium II) en AMD Athlon model 1 ook al, misschien zelfs eerdere AMDs. Het snufje, dat ook de 64-bits processors nodig hebben hiervoor, heet PAE (Page Addressing Extension). Hiermee kan zo'n besturingssysteem tot 64GB bijhouden en benaderen, echter niet alles tegelijk. Op een 64-bit computer kan dit ook alleen als zowel het programma als het besturingssysteem 64-bits-modus ondersteunen. Ze kunnen dan tot 256TB benaderen (262144 GB), het besturingssysteem zelfs tot 4PB (4194304 GB). Mits je zoveel hebt natuurlijk

> Dankzij het extra geheugen waarvan het EM64T-platform profiteert kan een grotere matrix worden opgelost dan in 32-bits mode. Hoewel er nog geen 64-bits versie van Maya is, blijkt deze applicatie toch 8% sneller te werken als er gebruik wordt gemaakt van Windows XP 64-bits Edition.

Nou... nee dus, er kan geen grotere matrix worden opgelost. Kleine zijopmerking, in Maya wordt heel weinig met grote matrices gerekend, de laatste keer dat ik keek zelfs niet met grotere dan 4x4. Dit kan een 8-bit processor nog zonder problemen.

De versnelling komt echter van het hebben van meer geheugen. Maya is een geheugenintensief stukje software, en als het gebruik kan maken van al het geheugen dat er beschikbaar kan zijn (de maximale 4GB) plus nog een disk cache voor waarschijnlijk het gehele project (de andere 4GB) gaat het aanzienlijk sneller dan als je de disk cache kleiner zet. Ook zijn er gegarandeerd normale architecturele en microcode optimalisaties doorgevoerd waardoor ie sowieso sneller is dan de vorige versie.

> Dit komt waarschijnlijk omdat er meer registers beschikbaar zijn in 64-bits mode, waardoor er efficiënter gebruik kan worden gemaakt van HyperThreading.

Hebben weinig met elkaar te maken. De registers op een X86 computer zijn sowieso al een stuk meer dan er beschikbaar zijn (zeg een stuk of 128 op een pentium I), door middel van register renaming en een paar andere optimalisaties is het mogelijk de "actieve set" van registers te mappen naar slechts 8 van deze registers, waardoor de vertragingen van de registers er niet veel meer toe doen. Er zijn zelfs speciale instructie-niveau optimalisaties waarmee snelheden nog hoger opgevoerd kunnen worden, en waarmee false dependencies opgelost kunnen worden (zie ook informatie over XCHG, XOR en dergelijke op de Intel site, Intel Architecture Software Developers Manual deel 2A en 2B).


Hyperthreading gaat waarschijnlijk sneller omdat in Winxp-64 een aantal hersendode vergissingen van Intel worden hersteld. In het Intel document over multiprocessing, samen met die over Operating System Development, wordt uitgelegd dat een aantal standaardmechanieken expliciet niet mogen worden gebruikt, omdat de cache niet is ontworpen om daadwerkelijk op zo'n systeem te werken. De cache werkt als een 2-way cache, en als allebei de processors hun stack alignen op dezelfde cache line wordt er bij elke data access op die lijn (kans van ongeveer 1 op 1024) een cache-line flush gedaan (drie dus, beide stacks 1x en de data 1x). Dit is slecht voor de performance. Intel heeft nog een aantal andere dingen er in gedaan, waardoor het logisch is dat de hyperthreading beter werkt op de 64-bit processors, met software die expliciet dingen doet voor hyperthreading.

> Dit zou kunnen betekenen dat Microsoft vergevorderd is met de ondersteuning van EM64T.

Vertaling naar reele termen: de AMD64 ondersteuning heeft afgeslankt tot de Intel-implementatie het ook nog deed. in EM64T zijn een 5tal belangrijke zaken uit AMD64 weggelaten, waaronder SYSCALL. Het aanpassen van de code duurt niet lang, maar is wel een monnikenwerk, het doet het allemaal al en omdat Intel geen licentiekosten wil mag je alles dubbel doen.

De groeten, DasCandy (OS developer).

[XyritZz]

het doet het allemaal al en omdat Intel geen licentiekosten wil mag je alles dubbel doen.

Dat is onzin, want AMD betaalt ook geen licentiekosten aan Intel voor het gebruik van x86 architectuur. Terwijl Intel hier patent op heeft. Intel en AMD mogen zonder te betalen elkaars technieken gebruiken, omdat ze dat zo hebben afgesproken.

Kan de bron van tweakers ff niet vinden, maar het heeft er een keer op gestaan volgens mij.

[Clueless]

Zo ver als ik mij kan herinneren (kan het verkeerd hebben) is het zo dat AMD en Intel een overeenkomst hebben waarin staat dat AMD de x86-basis mag gebruiken op voorwaarde dat alles wat ze op dat platform ontwikkelen aan x86 ook door Intel mag worden gebruikt maar Intel daar in principe niets voor hoeft terug te doen. Dit gaf ze dus ook de mogelijkheid om de AMD64-instructies aan te passen / te kopieren (geef het beestje een naampje) voor eigen gebruik.

Dat ze bijvoorbeeld later de MMX & SSE-instructies aan AMD hebben vrijgegeven als aanvulling op de x86-instructieset is een ander verhaal, maar naar mijn waren ze niet verplicht dit te doen....

just my 0,02

[Verwijderd]

Dat is onzin, want AMD betaalt ook geen licentiekosten aan Intel voor het gebruik van x86 architectuur. Terwijl Intel hier patent op heeft. Intel en AMD mogen zonder te betalen elkaars technieken gebruiken, omdat ze dat zo hebben afgesproken.

Ik denk dat het X86 patent eerder zou gaan over een patentenruil, niet zozeer een overeenkomst waarmee beiden van andermans patenten gebruik kan maken. Heb je anders een betere verklaring voor het niet ondersteunen van een aantal hoekstenen van AMD64, en het uitvinden van een incompatible techniek die essentieel hetzelfde is? Of nog erger, waarom zowel SYSENTER als SYSCALL bestaan, op beide in 32-bit mode worden ondersteund, en SYSENTER de enige is op EM64T, en SYSCALL de enige op AMD64? Mijn enige antwoord is een patentenprobleem.

[Ralph Smeets]

Soms snap ik niet hoe jullie aan informatie op de frontpage komen, dit keer was 't echter te bont, heb maar geregistreerd. De uitleg voor dit commentaar:

Er wordt door Tweakers.net actief gezocht naar nieuws, al dan niet geholpen door lezers die nieuws insturen. De informatie op Intel is erg karig, dus dan wordt het soms moeilijk. Niet iedereen ontwerpt besturingssystemen ( Alhoewel ik wel aan het ontwerp van twee 64-bits processor -de CM10 en de SuperH 5- heb meegeholpen. )

Wat bullshit is. In 32-bit modus kun je nog steeds 64GB geheugen benaderen. Dit kunnen processors vanaf de Pentium Pro (Pentium II) en AMD Athlon model 1 ook al, misschien zelfs eerdere AMDs. Het snufje, dat ook de 64-bits processors nodig hebben hiervoor, heet PAE (Page Addressing Extension). Hiermee kan zo'n besturingssysteem tot 64GB bijhouden en benaderen, echter niet alles tegelijk. Op een 64-bit computer kan dit ook alleen als zowel het programma als het besturingssysteem 64-bits-modus ondersteunen. Ze kunnen dan tot 256TB benaderen (262144 GB), het besturingssysteem zelfs tot 4PB (4194304 GB). Mits je zoveel hebt natuurlijk

Klopt, echter een 32-bits applicatie kan echter maar 4GB aan geheugen adresseren dat het krijg aangewezen door het OS die maximaal 64GB met PAE tot beschikking heeft. Een 64-bits applicatie kan echter meer dan 4GB geheugen adresseren.

Voor de rest, bedankt voor de info, we zullen er aan denken in een volgens artikel.

[aTmosh]

Klopt, echter een 32-bits applicatie kan echter maar 4GB aan geheugen adresseren dat het krijg aangewezen door het OS die maximaal 64GB met PAE tot beschikking heeft.

In de Intel implementatie voor Nocona dan. Voor AMD64 geldt 40 bits, dus 1 Terabyte.

[feuniks]

In 32-bit modus kun je nog steeds 64GB geheugen benaderen

Klopt. Alleen kan Windows in 32 bit mdus slechts 4 GB aan. Effectief kan dus met de huidige generatie Windows XP slechts 4 GB gebruikt worden, ook al vul je tot 64 GB...

[Verwijderd]

Zelfs windows snapt nog wat PAE is. De echte 32-bits kernel (de NT kernel, 4.0/5.0/5.1) kan overweg met meer dan 4GB geheugen, echter, Microsoft is niet gek. Ze vragen vanzelfsprekend meer geld voor het ondersteunen hiervan. Het is in het OS ook iets lastiger te programmeren.

Windows 2000 data center edition is een van de Windowses die meer dan 4GB kan ondersteunen.

Citaat van microsoft.com:

Large Memory Needs Microsoft SQL Server 2000 Enterprise Edition (64-bit) is one example of an application that can make use of the increased memory space of 64-bit Windows Server 2003 (up to 4TB Windows 2000 Datacenter only supports up to 64GB)

Bron: www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/c lustering/newclust.mspx

Een zijopmerking is nog van belang hierbij, de PCI adresruimte en de hardwareadresruimte van de PC/XT (A0000-FFFFF en E0000000-FFFFFFFF) zitten hier ook in, en deze worden, als het goed is (met MTRR) ingesteld op non-geheugen, waardoor op de 4GB tot 512MB (plus 320KB, maar dat is niet echt meer van belang) verloren gaat. Op 8GB houd je dit, behalve als je een AMD64 hebt. De AMD64's kunnen dit geheugen anders mappen dan van 0 tot X, zodat dit gat overgeslagen kan worden. Er is helaas nog geen BIOS die dit ondersteunt (heb daar bevestiging van vanaf C'T magazine, die claimden dat het helemaal niet mogelijk was).

[Olaf van der Spek]

registers op een X86 computer zijn sowieso al een stuk meer dan er beschikbaar zijn (zeg een stuk of 128 op een pentium I), door middel van register renaming en een paar andere optimalisaties is het mogelijk de "actieve set" van registers te mappen naar slechts 8 van deze registers, waardoor de vertragingen van de registers er niet veel meer toe doen.

Maar echt handig is het niet natuurlijk. Je hebt meer 'loads' en 'stores', dus je code is langer en toch minder efficient.

[2bme]

Natuurlijk is het voordeel dat de 64bits meer geheugen kan adresseren. Maar waarom doen ze dan niet 3 tests:
32bit met 4 Gig
64bit met 4 Gig
64bit met 8 Gig
Want als het enige voordeel moet komen uit het kunnen adresseren van meer geheugen....

Wat wel interessant is, is het feit dat er in sommige benchmarks gebruik is gemaakt van Windows XP 64-bits Edition

Dat kon je toch op je vingers natellen. Amd heeft al zolang de 64 bit klaar en dan wordt WinXP64 alsmaar uitgesteld (alleen een Beta, en dat vertrouw je niet echt in een bedrijfsomgeving) en nu Intel klaar is met zijn 64 bit, dan zal de 64 bits editie wel zo uitkomen....

[hardwareaddict]

Windows heeft verschillende x86-64 producten onlangs nog stevig naar 2005+ uitgesteld.

[dasiro]

als je nog niet doorhebt dat het uitstel van microsoft voor een groot deel te wijten is aan de achterstand van intel op amd op vlak van 64-bits cpu`s dan moet je toch serieuze oogkleppen ophebben hoor.

[Verwijderd]

Zijn 64 bits nu echt zoveel sneller dan 32 ?
Ik bedoel, je applicaties (of games) moeten toch ook aangepast aan die 64-bits processors vooraleer je echt veel verschil merkt

[Standeman]

64bits is inderdaad een stuk sneller dan 32 bits.. De processoren hebben grotere registers en kunnen dus "2x" zoveel aan in 1 clockcycle...


En ja.. je software moet het ook ondersteunen... voor 64 bit procs gecompiled zijn..

[bolleh]

onzin. een 64 bit proc is helemaal niet vanzelfsprekend sneller als een 32 bit proc
het aantal bits heeft nix, maar dan ook helemaal nix met de snelheid te maken, tuurlijk in bepaalde situaties maar dan heb je al 2 variabelen ipv 1, immers de situatie en de proc

32 en 64 bit hebben zo zn eigen voordelen, en de voordelen voor consumenten zijn nu eigenlijk nihil, je hebt er nix aan, en dat zal ook nog wel een tijdje blijven.

verder kan een 64 bit architectuur best 2x zo snel zijn als een 32 bit architectuur maar enkel en alleen onder perfecte omstandigheden. het feit alleen al dat x86-64 een doorontwikkeling is van x86-32 maakt dat eigenlijk al onmogelijk, de huidige architectuur heeft een hoop oude rommel in zich wat voor veel slowdown zorgt, om nog maar niet te spreken over gare programmas en slechte code

er gaat momenteel veel te veel computerkracht verloren aan deze 2 dingen. daarom zie ik ook meer in IA64 voor in de verdere toekomst dan x86-64, ergens houd het doorontwikkelen gewoon op, dan heeft het geen nut meer

[Luxx]

De processoren hebben grotere registers en kunnen dus "2x" zoveel aan in 1 clockcycle...

Deze bewering vind ik heel heel gedurfd. Als je rekent met 32bit of kleinere getallen is een 64 bits processor NIET sneller. De overgebleven bits kunnen niet zomaar ergens anders voor gebruikt worden. Alleen in berekeningen waar 32bits nauwkeurigheid te weinig is (en dat zijn er bij standaard desktop werk bijna geen) is 64 bits echt sneller. In het zware werk, met grote getallen is 64 bits wel veel sneller dan 32 bits, omdat die grote getallen dus in een kloktik verwerkt kunnen worden.

Om te voorkomen dat AMD64 een flop zou worden, en omdat AMD de x86 toch overhoop aan het halen was, hebben ze niet alleen de registers vergroot, maar ook het aantal verdubbeld. Het kleine aantal mogelijke registers was altijd al een zwak punt van X86, en daardoor neemt de snelheid dus flink toe. Op zich heeft dit dus niet zo veel met 64bits te maken.

[Japs]

Beweren dat 64bit 2x zoveel kan doen per kloktik is inderdaad erg kort door de bocht. Maar puur het feit dat de registers 2x zo groot zijn kan wel degelijk snellere 32 bits berekeningen opleveren.

Ter illustratie wat pseudo-assembly:
Als je 2 32 bits integers wil inverteren:

32 bits CPU:
MOVE getal1 TO REG_A(32bit)
INVERT REG_A(32bit)
MOVE REG_A(32bit) TO getal1
MOVE getal2 TO REG_A(32bit)
INVERT REG_A(32bit)
MOVE REG_A(32bit) TO getal2

64 bits CPU:
MOVE getal1 TO REG_AL(lower 32bit of 64bit)
MOVE getal2 TO REG_AH(upper 32bit of 64bit)
INVERT REGA(64bit)
MOVE REG_AL(lower 32bit of 64bit) TO getal1
MOVE REG_AH(upper 32bit of 64bit) TO getal2

Dat scheelt dus een invert operatie.
Dus aangenomen dat de 64-bitter een 64-bits invert even snel doet als een 32-bitter een 32-bits invert, en de 64-bitter de upper en lower delen van een 64-bit register appart kan aanspreken; zal de 64 bitter in dit geval sneller zijn.
Ik denk dat de compilers voor de 64-bitters dit soort trucjes toepassen om ook 32-bits code te optimaliseren.

[loodgieter]

op dit moment is er dan nog niet zo`n goede driver en software ondersteuning, maar dit komt steeds beter op gang.
bedrijven zoals Nvidia en Ati 3Com ect zijn al volop bezig zoveel mogelijk te ondersteunen.

Hier is ene lijstje met hard drivers die al worden ondersteund door de fabrikanten.

dit was toch ook zo met de overstap naar 32-Bits

[Countess]

64bits zijn onderander sneller als je met getallen werkt die 64bit groot zijn
in een 32bit cpu moet je die opsplitsen in 2 delen en die appart door de CPU gooien waardoor het 2 keer zo lang duurt voor hij klaar is.

maar de 64bit's zijn niet de enige reden dat 64bit CPU's sneller zijn in veel taken als 32bit CPU's
AMD (en daardoor intel om compatible te blijven) heeft de X86 structuur aangepast met de overstap naar 64bit om zo een aantal ingebouwde bottleneks in de X86 argitectuur op te lossen(en waarom niet, de software moet toch aangepast worden voor 64bit en die 64bit software hoeft niet meer te te werken op "oude" 32bit CPU's).
de registers zoals hierboven genoemd door Standerman. ze zijn niet alleen groter, maar er zijn er nu ook meer, wat eerst niet mogenlijk was vanwegen de ingebouwde limitaties van x86.
zo zijn er nog veel meer van zulke aanpassingen.

[machiel]

Ik meen me toch te herinneren dat Intel helemaal geen noodzaak zag voor 64 bit CPU's op werkstations. Grappig dat AMD die mening heeft veranderd en Intel nu meedoet met de 64-bit hype

[Digistorm]

Intel doet niet mee aan de hype, Intel heeft zich uit de naad gewerkt om ook zsm een 64 bit processor te maken, en is er tegelijk in geslaagd om Microsoft op te houden... nu is Intel klaar, en verrassing: Windows 64 bit komt er ook ineens aan. Goh....

[Frank-L]

Intel heeft al een paar jaar een 64-bits processor.

[Metal Baron]

Een op z'n zachts gezegd redelijk prijzige ja. Je hebt gelijk, maar het punt leek me wel duidelijk.

[Countess]

intel heeft helemaal niks te maken met het oponthoud bij MS
intel zegt dat, MS zegt dat en zelfs AMD zegt dat.

[nAFutro]

Nocona is eigenlijk bedoeld als server CPU, wat freaks en bedrijven met te veel geld zullen deze misschien als werkstation cpu gaan gebruiken

[Clueless]

Wil hier even op ingaan door te zeggen dat ze ook de Prescott met EM64T aan hebben gereleased dus die vlieger gaat dan niet op.

Wat wel interessant is blijft is het feit dat Intel eigenlijk gedwongen is door AMD ook in de 64bits-extenties te stappen. Als het aan Intel had gelegen hadden we deze nog helemaal niet omdat deze het eigen Itanium-platform (IA64) in gevaar brengen.

Ben eigenlijk wel benieuwd hoe de verhoudingen nu komen te liggen. De verschillen tussen AMD en Intel waren al klein maar of nu de balans met Intel's 64bitters nog vlakker wordt getrokken moet nog blijken. Wordt tijd voor een leuke vergelijking tussen de processors....

[Verwijderd]

vergeet niet dat de Intel I-Tanium al lang een 64 Bit CPU is ... en een echte 64 Bit CPU the one and only eigenlijk ...

[ymmv]

Ik dacht dat Intel dezelfde 64-bit extensies heeft als AMD. Dan hoeft Microsoft maar 1 64 bit OS op de markt te brengen en snap ik een zin als "Dit zou kunnen betekenen dat Microsoft vergevorderd is met de ondersteuning van EM64T" niet helemaal.

[hardwareaddict]

Dat klopt helemaal.

EM64T is in principe x86-64 met 1 instructie extra. Die instructie gaat straks door intel gebruikt worden om compilers te bakken die dan code genereren met erin die ene instructie (die verder nietszeggend is) die dan heel veel sneller op de testsets gaat zijn omdat het 64 bits is en met name 16 registers (versus nu 8 in x86).

Natuurlijk kan de opteron dan die code niet legaal draaien (natuurlijk kun je gewoon die instructie eruit gooien en dan werkt het maar dat mag dus helaas legaal niet) en intel kan dan victorie claimen.

Dat is hoe ik 't me voorstel waarom ze die instructie eraan toegevoegd hebben.

[EaS]

EM64T is in principe x86-64 met 1 instructie extra.

Eigenlijk is het juist Intel die een instructie minder heeft in iAMD64. Naast natuurlijk verschillen als 3DNow!/SSE3 (SSE-3 waarschijnlijk straks ook te vinden in 90nm versies van de K8) etc.
Dat is te lezen in dit rapport van MDR.
Andere belangrijke dingen als IOMMU ontbreken ook volledig op EM64T.
En dat de AMD64 implementatie een haastklus is geweest en gekopieerd uit AMD's handleidingen blijkt wel uit dit verhaal: Ze hebben gewoon een AMD64 instructie fout in Nocona gekopieerd.
Zal ook wel, want de K8 is AMD64 in hart en nieren. De prescott/nocona was eigenlijk 'yamhill' in hart en nieren, en is blijkbaar iets te overhaast bijgeklust naar AMD64. (64-bits plak je er niet zomaar even bij, zoals je hier kunt lezen.)

[halfgaar]

Een tijd geleden was er een computer gelanceerd, in het BASIC tijdperk (ik weet niet meer welke), die ook een fout had, waardoor elk programma met POKE nogwat moest voorafgaan in de source. Op een gegeven moment werden er clones van die PC uitgebracht. Ze hadden meteen even die fout eruit gehaald. En wat gebeurde er? De bestaande software was niet meer compatible. De fabrikant van die clone heeft dus snel die fout er ook in gezet.

Met andere woorden, Intel heeft misschien die fout express wel gekopieerd.

[aTmosh]

Met andere woorden, Intel heeft misschien die fout express wel gekopieerd.

Nee, AMD heeft geen fout in de besproken functie of bijbehorende documentatie, Intel's implementatie heeft geen 40 bits PAE maar 36 bits, vervolgens hebben ze wel de AMD CPUID functie en documentatie gekopieerd die correct is voor AMD, maar incorrect voor Intel.

Vrij grove fouten die wellicht onstaan zijn onder tijdsdruk, onmogelijk expres.

[Verwijderd]

Ik wil wel een benchmark zien van de Xeon met EM64T en de Itanium met IA64 op een 64 bit OS. En dan geen windows maar een echt 64b OS.

[hardwareaddict]

Om intel zelf te quoten: "Any difference in system hardware or software design or configuration may affect actual performance. "

Wat moet ik daar nog aan toevoegen?

[Standeman]

Ja.. nogal logisch dat ze dat zeggen.... Als je zo'n 64 bit proc neemt met 128Mb geheugen, een bagger progje dat slecht ontworpen is en het allemaal zo configureert dat het ongeveer 1 flop/s loopt dan is het niet echt vergelijkbaar he....

[Verwijderd]

wanneer houd dat op dat ziekelijke gedoe over amd en intel