On Sunday 21 January 2007 11:03, J Sloan wrote:
> Randall R Schulz wrote:
> > On Sunday 21 January 2007 09:44, J Sloan wrote:
> >> ...
> >>
> >> 32-bit suse can run on x86_64, but not ia64. It's unlikely that
> >> you have ia64 hardware, so the answer is most likely yes.
> >>
> >> Just curious why you'd want to do that though.
> >
> > Possible reasons:
> >
> > 1) Fewer problems with plug-ins.
> > 2) Better performance for many applications or classes of
> > applications.
>
> 1. My x86_64 installs defaulted to 32bit browsers, ergo no plugin
> problems.
>
> 2. On my main workstation, glxgears got 10,000 frames/sec with the
> x86_64 install, and 7,000 frames/sec with the i386 install, a
> noticeable difference.
For my personal needs, that kind of graphics performance is completely
irrelevant. I don't do any 3D work at all.
> Being able to move memory around in bigger chunks can really help
> things like database performance too.
All that 64-bit-per-word transfers do is change the ratio of number of
instructions executed to the number of bytes transferred. But CPU
speeds continue to outstrip memory speeds, so that distinction does not
yield so much of a difference as you might think.
In other words, the memory subsystem bandwidth is the dominant factor
and the processor's word size is not so important.
Remember, too, that every single virtual address synthesized and emitted
by the processor is 64-bits wide in a 64-bit mode, and for the large
majority of applications, that's a whole lot bits that are always zero
being shipped around. Since pointers are common in C, C++, Java, Perl
and just about every modern language, there's a whole lot of
unnecessary data movement when manipulating these pointers / addresses.
> *Having* to move data around in
> bigger chunks might not be as helpful for some scenarios, but I can't
> think of any. Got a specific example?
I did a lot of searching and reading on the 'net, most of it specific to
the Core 2 architecture ('cause that's the chip in my latest system),
and the only thing for which the 64-bit mode was advantageous was media
encoding and decoding. In particular, Java seems to be strongly
advantaged in 32-bit mode, and I do a lot of CPU-intensive Java work.
> Joe
The bottom line is that unless you have a _specific_ requirement for
64-bit operation (address space being the primary one), you're probably
better off sticking with a 32-bit installation.
Randall Schulz
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
