Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know this is a little funny question, but I didn't have the chance to realize what makes any difference when programming x64 or x86 at high level languages (.NET for instance).

Any explanations would be appreciated.

share|improve this question
10  
Duplicate of stackoverflow.com/questions/607322/…, which I unfortunately can't flag because it's on SO, not Programmers. –  Mason Wheeler Mar 3 '11 at 19:19
3  
@Matthew Read: Itanium failed spectacularly in the marketplace because the ISA was notoriously difficult to write compilers for. The HPC market had all but given up on it long before AMD introduced their extensions. –  greyfade Mar 3 '11 at 20:24
4  
@Mathew you could say that about Intel! If it wasn't for backward compatibility we would be working on CPUs with sane instruction sets and network byte order –  Martin Beckett Mar 3 '11 at 20:24
2  
@Matthew: Have you ever looked at the Itanium instruction set? What a nightmare! Moving instruction scheduling out to the compiler was a Bad Idea. If you want a good 64-bit model, look to DEC's Alpha. –  TMN Mar 3 '11 at 20:26
2  
@Mason - that has been happening a lot lately. I suggest going to SO and flagging all these questions to be moved! –  NickC Mar 3 '11 at 21:19
show 5 more comments

3 Answers

up vote 4 down vote accepted

The only real difference you'd notice when using a HLL is going to be code size, and discovering that some features/libraries aren't available for x64 yet. Oh, and x64 code tends to be less performant, at least under .NET. The app I'm working on runs about 20% faster when I compile for x86. I don't know if it's because I use more bus bandwidth moving 8-byte quantities around, or if there's some "chunking" going on to adapt 32-bit APIs to 64-bit.

share|improve this answer
9  
Not so much the bus bandwidth of the moves as the fact that if you deal with 64-bit quantities vs. 32-bit, you've effectively cut your cache sizes in half. –  Brian Knoblauch Mar 3 '11 at 20:39
    
@Brian: Excellent point, I hadn't thought of that. –  TMN Mar 3 '11 at 20:49
3  
Particularly with reference-heavy .NET where everything is a pointer (reference). –  Dean Harding Mar 4 '11 at 0:00
add comment

At the level you are talking about (.NET) there is very little difference. When you are using completely managed code the JIT will automatically compile your code and it will work pretty much the same, with different performance characteristics. For some things it will be faster (processing a lot of data, data could be processed in 64 bit chunks, more registers available etc), and for others slower (64 bit data (ie pointers) is slower to load into the cache for starters, meaning more data and slower transfers from main memory).

You only really have to worry about the difference when you use unmanaged code. This blog has a good run down of the issues.

share|improve this answer
    
You don't have 64bit data unless you specify it. Pointers are promoted to 64bits, but ints and floats stay the same. Almost all 32bit systems support 64bit float (double), and many supported 64bit int (long long). 64bit also opens up the newer features, including more user visible registers. –  Omega Centauri Mar 3 '11 at 22:31
    
@Omega, Pointers are data. They have to be moved in to the cache to be used. Running on 64 bit means that every reference or dereference could potentially move one or more of these in to the cache, and it also expands every object that contains references. But you are correct that the statement halves is incorrect. I will change that. Thanks. –  DominicMcDonnell Mar 3 '11 at 23:33
    
In my experience pointers aren't very common. But I don't do OOP, and I had a really painful early experience with bad pointers, so I only use them when absolutely necessary. So IMO pointers don't take up very much address space. OTOH modern compilers generate lots of loop unrolling, loop peeling and special case code, so the code size can become quite large. –  Omega Centauri Mar 4 '11 at 16:53
    
@Omega, every time you reference a complex object instance in a managed language you are using a pointer under the hood. –  DominicMcDonnell Mar 6 '11 at 22:22
add comment

There are actually three processors:

  1. x86 - 32bit systems. They support less than 3.5GB RAM.

  2. x86-64 - an extenstion added to a 32bit processor to make it able to access more than 4GB memory. It supports vatly larger virtual and physical address spaces than are possible on x86, thereby allowing programmers to conveniently work with much larger data sets.

  3. Itanium - 64bit (a pure 64bit processor)

With the proper hardware and compatible software, 64-Bit wins every time. So, .Net Programs that will be written for 64bit systems will have larger address space, and so will be much faster than x86-32 bit based programs. But their market share is not much. 64bit systems are still new, and the software being used on them is either 32bit or written after tweaking compiler and optimized for 64bit systems so that it can run faster.

Edit: 64bit CPUs are new. They have been here for over 2 decades. Wikipedia confirms this. Now market has been very stable for them. Actually CPU is not everything. When a program is written in a particular environment like .NET, it can affect the performance of the program.

So, on the efficiency of a program, three things can affect: 1. CPU architecture 2. OS 32/64 3. Implementation of the Compiler (whether 32bit compiler is better written and optimized or 64bit one).

I have seen many people use 32bit windows running on 64bit systems.

share|improve this answer
    
Not really. As the top comment referenced over a year ago, x86-64 has a vastly better register set and cannot be considered an "extension". Next, address space doesn't make programs faster. Then, their market share. 64 bits is currently leading, 32 bits the minority (Steam inventory, Aug 2012). –  MSalters Sep 17 '12 at 13:27
    
This (en.wikipedia.org/wiki/X86-64) says X86-64 is an extension of x86. May be address space does not affect programs run slow directly, but can affect memory which will make program run slow. In 64bit systems development, you may have few more jobs but not a big figure. For job market don't just see advanced countries but take third world countries into countries too. For good reference, check out: arstechnica.com/features/2008/09/x86-64. –  Badar Sep 17 '12 at 14:11
1  
You're quoting a 4 year old article. There are virtually no 32 bits x86 processors produced today, in 2012, and that incldues the low-end CPU's aimed at third-world countries. –  MSalters Sep 17 '12 at 14:15
    
In 3rd world countries, which is a large proportion of the world population, they use these system regularly. Even though new systems do come, but rate of purchase is not good as compared to mobile systems. –  Badar Sep 17 '12 at 14:17
    
@Badar Doubtful. I see 64-bit processors for low and mid-range computers here in Latin America. I tend to agree 32-bit CPUs are gone, at least for desktops and mid-range laptops. –  Andres F. Sep 17 '12 at 16:09
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.