64bits vs 32bits (i386/x86_64 op intel cpu)

[DDX]

ik zal er wel vreselijk overheen kijken (of verkeerde search doen)
maar ik kan er mar geen duidelijk antwoord op vinden

ik heb binnenkort een aantal intel servers met single en dual xeon cpu's
(met emt64 support)

nu vraag ik mij af of ik daar nu de i386 versie of de x86_64 versie op ga installeren
(redhat)

ga ik snelheidsverschil merken als ik de 64bits versie ga draaien of kan ik netzogoed de 32bits versie gaan draaien ?

ik ga er iig niet meer dan 4gb mem inzetten dus voor memorysupport heb ik het niet nodig

iemand ervaring met verschil tussen 32bits en 64bits
of misschien een duidelijk verhaal/benchmark oid hierover ?

[Geert.H]

Hangt nogal van de applicate af die erop gaat draaien. Sommige 32 bits software is nog niet geoptimaliseerd voor 64 bits en zal waarschijnlijk sneller lopen op 32 bits (of in zijn geheel niet op 64 bits ).

Over het algemeen is 64 bits sneller (mysql, apache en compileren van dingen als mozilla en je kernel)

[Anoniem: 6137]

Sneller, hoezo sneller dan ? Door dat het 64 bits is ? Of doordat de CPU anders qua opbouw is ?

Ik zie niet in dat 64 bit sneller compiled ofzo, true voor sommige dingen kan het sneller gaan enzo das vooral bij grote berekeningen enzo.

Could be wrong i quess ;-)

[froggie]

Ik heb zelf wat gerommeld met 64-bit op m'n laptop, gewoon voor mezelf wat proberen te vergelijken. Ik werd nog niet overtuigd door apps als MySQL en Apache (maar then again, het is een laptop, dus je loopt snel tegen hardware limieten aan) terwijl de 64-bit distro's nog wat scherp aan de randjes zijn.
Op een productie server zou ik nog even op 32-bit blijven en over een jaar nog eens verder kijken. De software is dan verder uitgekristaliseerd en ik verwacht dan de 'beloofde' verschillen te zien tussen 32 en 64-bit

[odysseus]

Anoniem: 6137 schreef op zondag 09 januari 2005 @ 20:41:
Sneller, hoezo sneller dan ? Door dat het 64 bits is ? Of doordat de CPU anders qua opbouw is ?

Ik zie niet in dat 64 bit sneller compiled ofzo, true voor sommige dingen kan het sneller gaan enzo das vooral bij grote berekeningen enzo.

Could be wrong i quess ;-)

Aan die extra bits heb je op zich inderdaad niet heel erg veel in de meeste gevallen. De uitbreiding die gebruikt wordt, x86_64, heeft echter ook nog een aantal andere wijzigingen ten opzichte van standaard x86-CPU's, waaronder een verzameling extra registers. Daar valt wel voordeel te behalen.

[Anoniem: 58667]

Het voordeel van 64 bits support zit hem in de hoeveelheid adresseerbaar geheugen. Het enige scenario waar je, puur op 64-bits afgaande voordeel uit zou halen, zijn berekeningen op grote getallen (die normaal in 2 32-bits operaties worden opgesplitst).

Wel is het zo dat dingen op AMD's K8 soms sneller gaan op 64 bits dan op 32 bits, dat is te danken aan het feit dat AMD bijvoorbeeld extra registers enabled wanneer de CPU in 64-bits mode werkt.

Op zich goed natuurlijk, maar mensen gaan dan al snel denken dat die extra snelheid van de 64-bits komt. Bij mijn weten is het enige verschil tussen 32 bits en 64 bits CPU's nog altijd de hoeveelheid geheugen waar ze mee overweg kunnen

[Anoniem: 106008]

64 bit zou ik nemen, dan heb je zeker iets voor in de toekomst. Alles wordt 64 bit, dus waarom zou je dan 32 bit software gaan installeren. 64 bit software op een 64 bit pc haalt zoiezo wel hogere prestaties als een 64 bit pc op 32 bit software, want je 32 bit software gaat ook tot ongeveer 62 bit (is mij ooit verteld, maar of die laml*l er wat van wist is mij de vraag)
Maar ik zelf zou voor 64 bits gaan!!!

[odysseus]

