Prevalence of 64Bit Vs 32Bit Platforms

Prevalence of 64bit vs 32bit platforms

On windows, 64 bit has been available since at least windows xp. However, it was not popular. I would call it a safe guess 99% of all xp systems out there are 32 bit. Why? You did not need 64 bit back then because systems did not have enough RAM to justify a different OS. By the time windows 7 arrived, RAM prices dropped to a point that 2 or more gb of RAM was mainstream. Computer manufacturers picked up on this and stated deploying 64 bit by default.

So the rule thumb is that windows xp is almost always 32 bit, and windows 7 is typically 64. That leaves vista dangling in the middle, but lucky for us, very few people run vista today.

I have seen recent popularity figures for xp to be of the order of 30%, so both 32 and 64 are strong.

Edit: According to this Microsoft blog, the picture for windows 7 is less black-and-white than I painted it above: 3 years ago, windows 7 64 bit penetration was only 46%. The article does note that on newly bought computers, 64 bit was dominant. I feel safe to assume that a large majority of Windows 7 machines today are 64 bit.

Determining 32 vs 64 bit in C++

Unfortunately there is no cross platform macro which defines 32 / 64 bit across the major compilers. I've found the most effective way to do this is the following.

First I pick my own representation. I prefer ENVIRONMENT64 / ENVIRONMENT32. Then I find out what all of the major compilers use for determining if it's a 64 bit environment or not and use that to set my variables.

// Check windows
#if _WIN32 || _WIN64
#if _WIN64
#define ENVIRONMENT64
#else
#define ENVIRONMENT32
#endif
#endif

// Check GCC
#if __GNUC__
#if __x86_64__ || __ppc64__
#define ENVIRONMENT64
#else
#define ENVIRONMENT32
#endif
#endif

Another easier route is to simply set these variables from the compiler command line.

Difference between x86, x32, and x64 architectures?

x86 refers to the Intel processor architecture that was used in PCs. Model numbers were 8088 (8 bit bus version of 8086 and used in the first IBM PC), 8086, 286, 386, 486. After which they switched to names instead of numbers to stop AMD from copying the processor names. Pentium etc, never a Hexium :).

x64 is the architecture name for the extensions to the x86 instruction set that enable 64-bit code. Invented by AMD and later copied by Intel when they couldn't get their own 64-bit arch to be competitive, Itanium didn't fare well. Other names for it are x86_64, AMD's original name and commonly used in open source tools. And amd64, AMD's next name and commonly used in Microsoft tools. Intel's own names for it (EM64T and "Intel 64") never caught on.

x32 is a fuzzy term that's not associated with hardware. It tends to be used to mean "32-bit" or "32-bit pointer architecture", Linux has an ABI by that name.

Will using longs instead of ints benefit in 64bit java

Using long for int probably will slow you down in general.

You immediate concern is whether int on 64 bit CPU requires extra processing time. This is highly unlikely on a modern pipelined CPU. We can test this easily with a little program. The data it operates on should be small enough to fit in L1 cache, so that we are testing this specific concern. On my machine (64bit Intel Core2 Quad) there's basically no difference.

In a real app, most data can't reside in CPU caches. We must worry about loading data from main memory to cache which is relatively very slow and usually a bottleneck. Such loading works on the unit of "cache lines", which is 64 bytes or more, therefore loading a single long or int will take the same time.

However, using long will waste precious cache space, so cache misses will increase which are very expensive. Java's heap space is also stressed, so GC activity will increase.

We can demonstrate this by reading huge long[] and int[] arrays with the same number of elements. They are way bigger than caches can contain. The long version takes 65% more time on my machine. The test is bound by the throughput of memory->cache, and the long[] memory volume is 100% bigger. (why doesn't it take 100% more time is beyond me; obviously other factors are in play too)

What is the purpose of setting the platform target for a Visual Studio application?

if I set this value to x86 does that mean I cannot run that project on a x64 machine?

No, 32-bit applications (x86) run just fine on 64-bit Windows (x64). All 64-bit versions of Windows include a 32-bit compatibility layer called Windows on Windows 64 (WOW64). This is usually what you want, in fact, as most applications do not benefit from being complied for 64-bit.

However, compiling for 64-bit (x64) does mean that your app will not run on a 32-bit (x86) machine. You can go backwards (64-bit can run 32-bit), but you cannot go forwards (32-bit cannot run 64-bit).

Compiling for Any CPU is always an option, as you point out. That will allow the application to run as a 32-bit application (x86) on a 32-bit machine, and as a 64-bit application (x64) on a 64-bit machine. This sounds like a panacea, but there are costs. Most notably, you'll need to test your application extensively in both 32-bit and 64-bit environments, whereas if you only target 32-bit environments (including 32-bit environments on a 64-bit host), you only have to test one build. And the additional workload is rarely worth it—most business applications do not benefit from the extra memory space of a 64-bit environment, and probably end up defeating any potential gains by the increased overhead of 64-bit pointers.

Visual Studio itself is a good example of an application that is fully 32-bit. There is no 64-bit version, yet it runs fine on a 64-bit host. This blog post helps to shed some light on why the decision has been made to keep VS 32-bit. You might find the reasoning helpful in making the decision yourself.

Likewise, although Microsoft Office is now available in a 64-bit package, Microsoft is still recommending that most customers stick with the 32-bit version. There are compatibility problems with the 64-bit version, and there just isn't much benefit.

Why is fPIC absolutely necessary on 64 and not on 32bit platforms?

As I understand it the problem is x86-64 seems to introduce a new, faster way of referencing data relative to the instruction pointer, which did not exist for x86-32.

This article has a nice in-depth analysis of it, and gives the following executive summary:

The ability of x86-64 to use instruction-pointer relative offsetting
to data addresses is a nice optimisation, but in a shared-library
situation assumptions about the relative location of data are invalid
and can not be used. In this case, access to global data (i.e.
anything that might be changed around on you) must go through a layer
of abstraction, namely the global offset table.

I.e. -fPIC addressing adds an extra layer of abstraction to addressing, to make what was previously possible (and a desirable feature) in the usual addressing style still work with the newer architecture.

The Double byte size in 32 bit and 64 bit OS

No, an IEEE 754 double-precision floating point number is always 64 bits. Similarly, a single-precision float is always 32 bits.

If your question is about C# and/or .NET specifically (as your tag would indicate), all of the data type sizes are fixed, independent of your system architecture. This is the same as Java, but different from C and C++ where type sizes do vary from platform to platform.

It is common for the integral types to have different sizes on different architectures in C and C++. For instance, int was 16 bits wide in 16-bit DOS and 32 bits wide in Win32. However, the IEEE 754 standard is so ubiquitous for floating-point computation that the sizes of float and double do not vary on any system you will find in the real world--20 years ago double was 64 bits and so it is today.

---

Related Topics