Int size

  • Onderwerp starter Onderwerp starter bzub
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.

bzub

Gebruiker
Lid geworden
29 mrt 2007
Berichten
115
De grootte van het type int in C (en ook C++ geloof ik) is platform (en vaak ook compiler) afhankelijk.
Op een 16-bit systeem heeft hij standaard een grootte van 16 bit (2 bytes),
voor een 32-bit systeem 32-bit (4 bytes) enz.

Nu mijn vraag is welk nut heeft dit?
De cursus die ik gelezen heb gaf niet zo'n bevredigend antwoord:
Het gebruik van het type int heeft als gevolg dat efficient kan gewerkt worden op ieder platform.

De nadelen zijn overduidelijk maar voordelen?
 
alle types in alle hoge talen zijn platform afhankelijk... er zit nog altijd electronica onder....


Het is gewoon zo. wat was het nut anders geweest om op 64 bit over te stappen? lijkt me toch logish dat je dan minder geheugen nodig hebt voor dezelfde bewerking. -> sneller
 
alle types in alle hoge talen zijn platform afhankelijk... er zit nog altijd electronica onder....


Het is gewoon zo. wat was het nut anders geweest om op 64 bit over te stappen? lijkt me toch logish dat je dan minder geheugen nodig hebt voor dezelfde bewerking. -> sneller

Ik snap het toch nog niet helemaal.
Hoe worden de bewerkingen sneller door een grotere int te gebruiken? Het is natuurlijk wel handig dat je met de groei van de processor een steeds groter worden geheel getal kan opslaan Maar het lijkt me sterk dat data opslag de reden was voor de c-ontwikkelaars om een 'variabele' int-size te gebruiken vermits er geen floating point type is met de zelfde kenmerken.
 
geheugen moet je reserveren, dat kost tijd. als je een getal in c++ wilt opslaan dat te groot is voor het grootste type (long double denk ik) dan moet je met een speciale class werken. op een 64 bit systeem is dit getal (misschien) niet te groot voor het grootste type, zodat je er gewoon bewerkingen mee kunt doen zonder speciaale functies en types op te roepen...
 
Dit klopt niet helemaal. Het ligt eraan welk 64-bit datamodel er gekozen wordt/is.
Je hebt er meerdere bv: LP64, ILP64, LLP64

LLP64
Dit data model behoudt zijn compatibility met 32 bit code, int en long blijven 32 bit.
De LLP64 wordt door microsoft VC++ gebruikt. (Dus zult long long moeten gebruiken voor 64 bit).

Echter steeds meer compilers gebruiken LP64 (zoals HP, AIX, Linux).
Dit datamodel zegt dat int 32 bits is, maar longs en pointers zijn 64 bit.

Hoop dat nu wat duidelijker is.
 
Mijn antwoord slaat op de eerste vraag. Hij zegt daar :

"De grootte van het type int in C (en ook C++ geloof ik) is platform (en vaak ook compiler) afhankelijk.
Op een 16-bit systeem heeft hij standaard een grootte van 16 bit (2 bytes),
voor een 32-bit systeem 32-bit (4 bytes) enz."

Hij zegt in feite dat 64-bit systeem int 64-bit wordt dat is dus niet zo. Het is afhankelijk welk data model er gekozen wordt. Zo hebben ze bij microsoft gekozen voor data model llp64, om compatibility met 32bit code te behouden.

Goed waarom nu 64-bit, wordt daar alles sneller van ? Ja en nee!
De huidige processors (32-bit) kunnen maximaal 4 gigabyte aan memory adresseren.
De 64-bit processors kunnen 18 miljoen terabyte adresseren.

Nu is 4 GB werkgeheugen al behoorlijk wat. Het probleem is dat dit een harde grens is. Desktopsystemen met 1 GB zijn tegenwoordig al geen uitzondering meer. Bovendien kan Windows XP maximaal 2GB aan applicaties toewijzen, bij een maximum aan RAM wordt de overige 2GB door de kernel gereserveerd. Met de steeds grotere opslagmogelijkheid per geheugenmodule en de prijsdalingen komt de grens dan ook in zicht.

Kijk de server markt gebruikt al veel langer 64-bit omdat die meer geheugen nodig hebben dan 4Gb. (Databases kunnen nu meer geheugen gebruiken, dus sneller).

De desktop markt, Athlon 64 als de Apple Power Mac G5 ondersteunen momenteel een maximum van 8 GB. (Lopen niet meer tegen de grens aan van 4GB).
Maar de meeste desktop programma's zullen niet zo snel meer dan 4 GB aan memory nodig hebben.

Dus waar zit het voordeel: als je veel memory aan moet spreken (meer dan 4GB) en als je grote berekeningen moet doen. (bv een getal past niet in 32 bit maar wel in 64-bit. Op een 32-bit machine zou je meer instructies verbruiken dan op een 64-bit machine omdat je dan in 1 keer getal in kan lezen en meewerken.)