Anoniem: 58667 schreef op zondag 09 januari 2005 @ 20:56:
Op zich goed natuurlijk, maar mensen gaan dan al snel denken dat die extra snelheid van de 64-bits komt. Bij mijn weten is het enige verschil tussen 32 bits en 64 bits CPU's nog altijd de hoeveelheid geheugen waar ze mee overweg kunnen

Dat is niet helemaal waar - de hoeveelheid adresseerbaar geheugen heeft wel te maken met het aantal bits waarop de processor werkt, maar is daar niet direct mee verbonden. Zo kunnen 32-bits Xeons meer dan 4GB geheugen adresseren omdat bepaalde delen van de CPU in 36 bits zijn uitgevoerd. Andersom is het zo dat de huidige x86-64-CPU's geen 64 bits hebben voor hun geheugenadressering: ik meen dat er op dit moment 48 bits gebruikt worden, maar dat staat wel ergens in een specsheet neem ik aan .

--edit--

Anoniem: 106008 schreef op zondag 09 januari 2005 @ 20:58:
64 bit zou ik nemen, dan heb je zeker iets voor in de toekomst. Alles wordt 64 bit, dus waarom zou je dan 32 bit software gaan installeren. 64 bit software op een 64 bit pc haalt zoiezo wel hogere prestaties als een 64 bit pc op 32 bit software, want je 32 bit software gaat ook tot ongeveer 62 bit (is mij ooit verteld, maar of die laml*l er wat van wist is mij de vraag)
Maar ik zelf zou voor 64 bits gaan!!!

Alles wordt vast 64 bit, maar wanneer? Dat duurt nog een kleine eeuwigheid als je het in pc-levensduren uitdrukt. Bovendien is het zoals hierboven al gezegd helemaal niet zo dat software die op een 64-bit processor draait sneller dan diezelfde software op een 32-bit processor. Door de extra bits die over de geheugenbus moeten kan het zelfs trager gaan.

[ Voor 35% gewijzigd door odysseus op 09-01-2005 21:03 ]

[Anoniem: 58667]

Om eigenlijk een kort en duidelijk antwoord te geven op de vraag: Neen, normaalgesproken ga je geen verschil in snelheid merken tussen een 64-bits of een 32-bits distro op EMT64 CPU.

[Kees]

dat merk je wel, vraag me niet hoe, maar mysql performt 5-10% beter op 64 bits dan op 32 bits tegenwoordig.

[odysseus]

Ik gok dat MySQL wel baat heeft bij wat extra registers en dat de verbetering vooral in die hoek gezocht moet worden. De extra efficiëntie die het vergelijken van een enkele 64-bits waarde heeft in plaats van een vergelijking van twee 32-bits waardes lijkt me verwaarloosbaar - voor compressie- en encryptie-algoritmes kan ik het me voorstellen, maar daar zal MySQL niet al te veel mee te maken hebben.

[Anoniem: 27915]

Fedora installeert op je x86-64 systeem zowel een 32-bit als 64-bit environment. Dus applicaties die per se 32-bits moeten, werken ook. Van wat ik begrepen heb, is het iets sneller, maar veel maakt 't niet uit.

[Anoniem: 58667]

Correct me if I'm wrong, maar bij mijn weten zitten die registers enkel in de K8 core, niet in Intel CPU's. Dat was overigens niet het enige dat er minder op zit bij de Intel implementatie

Ja, op AMD maakt het een verschil, maar op Intel dacht ik niet.

[DDX]

op dit moment heb ik al 1 dell poweredge 1425 staan
dual 2.8 xeon (met 2gb mem) met emt64 support

heb als test al even tao 64bits installed
werkt allemaal wel ok
en ook 32bits applicaties draaien wel
alleen beetje lastig met rpm's van yum repo's installeren
die gaan allemaal uit van 32bits nog

deze machine gaat voor spamassassin gebruikt worden
(veel perl dus en clamav virusscanning)
denk dat ik hier dus nog maar even tao32bits op zet
(tenzij ik dus grote verschillen in prestaties zou zien met 64bits)

machines die binnenkort installed gaan worden zijn :

webservers (apache / java)
dbservers (oracle)
fileservers (nfs)

hier komt allemaal redhat es 3 op te staan en twijffel hier dus nog een beetje over of ik nu voor de 64bits redhat ga, of toch maar voor de 32bits...

