hbe02

So guess what happened? i bought the new notebook..its a tablet HP 2170ee ... pretty cool AMD TL-68 x64-bit... what is outrageous is that the O.S installed was vista 32-bit!!! how can HP even do that!? im gona be buying 64-bit O.S... i gona go for xppro... do you think i should choose vista 64-bit instead?

Jabo

XP 64 bit has had many problems/bugs from what I've heard. I'd say go with Vista 64 bit, or stick with Vista 32 bit, as most programs are not geared to take advantage of 64 bit processing.

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?

lectricpharaoh

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:Now, imagine we have the same buffer, but want to do it faster: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.

__________________
A man's knowledge is like an expanding sphere, the surface corresponding to the boundary between the known and the unknown. As the sphere grows, so does its surface; the more a man learns, the more he realizes how much he does not know. Hence, the most ignorant man thinks he knows it all. - L. Sprague de Camp

hbe02

Great Explanation, thanks :-)

Jabo

Yeah, I bought into the whole 64 bit hype when I built my new pc, haven't really noticed that much improvement over 32 bit XP. Probably 95% or better of my performance increase came from better/faster hardware.

JAlexBrown

The laptop specs don't sound bad, but I'd suggest downgrading to XP. Vista is a resource HOG, and running Vista will eat your PC. Even if your PC could run multiple Visual Studio projects at once, it would run them much better in XP.