Nejlepší odpověď
> 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
Velikost ukazatele závisí pouze na modelu, pod kterým kompilujete svůj kód. Ne v operačním systému. Takže mám 64bitový Linux, ale když vynucuji gcc ke kompilaci 32bitového kódu, dostanu 32bitový ELF a i386 kód s pouhou velikostí ukazatele 4 bajty.
Pokud ve vašem Windows získáte 4 bajty, znamená to, že stále kompilují 32bit a měli byste najít přepínač, abyste uvolnili plný potenciál vašeho stroje. Uvolněte Kraken!
Právě jsem srovnal, že včera mezi výkonem 32bitového kódu i386 a x86\_64 bdver2 (Piledriver, Haswell a vyšší) může být více než faktor 5 na zvýšení rychlosti, nejen použití větší paměťový model. To většinou není tak kritické, 4 GB paměti stačí pro většinu aplikací.
Ale s pouhým 32bitovým kódem začnete ztrácet schopnosti MMX, SSE, SSE2,3,4 a mnoho pokroku v sestavování přes posledních 35 let. Stejně jako rychlejší přístup k jakémukoli přenosu dat, bitová manipulace, operace s řetězci, pokročilé matematické funkce, a, a,…
Zatímco v některých případech je původní kód x86 výhodou: nemůžete překonejte těsnost kódu!
Upravit: (a malý chvástat, který můžete ignorovat)
Dobře, vždycky kontroluji hodnotu takových vět. Právě zkompilovaný starší kód x86\_64 vs 8086. 53 bajtů pro x88\_64 vs 74 bajtů na starší kód 8086 s malým programem. No … Pokud to udržíte na 8/16 bit, může to být pravda. Ale ne s moderním softwarem a c-programy a kompilátory. Takže žádné slzy o tom, že staré staré časy jsou pryč. Buďme upřímní: byli na hovno. Jediná dobrá věc byla, že jsem tehdy byl třpytivý mladý. Mělo to ale jiné nevýhody.
Důležité je, že naše moderní procesory jsou opravdu skvělé. Nyní máme to, co jsme měli ve snech jen v 80. letech. Konečně máme dostatečně velké pevné disky, které nám nezajímají bajt nebo dva. Máme dostatečně velkou paměť, pokud nejezdíme Windows nebo jiná prasata. Na našem CPU máme vektorové zpracování a na našich GPU celkové paralelní výpočty. Máme vícejádra, matematické FPU, specializované registry jako v MMX, SSE, SSEx, dostali jsme FMA3 a FMA4 (dobře, pokud máte alespoň procesor AMD, musíte počkat dlouho, než se vám to podaří), my máme vysoce sofistikované montážní opcodes, které pro nás dělají všechny skvělé věci v mikrokódu nebo dokonce v hardwaru, mnohem častěji než ne, právě provedené v jednom cyklu, dostali jsme mezipaměť, která je větší než cokoli, o čem bychom se odvážili snít v 80. letech .
A „přicházející“ věcí v 80. letech bylo CD a myšlenka ukládat ohromující gigabajty na levný stříbrný talíř byla prostě nepředstavitelná. A máme v sobě telefony s počítači, které dokážou simulovat největší sálové počítače z roku 85 faktorem 10000 jejich rychlosti nebo tak něco.
Nyní máme všechny skvělé věci!
Ale co s tím děláme? Twitterujeme 144 znaků. Už nikdo nezná zázraky montážních kódů našich zbrusu nových procesorů. Stačí kliknout na zasraný spam a řídit systémy Windows, které byly hodnoceny jako „pryč brzy“, „hovno“, „co děláš s těmi kecy“, dokonce i v roce 1985, kdy jsem začal studovat.
S Windows se to opravdu nezlepšilo. Stále jsou to chyby a spamy šířící se malwarem, které se diví nad zázraky našeho počítačového hardwaru, které jsou tak úžasné, že pokud si na naši dobu nainstalujete něco lépe vyhovujícího OS, vyrazí vám to mysl. Zejména jako vývojář.
Vývoj našich procesorů se zpomaluje, na trhu zbývají pouze dva konkurenti a měl by být čas skutečně uvolnit to, co již máme: vypnout 32bitovou sračku, začít optimalizovat naše kód knihovny v sestavě, kde můžeme. Volitelné, vždy s rezervou čistého „C“.
A co je kurva Twitter? To je vtip, že? 144 znaků ?! To není vážné, nebo? Všimli si, jaký máme hardware? Žádné slovo proti Twitteru, pěkná služba, ale víte, co tím myslím. Myslí si, že jsou tak kurva malí a ani poté selžou.
Odpověď
Tuto odpověď budete nenávidět.
Jste připraveni?
Závisí to.
Ukazatel je velikost adresy na stroji, pro který je program C kompilován.
- Na mikroprocesoru Z80, populárním v 80. letech, ukazatel má 16 bitů.
- Na původní verzi 8086 může mít ukazatel 16, 20 nebo 32 bitů, přestože adresový prostor byl široký pouze 20 bitů. Museli jste dát kompilátoru C argument příkazového řádku, který říkal, jak široký by měl být ukazatel. Byla to noční můra.Vyhledejte „ paměťový model “ na wikipedii a získejte dlouhý a děsivý úvod.
- U mikroprocesoru 68 000 byly ukazatele 32 bitů.
- Na modelu x86 používaném pro procesory Intel až do doby před asi 5 lety, který byl stále použitelný, měl ukazatel 32 bitů, což mu umožnilo oslovit přibližně 4 GB. Toto omezení vedlo k vytvoření 64bitových adres.
- Na modelu x64 použitém pro procesory Intel posledních několika generací má ukazatel 64 bitů.
Nemůžete Předpokládejme, že ukazatel má stejnou velikost jako int nebo stejnou velikost jako long. Celočíselnou konstantu 0 lze převést na ukazatel, ale jiné celočíselné konstanty nemusí být převoditelné. Když převádíte 0 na ukazatel, neexistuje žádná záruka, že všechny bity obsažené v ukazateli budou nuly, i když je to typické. Může to být vůbec cokoli. 0 je převeden na ukazatel, který ukazuje na žádnou platnou adresu. Můžete přidat celé číslo do ukazatele, čímž získáte ukazatel, nebo odečíst celé číslo od ukazatele, čímž se získá ukazatel. Cokoli jiného má nedefinovaný účinek.