On 2009-10-19 15:04:23 +0200, language_fan <f...@bar.com.invalid> said:
Mon, 19 Oct 2009 13:22:34 +0200, Fawzi Mohamed thusly wrote:
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:
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
I believe in real world benchmarks more than in hollow words.
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?
You did not comment on this.. in desktop use cpu power rarely matters.
But running out of memory is pretty common (think about laptops with
limited amount of memory slots and expensive memory units).
I fully agree that for desktop 32 bit is enough, but selling it as
better is just misinformation (at least for x86).
Just look at the installs for ubuntu 64 bit vs 32 and you will see that
the difference is just a few %.
What uses lot of place is installing things twice (32 and 64 bit
version of the libs for example), if you have a pure 64 bit install
(like I do) then you do loose the possibility to run 32 bit binaries or
plugins that need 32 bit libs (like dmd :(), but the whole system is
not much larger.
In any case often what occupies most space isn't the compiled code but
other resources.
With this I will stop answering you, because I don't find it so productive.
Fawzi