Nadeel: Om volledig gebruik van 64-bit te maken is het noodzakelijk dat software compleet herschreven wordt. (je oude programma's wel te verstaan).

Kortom: Er zijn verschillende modellen (llp64 enz) die beschrijven hoe groot variablen zijn.
Elk OS is vrij in het kiezen van een model. Compiler kent het model (anders kun je niet compileren voor dat OS) Met 64-bit kan er meer memory geadresseerd worden, dus programma die meer memory nodig dan 4Gb werken "sneller". Omdat sommige variabelen 64-bits zijn, kan je soms (bij bv grote berekeningen) deze gebruiken om met minder instructies het zelfde te bereiken dan met 32-bits. (De programmeur moet wel de goede keuzes maken tijdens 64-bit programma's maken).


Hoop dat het nu wat duidelijker is.
 
Laatst bewerkt:
Ik heb hierover ook een vraag:

Wat valt er te herschrijven aan software als je van 32 bit naar 64 bit wil gaan? Wat precies moet er dan in je code veranderen? Kan je een voorbeeld geven?
 
Nou je variabelen veranderen van grootte, dus je zult erop moeten letten dat je de juiste neemt.

Code:
Datatype	LP64 	ILP64	LLP64	ILP32	LP32
char	8	8	8	8	8
short	16	16	16	16	16
_int32		32			
int	32	64	32	32	16
long	64	64	32	32	32
long long			64		
pointer	64	64	64	32	32

Een voordeel is dat je sommige problemen met minder instructies/clock cycles kan oplossen. BV 32 bit:

Code:
{
    int   a1[2048];
    int   a2[2048];
    int   a3[2048];

    for (int i = 0; [B]i < 2048[/B]; ++i)
    {
         a3[i] = a1[i] & a2[i];
    }
}

Tegen 64-bit:

Code:
{
    long long  a1[1024];
    long long  a2[1024];
    long long  a3[1024];

    for (int i = 0; [B]i < 1024[/B]; ++i)
    {
         a3[i] = a1[i] & a2[i];
    }
}

Als je kan zien, deze AND operatie kan met twee keer minder operaties uitgevoerd worden. Het is dus mogelijk door de juiste keuzes te maken, code sneller uit te laten voeren. minder instructies = meer snelheid!
 
Dus als ik het goed begrijp dan kiest de compiler welke datatypes er een 'variabele' grootte hebben. En de reden hiervoor is om de steeds groter worden processor capaciteiten uit te buiten?
Er is nog altijd iets niet duidelijk. Wat ik hieruit opmaak is dat zou ik een 64-bit processor gebruiken dan zou ik wel degenlijk m'n voordeel kunnen halen.

Maar het voordeel bij 16- vs 32-bit machines zie ik nog niet meteen. Veronderstel nu dat de compiler de int op een 16-bit 2 byte grootte geeft en op een 32-bit 4byte. Dan is er toch geen verschil met het gebruiken van enerzijds een short en anderzijds een long?
Dus waarom moest de int toen al 'variabel' zijn?
Zit er een wezenlijk verschil tussen de int van 32-bit en de long van 32-bit?
Of "kiest" de compiler zijn datatype grootte gewoon en vallen nu en dan toevallig eens types in dezelfde grootte orde zodat eentje ervan vrijwel nutteloos lijkt?
 
De term 16, 32 of 64 bits platform geeft de grootte aan van de registers op de processor. De benaming en het aantal registers op een processor is speciefiek voor een 'familie' processors. Zo hebben x86 processors (die in pc's zitten) EAX, EBX, ECX, EDX, ESI en EDI als normale gebruiksregisters. Een register is een plek op de processor waar een waarde (16, 32 of 64 bits groot) opgeslagen wordt en door commando's bewerkt wordt. Deze waarden worden uit het geheugen geladen, in het register gezet, bewerkt (zoals bijv tel EAX en EBX bij elkaar op) en terug in het geheugen gezet.
De grootte van zo'n register bepaalt dus de maximale grootte van een waarde waarmee de processor kan werken. Zo kan een 16 bits processor alleen werken met waarden tussen 0 en 65535 (2 tot de macht 16). Wil je met grotere getallen werken zal dit dan in meerdere stappen moeten doen. Ditzelfde geldt voor 32 bits processoren, die kunnen niet verder tellen dan 2 tot de macht 32.
De grootste reden dat dit een enorme tijdwinst oplevert is omdat register op de processor zitten en dus vele malen sneller te lezen en schrijven zijn dan geheugen. Als je een te groot getal in stukjes moet gaan breken moeten er meer geheugen lees- en schrijf operaties plaatsvinden en dat kost gewoon meer tijd.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan