- What is the difference between building a .NET project to target 32-bit or 64-bit?
- Are there computers that aren't able to run 32-bit programs and only 64-bit?
- Do x64 programs run twice as fast?
-
12Duplicate of stackoverflow.com/questions/607322/…, which I unfortunately can't flag because it's on SO, not Programmers.– Mason WheelerMar 3, 2011 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.– greyfadeMar 3, 2011 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 BeckettMar 3, 2011 at 20:24
-
3@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.– TMNMar 3, 2011 at 20:26
-
3@Mathew, do not underestimate the importance of a platform being backward compatible.– user1249Mar 3, 2011 at 20:58
|
Show 6 more comments
3 Answers
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.
-
11Not 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. Mar 3, 2011 at 20:39
-
-
3Particularly with reference-heavy .NET where everything is a pointer (reference). Mar 4, 2011 at 0:00
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.
answered Mar 3, 2011 at 20:55
-
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. Mar 3, 2011 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. Mar 3, 2011 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. Mar 4, 2011 at 16:53
-
1@Omega, every time you reference a complex object instance in a managed language you are using a pointer under the hood. Mar 6, 2011 at 22:22
The .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. Also latest .NET Language compilers produce much optimized code. JIT is also improved in recent years and now you can do Multi-core JIT optimization. Debuggers are also improved. Meanwhile, better and optimized code is produced for 64bit - based systems.
-
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).– MSaltersSep 17, 2012 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.– BadarSep 17, 2012 at 14:11
-
2You'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.– MSaltersSep 17, 2012 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.– BadarSep 17, 2012 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. Sep 17, 2012 at 16:09