fileserver zal ik het verschil niet echt merken (cpu's maken daar toch weinig uit)
maar voor de oracle en webservers kan 64bits misschien best nuttig zijn ?
(als ik lees dat mysql 5-10% betere performance heeft met 64bits?)

[Anoniem: 63780]

Die 5-10% zou kunnen worden veroorzaakt door die extra registers van AMD dus of je dat bij intel hebt is maar de vraag.Benchmark gewoon eens als je er toch een server hebt staan. als ik zo lees is die server nog niet in gebruik genomen dus

[DDX]

mja kan ik doen, alleen waarmee benchmark ik het ?
spamassassin valt weinig aan te benchen

time make bzImage zou ik kunnen doen
nog andere ideeen ?

[Anoniem: 25021]

odysseus schreef op zondag 09 januari 2005 @ 21:00:
Zo kunnen 32-bits Xeons meer dan 4GB geheugen adresseren omdat bepaalde delen van de CPU in 36 bits zijn uitgevoerd. Andersom is het zo dat de huidige x86-64-CPU's geen 64 bits hebben voor hun geheugenadressering: ik meen dat er op dit moment 48 bits gebruikt worden, maar dat staat wel ergens in een specsheet neem ik aan .

code:

$ cat /proc/cpuinfo | grep ^address\ sizes
address sizes   : 40 bits physical, 48 bits virtual

[Anoniem: 63780]

DDX schreef op maandag 10 januari 2005 @ 09:04:
mja kan ik doen, alleen waarmee benchmark ik het ?
spamassassin valt weinig aan te benchen

time make bzImage zou ik kunnen doen
nog andere ideeen ?

Ik zat meer te denken aan het banchmarken van de desbetreffende servers wat erop komen te draaien. Een Oracle Database benchmark bijv. Na wat zoeken kom ik helaas alleen maar een benchmark product waar je voor moet betalen, Benchmark Factory, er is wel een trail versie beschikbaar.
MySQL komt met een eigen benchmark suite, nu weet ik niet of oracle dat ook meeleverd.

Hier nog een stukje over 64bits vs 32bits bij databases (in dit geval MS SQLServer). Het gaat vooral over voordelen van geheugen adressering.

[ Voor 10% gewijzigd door Anoniem: 63780 op 10-01-2005 14:02 ]

[DDX]

tja benchmarken van oracle ga/kan ik niet doen
ik heb nog geen license van oracle
en ik ben ook geen DBA
dus geen idee kwa tuning ed (dit laten we over aan iemand die wel kennis heeft van oracle)

dus tenzij iemand nog leuke benchmarks weet voor andere aplicaties onder linux..

[Parody]

Het aantal voor de programmeur zichtbare registers in 64-bits mode is gelijk voor zowel AMD als Intel. Die aantallen registers hangen vast aan de instructieset, en die is voor 99% gelijk voor AMD en Intel. Die paar exoten die anders geïmplementeerd zijn heb ik het even niet over.

Ik heb nog geen benchmarks gelezen voor Intel versus AMD, dus ik zou niet durven beweren wie de 64-bits extensies efficiënter geïmplementeerd heeft. Kan dus inderdaad zijn dat AMD intern meer ruimte over heeft voor register renaming, maar zeker weten doe ik dat niet. Puur op speculatie zou ik zeggen dat AMD het "beter" gedaan heeft omdat ze al bij het begin van de K8-ontwerpen hier rekening mee gehouden hebben, maar ook dat blijft puur speculatie.

[froggie]

Oracle op 64-bit zou ik nog niet durven. Ik heb een maand of 3 geleden over de schouders van collega's meegekeken toen zij een volledig nieuwe Oracle DB cluster gingen neerzetten. Zij hebben nog netjes voor de 32-bit versie van Oracle (en dus ook 32-bit CPU's) gekozen omdat Oracle zelf aangaf nog lang geen production ready versie van Oracle DB 64-bit te hebben. Het kan zijn dat dit nu veranderd is, maar daar zul je zelf even naar moeten informeren.

Omdat webservers waarschijnlijk geen voordeel uit 64-bit gaan halen en je zelf al aangaf dat je fileserver ook geen echte winst ging boeken zou ik gewoon op de 32-bit distro's blijven. 64-bit CPU's kopen is geen gek idee met het oog op de toekomst, maar de software is er gewoon nog niet klaar voor.