Bästa 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 beror bara på vilken modell du sammanställer din kod för. Inte i operativsystemet. Så jag har en 64-bitars Linux, men om jag tvingar gcc att kompilera 32-bitars kod får jag 32-bitars ELF- och i386-kod med bara 4 bytes pekstorlek.
Om du får 4 byte på din Windows betyder det att du håller fortfarande på att kompilera 32 bitar och du bör hitta omkopplaren för att frigöra maskinens fulla potential. Släpp loss Kraken!
Jag jämförde just att igår, mellan prestanda för 32bit i386-kod och x86\_64 bdver2 (Piledriver, Haswell och uppåt) kan vara mer än faktor 5 på hastighetsförstärkning, inte bara användningen av större minnesmodell. Det är oftast inte så kritiskt, 4 GB minne räcker för de flesta applikationer.
Men med bara 32bit-kod börjar du förlora förmågan hos MMX, SSE, SSE2,3,4 och många framsteg i montering under senaste 35 åren. Förutom snabbare åtkomst för dataöverföring, bitmanipulation, strängåtgärder, avancerade matematiska funktioner och, och, och, …
Även i vissa fall är original x86-kod en fördel: du kan inte slå tätheten i koden!
Redigera: (och en liten rant, du kan ignorera)
Okej, jag kollar alltid värdet på meningar som det. Bara sammanställt x86\_64 vs 8086 äldre kod. 53 byte för x88\_64 mot 74 byte på 8086 äldre kod med ett litet program. Tja … Om du håller den på 8/16 bit kan det stämma. Men inte med modern programvara och c-program och kompilatorer. Så, inga tårar om att de gamla arvetiderna är borta. Låt oss vara ärliga: de var skit. Det enda bra var att jag gnistrade ung då. Men det hade andra nackdelar.
Poängen är: våra moderna processorer är riktigt coola. Vi har nu vad vi bara hade i våra drömmar på 80-talet. Vi har äntligen tillräckligt stora hårddiskar för att vi inte bryr oss om en byte eller två. Vi har tillräckligt stort minne om vi inte driver Windows eller andra resursgrisar. Vi har vektorbearbetning på vår CPU och total parallell beräkning på våra GPU: er. Vi har multicores, matematiska FPU: er, specialiserade register som i MMX, SSE, SSEx, vi har FMA3 och FMA4 (ja, om du har en AMD-processor åtminstone annars måste du vänta länge för att få tag på det), vi fick mycket sofistikerade monteringsopkoder som gör alla coola saker i mikrokod eller till och med i hårdvara för oss, ofta än bara, bara gjort i en cykel, vi fick cacheminne som är större än vad vi vågade drömma om på 80-talet .
Och det ”kommande” på 80-talet var CD: n och tanken att lagra mindboggingly gigabyte på en billig silverplatta var helt enkelt otänkbar. Och vi har telefoner med datorer i det, som kan simulera de största mainframe-datorerna från 85 med faktor 10000 av deras hastighet eller något.
Nu har vi alla de coola grejerna!
Men vad gör vi med det? Vi twitterar 144 tecken. Ingen känner till underverk från monterings-koderna för våra helt nya processorer längre. Vi klickar bara på jävla skräppost och driver Windows-system, som fick betyget ”borta snart”, ”skit”, ”vad gör du med det skit” till och med 1985, när jag började studera.
Det gjorde inte blev inte bättre med Windows. Det är fortfarande bug-rided och malware spammad skit, det är svindlande över underverk av vår datorhårdvara, som är så fantastiska, att, om du installerar ett något bättre passande OS för vår tid, kommer att spränga ditt sinne bort. Särskilt som utvecklare.
Utvecklingen av våra processorer saktar ner med bara två konkurrenter kvar på marknaden och det borde vara dags att släppa loss det vi redan har: stäng av den 32bit-skiten, börja optimera vår bibliotek kod i montering där vi kan. Valfritt, med alltid en återgång till ren ”C”.
Och vad fan är Twitter? Det är ett skämt, eller hur? 144 tecken ?! Det är inte allvarligt, eller? Märkte de vilken typ av hårdvara vi har? Inget ord mot Twitter, trevlig service, men du vet vad jag menar. De tänker så jävla små och misslyckas även då.
Svar
Du kommer att hata det här svaret.
Klar?
Det beror på.
En pekare är storleken på en adress på den maskin som C-programmet kompileras för.
- På Z80-mikroprocessorn, populär på 1980-talet, en pekare är 16 bitar.
- På original 8086 kan en pekare vara 16, 20 eller 32 bitar, även om adressutrymmet bara var 20 bitar brett. Du var tvungen att ge C-kompilatorn ett kommandoradsargument som sa hur bred en pekare ska vara. Det var en mardröm.Leta upp “ minnesmodell ” på wikipedia för en lång och skrämmande introduktion.
- På 68000 mikroprocessorn var pekare 32 bitar.
- På x86-modellen som användes för Intel-processorer fram till ungefär 5 år sedan, och fortfarande användbar, var en pekare 32 bitar, så att den kunde adressera cirka 4 GB. Denna begränsning leder till att 64-bitarsadresser skapas.
- På x64-modellen som använts för Intel-processorer under de senaste generationerna är en pekare 64 bitar.
Du kan inte anta att en pekare har samma storlek som en int, eller samma storlek som en lång. Heltalskonstanten 0 kan konverteras till en pekare, men andra heltalskonstanter kanske inte kan konverteras. När du konverterar 0 till en pekare finns det ingen garanti för att bitarna i pekaren alla är nollor, även om detta är typiskt. Det kan vara vad som helst. 0 är konverterad till en pekare som inte pekar på någon giltig adress. Du kan lägga till ett heltal till en pekare, ge en pekare eller dra ett heltal från en pekare, vilket ger en pekare. Allt annat har odefinierad effekt.