64-bit

Fawzi Mohamed fmohamed at mac.com
Mon Oct 19 04:22:34 PDT 2009


On 2009-10-18 20:01:26 +0200, language_fan <foo at bar.com.invalid> said:

> 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.
Probably you don't know x86 architecture well, it is register starved 
for modern standards, also with the 64 bit new instruction were added, 
on x86 the 64 bit change was not "add 64-bit pointers" but it was let's 
try to fix some major shortcomings of x86.
These enhancements are available only in 64 bit mode (to keep backward 
compatibility).

I know for a fact that my code runs faster in 64 bit mode (or you can 
say my compiler optimizes it better), and I am not the only one: for 
sure apple converted basically all its applications to 64 bit on snow 
leopard (that is focusing on speed), so that they are slower :P.

>  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.

cache usage is a real issue, but on the whole code is faster in 64 bit 
mode, at least in my experience

> 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.

not sure, see snow leopard...

> 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.

intel tried hard to avoid giving 64 bit in consumer processors (as it 
wanted to push IA-64), but failed and had to give what people wanted, 
in this case I think it was a good thing.

Fawzi




More information about the Digitalmars-d mailing list