Beste svaret
> cat pointersize.c
#include
int main(){
int *ip;
printf(“pointer size: \%zu\n”, sizeof(ip));
}
> cc -o pointersize pointersize.c
> ./pointersize
pointer size: 8
> cc -m32 -o pointersize pointersize.c
> ./pointersize
pointer size: 4
Pointersize avhenger bare av modellen du lager koden din under. Ikke på operativsystemet. Så jeg har en 64bit Linux, men hvis jeg tvinger gcc til å kompilere 32bit-kode, får jeg 32bit ELF- og i386-kode med bare 4 bytes pekestørrelse.
Hvis du får 4 byte på Windows, betyr det at du kompilerer fremdeles 32bit, og du bør finne bryteren for å frigjøre hele potensialet til maskinen din. Slipp løs Kraken!
Jeg målte bare at i går, mellom ytelsen til 32bit i386-kode og x86\_64 bdver2 (Piledriver, Haswell og oppover) kan være mer enn faktor 5 på hastighetsøkning, ikke bare bruken av større minnemodell. Det er stort sett ikke så kritisk, 4 GB minne er nok for de fleste applikasjoner.
Men med bare 32bit-kode begynner du å miste evnene til MMX, SSE, SSE2,3,4 og mange fremskritt i montering over siste 35 årene. I tillegg til raskere tilgang for dataoverføring, bitmanipulering, strengoperasjoner, avanserte matematiske funksjoner og, og, og, …
Mens det i noen tilfeller er original x86-kode en fordel: du kan ikke slå tettheten i koden!
Edit: (og en liten rant, du kan ignorere)
OK, jeg sjekker alltid verdien av setninger som det. Bare kompilert x86\_64 vs 8086 eldre kode. 53 byte for x88\_64 mot 74 byte på 8086 eldre kode med et lite program. Vel … Hvis du holder den på 8/16 bit, kan dette være sant. Men ikke med moderne programvare og c-programmer og kompilatorer. Så, ingen tårer om at den gamle arven er borte. La oss være ærlige: de var dritt. Den eneste gode tingen var at jeg glitret ung den gangen. Men det hadde andre ulemper.
Poenget er: våre moderne prosessorer er veldig kule. Vi har nå det vi bare hadde i drømmene våre på 80-tallet. Vi har endelig store nok harddisker til at vi ikke bryr oss om en byte eller to. Vi har stort nok minne hvis vi ikke kjører Windows eller andre ressurssvin. Vi har vektorbehandling på CPU-en vår og total parallell databehandling på GPU-ene våre. Vi har multicores, matematiske FPUer, spesialiserte registre som i MMX, SSE, SSEx, vi fikk FMA3 og FMA4 (vel, hvis du i det minste har en AMD-prosessor, må du vente lenge på å få tak i det), vi fikk svært sofistikerte monteringsopkoder som gjør alle de kule tingene i mikrokode eller til og med i maskinvare for oss, ofte enn ikke, bare gjort i en syklus, vi fikk hurtigminne som er større enn noe vi våget å drømme om tilbake på 80-tallet .
Og det «kommende» på 80-tallet var CD-en og ideen om å lagre mindboggingly gigabyte på en billig sølvplate var bare utenkelig. Og vi har telefoner med datamaskiner i det, som er i stand til å simulere de største mainframe-datamaskinene fra 85 med faktor 10000 av hastigheten deres eller noe.
Nå har vi alle de kule greiene!
Men hva gjør vi med det? Vi twitterer 144 tegn. Ingen kjenner underverkene til samlingskodene til våre splitter nye prosessorer lenger. Vi klikker bare på jævla spam og kjører Windows-systemer, som ble vurdert «borte snart», «skitete», «hva gjør du med det drittet» til og med 1985, da jeg begynte å studere.
Det gjorde ikke ble ikke bedre med Windows. Det er fremdeles bug-ridd og malware spammed crap, som svir over underverkene til datamaskinens maskinvare, som er så fantastiske, at hvis du installerer et noe bedre passende OS for vår tid, vil du sprenge tankene dine bort. Spesielt som utvikler.
Utviklingen av prosessorene våre avtar med bare to konkurrenter igjen på markedet, og det bør være på tide å virkelig slippe løs det vi allerede har: slå av den 32bit-dritten, begynn å optimalisere bibliotekode i montering der vi kan. Valgfritt, med alltid et tilbakefall til ren «C».
Og hva faen er Twitter? Det er en vits, ikke sant? 144 tegn ?! Det er ikke alvorlig, eller? Merket de hva slags maskinvare vi har? Ingen ord mot Twitter, hyggelig service, men du vet hva jeg mener. De tenker så jævla små og mislykkes selv da.
Svar
Du kommer til å hate dette svaret.
Klar?
Det avhenger.
En peker er størrelsen på en adresse på maskinen som C-programmet blir samlet for.
- På Z80-mikroprosessoren, populær på 1980-tallet, en peker er 16 bits.
- På den opprinnelige 8086 kan en peker være 16, 20 eller 32 bits, selv om adresseområdet bare var 20 bits bredt. Du måtte gi C-kompilatoren et kommandolinjeargument som sa hvor bred en peker skulle være. Det var et mareritt.Slå opp “ minnemodell ” på wikipedia for en lang og forferdelig introduksjon.
- På 68000 mikroprosessor var pekerne 32-bits.
- På x86-modellen som ble brukt til Intel-prosessorer inntil for omtrent 5 år siden, og fremdeles brukbar, var en peker på 32 bits, slik at den kunne adressere omtrent 4 GB. Denne begrensningen fører til opprettelse av 64-biters adresser.
- På x64-modellen som er brukt for Intel-prosessorer i de siste generasjonene, er en peker på 64 bits.
Du kan ikke anta at en peker har samme størrelse som en int, eller samme størrelse som en lang. Heltallskonstanten 0 kan konverteres til en peker, men andre heltallskonstanter er kanskje ikke konvertible. Når du konverterer 0 til en peker, er det ingen garanti for at bitene i pekeren alle vil være nuller, selv om dette er typisk. Det kan i det hele tatt være hva som helst. 0 er konvertert til en peker som ikke peker til noen gyldig adresse. Du kan legge til et helt tall i en peker, gi en peker, eller trekke et helt tall fra en peker, og gi en peker. Alt annet har udefinert effekt.