Quote:
Originally Posted by hbe02
btw,for us as programmers... how do we make our programs take advantage of the 64-bit tehnology... does it mean we use variables that store more bits? like the int64 in the .NET framework?
|
The rule of thumb is to use the appropriate data type. If space is at a premium (for example, in a large array), use the smallest type that can hold your range. If space is not at a premium, use
int where possible, and a larger type if necessary. Trust the system to use the appropriate machine-level type. You're not going to see huge performance improvements by changing all your
int32 definitions to
int64 when migrating to a 64-bit system. Much of the speed-up will lie in the bowels of the OS or other system-level code, such as device drivers. When writing your code, especially if you're targeting a managed platform such as .NET or Java, trust that the implementation will do what's best (in most cases, it will, unless it's broken).
64-bit technology offers two main advantages. First is the ability to address more memory, by having a larger address space. For current consumer machines, this isn't an issue; few people have greater than four gigabytes installed, and for those that do, most can be managed on a 32-bit machine with addressing extensions.
The second advantage, and what really impacts the performance of software, is a larger data bus. Basically, this means that while data is still moved a piece at a time, the pieces are bigger. When moving large amounts of contiguous data, a wider data bus really becomes noticeable. It also means that if you're applying the same kind of transformation to data, you can often do it much faster by using larger data types. For example, say you wanted to mask every byte in a buffer with 0x0F. You could have a loop to do this:
// assume buffer is an array of char, of size BUFSIZE
for(int x=0; x<BUFSIZE / sizeof(buffer[0]); ++x)
buffer[x] = 0x0F;
Now, imagine we have the same buffer, but want to do it faster:
int64 *buffer_alias = (int64 *)buffer;
for(int x=0; x<BUFSIZE / sizeof(int64); ++x)
buffer_alias[x] = 0x0F0F0F0F0F0F0F0F;
The second loop will only have one-eighth as many iterations; on big loops, you can see that significant time could be saved.
Now, if you're moving data around by hand like that, you're probably going about it the wrong way. Odds are, there are library methods to do what you want, such as
memmove() or
memset(). These kinds of methods are (or should be) optimized for their target system, and will use the appropriate types for optimizing performance. If you try to outperform them by writing your own, you're likely a) wasting your time (it's unlikely you'll write better code than your compiler's library code authors), and b) often hurting performance (my example above using
int64 doesn't take into account an array that might not be a multiple of eight bytes in size, nor is it aware of data alignment issues, and as such, it might well perform far worse than the version above it). A less naive implementation would be testing the start address, possibly copying smaller pieces of data so as to reach an aligned memory location, then copying a run of the largest type, then possibly finishing off by copying smaller pieces again. It might determine that copying multiple differently-sized blocks like this is slower (for a particular block of memory, such as a very small one) than just copying it byte-by-byte to begin with; if this is the case, it should revert to a bytewise copy.
The other common arguments that some people say about 'you can store bigger values' and such are technically true, but largely meaningless for most applications. I mean, how often have you needed to store a 64-bit integer value, for use as a count or something similar? I never have, and even if I did, there are still 64-bit types available on 32-bit systems. These pair 32-bit values to hold a 64-bit one, just as 16-bit systems still had a 32-bit
long data type for their C compilers.
In short: the performance advantages of 64-bit systems for the average user are, in almost all cases, drastically overstated. Remember that the 64-bit label sells machines, and people want the newest because they perceive it as the best, whether or not it is. Are such systems faster? Yes. Are they twice as fast, across the board, as so many people are led to believe? Hell no. Are they worth it for you? Perhaps. Only you can decide this. However, you need to factor in everything, such as cost, compatibility with any legacy code you want to run, stability of the 64-bit version of your chosen OS (which has probably been in the field for less time than the 32-bit version, and is likely to be less robust as a result), power consumption (if you're looking for a loptop), and so on. Only then can you make an informed decision.