On Thu, Sep 29, 2005 at 10:40:47PM +1000, O Plameras wrote: > The only change from 32-bit to 64-bit machine as far as > data type sizes are concerned is 'long'. Changed from 4 to 8 bytes. > This resolves the argument comprehensively. > > This means that there is going to be minimal improvements from > a 32-bit to 64-bit PCs. > > I had wanted to buy a 64-bit CPU, but with this I will defer. > I need to check that documentation re AMD64.
When thinking about why things are as they are, it's always good to consider the alternative outcome. Imagine if the size of int did increase to 64 bits. Firstly a lot of code would break. That's a bug, and would eventually be fixed after some initial pain. Suddenly every int variable now takes up twice as much space, every array of ints is twice as big. This means binary sizes increase and, more importantly, you waste a lot of your cache. How often does a loop counter overflow a 32 bit variable? To be sane people would have to reduce the size of variables they know won't overflow. So maybe you could make a short a 32 bit variable on your 64 bit machine. But now when people try to move their code between machines might find their counter becomes 16 bits, which is much more realistically overflowed. Now programmers have to be concerned about sizeof(int) and sizeof(short) to maintain portability. It would be a debacle. 64 bits is mostly about addressing; the times we need to cater for 64 bit variables that aren't addresses are limited. I'd still consider an AMD64; there are a number of architectural enhancements over x86. Of course if you want a real 64 bit architecture, pick up an Itanium from somewhere :) -i
signature.asc
Description: Digital signature
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html