Cel mai bun răspuns
> 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 depinde doar de modelul în care compilați codul. Nu pe sistemul de operare. Deci, am un Linux pe 64 de biți, dar dacă forțez gcc să compileze codul pe 32 de biți, primesc cod ELF pe 32 de biți și codul i386 cu o dimensiune a indicatorului de doar 4 octeți.
Dacă primiți 4 octeți pe Windows, asta înseamnă că încă compilează 32 de biți și ar trebui să găsiți comutatorul pentru a elibera întregul potențial al mașinii dvs. Eliberați Kraken!
Tocmai am comparat că ieri, între performanța codului i386 pe 32 de biți și x86\_64 bdver2 (Piledriver, Haswell și mai sus) poate fi mai mult decât factorul 5 pentru creșterea vitezei, nu doar utilizarea model de memorie mai mare. Acest lucru nu este în mare parte atât de critic, 4 GB de memorie sunt suficienți pentru majoritatea aplicațiilor.
Dar cu doar un cod pe 32 de biți începeți să pierdeți abilitățile MMX, SSE, SSE2,3,4 și multe progrese în asamblare peste ultimii 35 de ani. La fel și accesul mai rapid pentru orice transfer de date, manipulare de biți, operații de șiruri, funcții matematice avansate și, și, și, …
Deși în unele cazuri codul x86 original este un avantaj: nu puteți bateți etanșeitatea codului!
Editați: (și o mică descifrare, s-ar putea să ignorați)
Bine, verific întotdeauna valoarea unor propoziții de genul acesta. Tocmai ați compilat codul vechi x86\_64 vs 8086. 53 octeți pentru x88\_64 vs 74 octeți pe codul moștenit 8086 cu un mic program. Ei bine … Dacă îl păstrați la 8/16 biți, acest lucru ar putea fi adevărat. Dar nu cu software-ul modern, programe c și compilatoare. Deci, nu există lacrimi despre faptul că vechile vremuri moștenite au dispărut. Să fim sinceri: erau niște rahaturi. Singurul lucru bun a fost că atunci când eram scânteietor. Dar asta avea și alte dezavantaje.
Ideea este că procesoarele noastre moderne sunt foarte interesante. Acum avem ceea ce am avut doar în visele noastre din anii ’80. În sfârșit, avem hard diskuri suficient de mari încât să nu ne pese de un octet sau doi. Avem memorie suficient de mare, dacă nu conducem Windows sau alte porci de resurse. Avem procesare vectorială pe procesorul nostru și calcul paralel total pe GPU-urile noastre. Avem multicore, FPU-uri matematice, registre specializate precum MMX, SSE, SSEx, avem FMA3 și FMA4 (bine, dacă aveți un procesor AMD cel puțin altfel, trebuie să așteptați mult timp pentru a pune mâna pe asta), avem avem opcodes de asamblare extrem de sofisticate care fac toate lucrurile interesante din microcod sau chiar din hardware pentru noi, de cele mai multe ori, doar făcute într-un singur ciclu, avem memorie cache mai mare decât orice am îndrăzni să visăm înapoi în anii 80 .
Iar ceea ce „venea” în anii 80 a fost CD-ul, iar ideea de a stoca gigabytes minți pe o placă de argint ieftină a fost doar de neimaginat. Și avem telefoane cu computere, care pot simula cele mai mari computere mainframe din 85 cu factorul 10000 din viteza lor sau ceva de genul.
Acum avem toate lucrurile interesante!
Dar ce facem cu el? Noi twitter de 144 de caractere. Nimeni nu mai cunoaște minunile codurilor de asamblare ale procesoarelor noastre noi. Facem doar clic pe nenorocit de spam și conducem sisteme Windows, care au fost clasificate ca „dispărute curând”, „rahat”, „ce faci cu porcăriile acelea” chiar și în 1985, când am început să studiez.
Nu Nu s-a îmbunătățit cu Windows. Încă este o porcărie plină de bug-uri, iar malware-urile sunt spam-uri, care ascund minunile hardware-ului computerului nostru, care sunt atât de uimitoare, încât, dacă instalați un sistem de operare mai potrivit pentru timpul nostru, vă va distruge mintea. Mai ales ca dezvoltator.
Dezvoltarea procesoarelor noastre încetinește, cu doar doi concurenți rămași pe piață și ar trebui să fie timpul să dezlănțuim ceea ce avem deja: opriți acea rahat de 32 de biți, începeți să optimizați codul bibliotecii în asamblare unde putem. Opțional, cu întotdeauna o alternativă la „C” pur.
Și ce dracu este Twitter? E o glumă, nu-i așa? 144 de caractere ?! Nu este grav, sau? Au observat ce fel de hardware avem? Nici un cuvânt împotriva Twitter, un serviciu frumos, dar știi la ce mă refer. Se gândesc atât de nenorocit și nu reușesc nici atunci.
Răspunde
O să urăști acest răspuns.
Gata?
Depinde.
Un indicator este dimensiunea unei adrese de pe mașină pentru care este compilat programul C.
- Pe microprocesorul Z80, popular în anii 1980, un pointer are 16 biți.
- Pe 8086 original, un pointer ar putea avea 16, 20 sau 32 de biți, chiar dacă spațiul de adresă avea o lățime de doar 20 de biți. Trebuia să oferiți compilatorului C un argument de linie de comandă care să spună cât de larg ar trebui să fie un indicator. A fost un coșmar.Căutați „ model de memorie ” pe Wikipedia pentru o introducere lungă și îngrozitoare.
- Pe microprocesorul 68000, indicatoarele erau pe 32 de biți.
- Pe modelul x86 utilizat pentru procesoarele Intel până acum aproximativ 5 ani și încă utilizabil, un indicator avea 32 de biți, permițându-i să se adreseze aproximativ 4 GB. Această limitare duce la crearea de adrese pe 64 de biți.
- Pe modelul x64 utilizat pentru procesoarele Intel din ultimele generații, un indicator este de 64 de biți.
Nu puteți presupunem că un indicator are aceeași dimensiune ca un int sau aceeași dimensiune ca un lung. Constanta întregului 0 poate fi convertită într-un pointer, dar alte constante întregi pot să nu fie convertibile. Când convertiți 0 într-un pointer, nu există nicio garanție că biții conținuți în pointer vor fi toți zerouri, deși acest lucru este tipic. Ar putea fi orice. 0 este convertit într-un pointer care nu indică nicio adresă validă. Puteți adăuga un număr întreg la un pointer, obținând un pointer sau scăzând un număr întreg dintr-un pointer, obținând un pointer. Orice altceva are un efect nedefinit.