On 2009-10-18 20:01:26 +0200, language_fan <f...@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 <f...@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
