64-bit

[language_fan]

Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:

> On 2009-10-18 11:32:07 +0200, language_fan <foo at bar.com.invalid> said:
> 
>> Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote:
>> 
>>> I won't deny that for certain people 32-bit systems are still
>>> perfectly useful. Just my clients do not share this view for a series
>>> of good reasons. Even their older systems tend to be 64-bit nowadays.
>>> Migration towards 64-bit OSes is under way. There is still 32-bit
>>> compatibility if needed. At the same time certain programs will
>>> perform drastically better when compiled to 64-bit. Replacement thus
>>> can be postponed which is usually the best way to keep CFOs happy.
>> 
>> 64-bit programs often also require larger CPU caches to work
>> efficiently, more disk space (larger binaries), and finally larger
>> memory consumption. 32-bit x86 + PAE still works until you have more
>> than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop
>> use 32-bit feels like the best way to go unless 64-bit algorithms are
>> provably more efficient in the chosen task.
> 
> on x86 the 64 bit extension added registers, that makes it faster, even
> if as you correctly point out a priori just using 64 bit pointers is
> just a drawback unless you have lot of memory.

That is very silly claim. First, you need to have use for all those extra 
registers to obtain any performance benefits. This is nearly not always 
the case. Also note that cache size is heavily constrained and larger 
binaries will fill it with less code. This alone can make the code a lot 
slower on first generation and budget 2..4-core x86 machines with smaller 
cache sizes.

Main memory is expensive and you rarely can install more than 64 GB on a 
PC style hardware. Many times you can even split a task into separate 
2..3 GB processes quite easily. So the immediate advantages of 64-bit 
code are not that clear when you only need it to grow the processes 
larger. On Linux, for instance, ordinary 64-bit desktop requires a lot 
more memory than its 32-bit alternative. Why would you want to buy more 
hardware to fix something that can be fixed with existing software?

> Anyway I also need 64 bit (computational chemistry, speed and memory
> hungry), and to that the only thing that I can say is D1 works very well
> with 64 bit.

That's one domain where 64 bits may give you an advantage. In normal 
desktop applications there is often nothing in 64-bit code that can 
improve anything. I am talking about firefox / winamp / mediaplayer / 
photoshop / outlook / casual gaming use here.

Why I mentioned desktop applications is that currently the trend has been 
to replace old 32-bit intel/amd processors in desktop use. And most 
desktop apps are written in systems programming languages. You can hardly 
buy any non-64-bit capable processor from any pc store these days. The 
people are getting crap that they don't need.

The same thing happens with digital cameras. In cameras the pixel count 
of sensors is growing even though the image quality stays the same. A 
good quality 4 MPix camera is much better than a cheap 15 MPix pocket 
camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored in 
jpg format might look better than the original 15 MPix one in raw format. 
They just keep pushing the limits to sell larger and larger storage media.