is ti worth going to 64 bit?

[mv]

[wcg]

memcmp() and memcpy() can process sizeof(long) aligned memory
regions 8 bytes at a time instead of 4 bytes at a time, for just one
non-double context where wider registers are an advantage.
Since applications can set up memory regions that they know
in advance they are going to need to memcmp() or memcpy()
to have that alignment when they are allocated, this will be a fairly
common speedup (times 2) for those operations in both the kernel
and in applications doing pretty much anything (I seem to recall
that the default alignment returned by glibc's malloc() is 8 bytes,
so that fits the requirement). Even interpreted code will benefit,
because the interpreter itself can be programmed to use sizeof(long)
aligned allocations where it uses memcmp() and memcpy() (the same
is true of comparable operations in other compiled languages than
C/C++/Objc, like Ada, Fortran, etc).
_________________
TIA

[depontius]

Now for a slightly different perspective...

In practical terms, if you need 64-bit, say to run VLSI CAD code that only comes in 64-bit form, then you just plain need 64-bit, and 32-bit is a non-starter. If you need 32-bit, say for the "win32codecs" package, then you just plain need 32-bit, but the issue is a little murky.

For me it came down to this: Most software developers these days live on 64-bit. The initial coding and debug is done on 64-bit, it's the most "live" version, and essentially gets ported back to 32-bit. I'd just as soon stay closer to the mainstream developers, so I run 64-bit. For my home use, everything else washes out, and it comes down to that. Oh, and at work I need to run 64-bit-only code, so that decision is a no-brainer.

I have 32-bit standard (not overylay) multilib, and that has been sufficient for my 32-bit needs. In the past I have run a 32-bit chroot for touchy 32-bit applications, but haven't had to do so in some time. The 64-bit situation just gets better with time.

Again, for home use it's not compelling, not even practical or non-practical, just "closer to mainstream development."
_________________
.sigs waste space and bandwidth

[Yamakuzure]

[Hypnos]

Google says:

http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks

These benchmarks are on Ubuntu, where the 32-bit systems are compiled for vanilla i686 and the 64-bit for x86-64 which is currently state-of-the art. However, machine-specific compiler optimizations don't account for the staggering performance boost of 64-bit on CPU- and memory-intensive applications.

If you're running a server, simulations or multimedia, 64-bit seems is a no-brainer. While 64-bit code does take considerably more RAM, for these applications you would have a fair bit of physical RAM anyway. And if you have an SSD for your executables, the difference in loading speed is negligible.

I think where most "regular" users would benefit from 64-bit is multimedia handling, e.g. you can playHD movies with less CPU overhead and less battery consumption, or encode media more quickly. Even games seem to get a boost, depending on the engine.
_________________
Personal overlay | Simple backup scheme

[aCOSwt]

Hey... I found one good reason for running 32 ! (To date)...

wrapperless flash +vdpau