On Tue, Dec 12, 2006 at 12:00:38PM +0100, Gilles Gravier wrote:
> Well, it's good that you've found a case where, for you, 64 bit is 
> faster. That probably justifies the use of a 64 bit version of the OS 
> for you.

But what's the problem with using a 64-bit version of the OS by default
if there is no known performance degradation, and known performance
improvement?

I know you've claimed that there's some performance degradation in
an earlier post, but that seems to just be an assumption that since
pointers are twice as wide, things must be slower. I see no reason that
has to be the case though, seeing that amd64 is a 64-bit architecture
and is designed to manipulate 64-bit quantities. In fact, not that
this example is directly applicable, but there are certainly cases
where using fewer bits makes things much slower: IIRC, gzip on older
Cray supercomputers (around the Y/MP era) was slower than when running
on the average workstation of the day, since the Cray didn't have any
way of working with 8-bit quantities--you had to load a whole word
(64 bits?) and shift/mask to extract the 8 bits you wanted.

In the Windows world, a good reason to avoid the 64-bit version unless
you really need it is because the device driver support is still rather
lacking. That doesn't apply to NetBSD, and I see little reason to avoid
running NetBSD/amd64 if your hardware will support it. (The only caveat
I can think of is proprietary multimedia codecs that are only available
as Win32 DLLs won't work, but I think even that can be worked around by
running a 32-bit binary of the media player under COMPAT_NETBSD32).