Fel, fel, fel. Nigel Page på Microsoft Australia har försökt förklara systemkraven hos nästkommande version av deras operativsystem (Windows Vista) och särskilt hur mycket extra RAM en x86-64-burk drar jämför med en vanlig x86-32.
Sanningen är att programkoden tar mer plats (bredare instruktioner) och alla pekare drar 8 bytes istället för 4 (64-bitars addressrymd). Datan däremot, som typiskt ockuperar den absolut största delen av detta nämnda gigabytestora RAM, drar inte per automatik mer utrymme.
C-perspektivet (för x86-64, andra 64-bitars plattformar beter sig annorlunda): En
int är fortfarande 4 bytes bred. En float, double eller long double är lika stora som i 32-bitars fallet. En long är fördubblad, 8 bytes istället för 4. Så visst, om någon programmerare strött long's över hela sin kod, använder dom som 32-bitars data och kompilerar om rubbet för x86-64 så drar programmet mycket riktigt onödigt mycket RAM. En bugg.Dubbel faktiskt datamängd fås bara om programmet anpassas till att använda dubbla ordstorleken på 64-bitars diton med vetskap om att ALU:n fixar beräkningen på samma tid. Man vill åt dubblerad heltalsprecision. Sådana program kommer vara ytterst sällsynta, istället ser man till att programmet kompileras med
long long mot x86-32 och long mot x86-64, vilket ger samma uppförande på båda plattformar med bonusen i 64-bitarsfallet att beräkningarna sker fortare. Nej, ska man verkligen dra nytta av sina extra bitar använder man den bredare ALU:n till att bearbeta samma data på halverad tid. Till samma RAM-kostnad. Kika på GNU MP för ett exempel (en bignum-implementation).Notera att Java, Mono och .NET inte gör skillnad på de inbyggda datatypernas storlekar mellan 32- och 64-bitars plattformar. En
long är alltid 8 bytes stor. Körs programmet på en 64-bitars maskin kan VM:en utföra en long + long addition i en instruktion. Till samma RAM-kostnad.Så lugn i stormen, om du verkligen behöver dubblera RAM-minnet för att rulla Vista på din x86-64-maskin kanske du borde fundera på hur välskrivna de program (och det OS) du kör är. Fundera är väl det ända som återstår att göra, när inte källkoden finns tillgänglig för dig eller någon annan nyfiken själ att glutta på.
Nu tror jag bestämt vi har blivit GNU-blinda eller har jag inte läst någon spec som jag borde?
ReplyDeleteEn short är minst 16 bit, en int är minst 16 bit, en long är minst 32 bit. En short får inte vara längre än en int, en int får inte vara längre än en long. Men det finns ingenting som säger att en int inte får vara 64 bit.
Tyvärr är jag rätt dålig på lågnivå stuff.
ReplyDeleteMen om adresseringen fungerar så att man adresserar på ordnivå så är han väl inte helt ute och cyklar, speciellt inte om det inte finns instruktioner för att plocka ut och skriva en specifik range inom ett ord (tex de högsta eller lägsta 32 bitarna).
Om det inte finns instruktioner för sådant och kompilatorn skall kompensera för detta känns det som att det lätt blir väldigt komplicerat väldigt fort. Tex kan man inte maska manuellt om man har 2 variabler som existerar inom samma ord och som accessas från två olika trådar. För övrigt skulle sådant ta massa extra operationer och jag vet inte om det är särskilt bra heller?
Sen tänkte jag på en annan sak, är inte instruktionslängden variabel på x86? :-)
Att du har teoretiskt rätt om att det inte går åt mer minne på en 64-bitars plattform kan jag köpa rakt av. Däremot om det i praktiken är så enkelt alternativt effektivt att göra det är jag inte lika övertygad om.
Jag antar att jag ska ta tillbaka lite av flummet i den förra kommentaren. Om man kan adressera bara 4GB minne på en 32 bitars x86 iaf så antar jag att det fungerar på samma sätt på en x86-64, dvs max adreserbart minne är 2^64.
ReplyDeleteAja, nu göra något vettigt.
..och ska man vara riktigt skitnödig så är den virtuella adressrymden på x86-64 "bara" 2^48 bytes stor, "256 terabyte borde vara nog för samtliga". ;)
ReplyDeleteJag säger wooord! ;)
ReplyDeleteWhile jag accepterar att du har rätt så tycker jag ditt exempel suger (;-), no offence osv ..) :p. Det finns ingen direkt koppling mellan C och maskinkod. Man hade lika gärna kunnat tänka sig att även char variabler är 32bits alignade i minnet (även om det inte är så).
ReplyDeleteFör övrigt kan jag bara säga:
iPod nano 4 GB svart (anpassad)
Artikelnummer: PA107
failureisnotanoption
bus[iy]nessasusualteam
Skickas vanligen: 5 dagar
Shit Gurra, du har fel(!), skapar du en char-array i C är du garanterad att de ligger direkt påföljande varandra, utan padding, dvs byte för byte. Sen vadå ingen koppling mellan C och ASM, så satans mycket mer än ett avancerat macrosystem för ASM är faktiskt inte C. Helt ärligt.
ReplyDeleteiPod nano låter sweet, fränt med 4GB stora flashminnen, glöm inte att tanka in lite the Bash på den, vettja.
Det hade inte gått åt alls lika mycket ram att ladda in fancy om det inte hade varit för en lång och väldigt intressant artikel om x86_64 ;)
ReplyDeleteAngående iPOD så säger jag bara det här.
Analog studio -> 2-tumsband -> Vinylskivor -> C60-band -> Sony Walkman WM-EX304.
Antal AD/DA-omvandlingar: Noll stycken
Digitalt brus: Nada
Speltid: (60 eller 90 minuter) X (så många band som får plats i handväskan)
Rock'n'rollfaktor: Elva av tio
...och dessutom. Om man får slut på batterier i sin iPOD kan man inte spola tillbaka flashminnet med en penna. Om flashminnet skulle gå sönder kan man inte tejpa ihop det igen och fortsätta spela. Flashminnen går inte att vända på, så det får bara plats hälften så mycket musik som på ett band.
Världen är analog. Digitala avbildningar är bara dåliga kopior
Nu orkar jag inte argumentera mer. Jag vet att jag är bäst och att jag har rätt, det är ett problem när du vet det också .. :P
ReplyDeleteInstämmer med Burt och Gurra a'la Andreas; wooord! =)
ReplyDeleteden här texten är ett norskt virus
ReplyDeleteskicka den till alla du känner och ta sen bort alla filer på din dator
Eller som di säger i Värmland.
ReplyDeleteDi får INT gör sa, dä fatter väl vem som hälst dä.
En kan INT håll på mä sånt dret, ni får fan slute mä dette programeringa. Dä ä INT nöttit. Å framförallt, dä hetter inte bitar, dä hetter BETAR. Dä fatter väl vem som hälst dä, ta å assörtö den hele diskussion och flötte den in i dä däringa minnes registre såm ingen allåkering kan kåmme åt.
Gå te tie