[DB] Beter 32bits dan 64bits processor?

[Verwijderd]

Ik las gisteren een interessant stuk over het gebruik van datatypes in MSSQL Server, en daaruit kwam naar voren dat het gebruiken van het type integer slimmer is dan het gebruik van het type tinyint.

Waarom? Omdat integer 4 bytes vereist en tinyint 2 bytes. Een 32 bits Intel Processor behandelt per request 4 bytes. Dwz dat de uitvoertijd van een integer datatype lager is dan die van een tinyint type omdat deze van 2 bytes eerst naar 4 bytes gewrapped moet worden. Heel vreemd natuurlijk omdat een integer visueel groter is.

Nu vroeg ik me dus af, is het wel verstandig om een 64 bits processor te gebruiken voor een databaseserver Want dat zou betekenen dat je dus 8 bytes per request afhandelt met de processor, en dat dus alle datatypes behalve de datetime van 8 bytes een overhead opleveren die je met een 32 bits processor niet hebt.

[Femme]

De snelheidsverlies dat je hiermee krijgt zal niet opwegen tegen het performance voordeel van >4GB adresseerbaar geheugen, als de database server daadwerkelijk zoveel geheugen nodig heeft.

In het geval van de AMD Hammer zijn er in 64-bit mode nog andere voordelen die de snelheid bevorderen zoals een groter aantal registers.

Bovengenoemde verhaal is trouwens ook de reden waarom 64-bit processors meer cache (nodig) hebben.

[Verwijderd]

Op woensdag 27 februari 2002 11:07 schreef Femme het volgende:
De snelheidsverlies dat je hiermee krijgt zal niet opwegen tegen het performance voordeel van >4GB adresseerbaar geheugen, als de database server daadwerkelijk zoveel geheugen nodig heeft.

In het geval van de AMD Hammer zijn er in 64-bit mode nog andere voordelen die de snelheid bevorderen zoals een groter aantal registers.

Bovengenoemde verhaal is trouwens ook de reden waarom 64-bit processors meer cache (nodig) hebben.

Dan zou het eigenlijk verstandiger zijn voor software leveranciers zoals een Microsoft om datatypes juist groter te maken

Dus zegge voor iedere datatype minimaal 8 bytes pakken zodat de overhad geminimaliseerd wordt voor 64 bits Betreft schijfruimte hoef je het niet te laten.

En voor de 32 bits processors dus minimaal 4 bytes reserveren

[Varienaja]

Sinds win32 gebruikt toch ook iedereen opeens 32 bits integers in plaats van 16 bits integers? Dat zal met de overgang naar 64bits ook wel zo zijn.

[ACM]

Op woensdag 27 februari 2002 10:00 schreef Gordijnstok het volgende:
Waarom? Omdat integer 4 bytes vereist en tinyint 2 bytes. Een 32 bits Intel Processor behandelt per request 4 bytes. Dwz dat de uitvoertijd van een integer datatype lager is dan die van een tinyint type omdat deze van 2 bytes eerst naar 4 bytes gewrapped moet worden. Heel vreemd natuurlijk omdat een integer visueel groter is.

Dat is inderdaad bj Postgresql ook zo, int4 wordt veel efficienter behandeld dan int2.

Echter zou je ook kunnen afwegen die hele int2 te skippen, simpelweg omdat je het "om de opslagruimte" niet meer hoeft te laten
Eigenlijk zou je gewoon altijd de "systeem eigen integers" moeten gebruiken (op 32bits cpu dus 32bit etc) voor performance.

Maar of een 64-bits cpu efficient met 4bytes integers kan werken hangt dus vrij sterk van de architectuur ervan af.
Of ie dus wel of niet met 4bytes tegelijk wil kunnen werken.

[raptorix]

Ik neem aan dat je een smallint bedoelt een tinyint is 1 byte

[raptorix]

Ik zie dat je trouwens ook bigint hebt in sqlserver 2000:

bigint

Integer (whole number) data from -2^63 (-9223372036854775808) through 2^63-1 (9223372036854775807). Storage size is 8 bytes.

int

Integer (whole number) data from -2^31 (-2,147,483,648) through 2^31 - 1 (2,147,483,647). Storage size is 4 bytes. The SQL-92 synonym for int is integer.

smallint

Integer data from -2^15 (-32,768) through 2^15 - 1 (32,767). Storage size is 2 bytes.

tinyint

Integer data from 0 through 255. Storage size is 1 byte.

[Verwijderd]

Op woensdag 27 februari 2002 12:02 schreef raptorix het volgende:
Ik neem aan dat je een smallint bedoelt een tinyint is 1 byte

Erm.. ja Vergissing..

[Verwijderd]

Op woensdag 27 februari 2002 12:02 schreef ACM het volgende:

[..]

Dat is inderdaad bj Postgresql ook zo, int4 wordt veel efficienter behandeld dan int2.

Echter zou je ook kunnen afwegen die hele int2 te skippen, simpelweg omdat je het "om de opslagruimte" niet meer hoeft te laten
Eigenlijk zou je gewoon altijd de "systeem eigen integers" moeten gebruiken (op 32bits cpu dus 32bit etc) voor performance.

Maar of een 64-bits cpu efficient met 4bytes integers kan werken hangt dus vrij sterk van de architectuur ervan af.
Of ie dus wel of niet met 4bytes tegelijk wil kunnen werken.

Dan kun je eigenlijk ook wel af van de boolean Kun je beter een integer veld gebruiken met een 1 of een 0 Zelfde resultaat, bereikbaar met dezelfde scripting, en nog sneller ook

[Glimi]

Tja kan opzich die bool vervangen maar dan moet je wel DWINGEN dat ie alleen 1 of 0 kan ontvangen.
Nare is dan wel dat dingen als Boolwaarde = (Blah +1) - Blah gaan werken wat vieze constructies in de hand werkt

[Verwijderd]

Op woensdag 27 februari 2002 12:16 schreef Glimi het volgende:
Tja kan opzich die bool vervangen maar dan moet je wel DWINGEN dat ie alleen 1 of 0 kan ontvangen.
Nare is dan wel dat dingen als Boolwaarde = (Blah +1) - Blah gaan werken wat vieze constructies in de hand werkt

Dat soort constructies hou je toch altijd wel en moet je toch wel op controleren

[ACM]

Op woensdag 27 februari 2002 12:13 schreef Gordijnstok het volgende:
Dan kun je eigenlijk ook wel af van de boolean Kun je beter een integer veld gebruiken met een 1 of een 0

Dat doen ze in C toch al?
(heeeel vooruitstrevend hoor ) en Java werkt meende ik ook met 32bits per boolean? (of was dat nou 8bits?)

Op woensdag 27 februari 2002 12:16 schreef Glimi het volgende:
Tja kan opzich die bool vervangen maar dan moet je wel DWINGEN dat ie alleen 1 of 0 kan ontvangen.
Nare is dan wel dat dingen als Boolwaarde = (Blah +1) - Blah gaan werken wat vieze constructies in de hand werkt

Ach, in C (en php en perl en...) zit je met 0 = false, !0 = true
Als je dat afspreekt hoef je ook niet te werken met verplicht 1 of 0