Re: AMD response about Debian x86-64 port
On Fri, Jan 10, 2003 at 01:45:51PM -0600, Steve Greenland wrote:
> It's worth noting that this is not a universal truth. Compiling in
> 64-bit mode tends to increase both data and code size, which in turn
> tends to increase load time and cache usage. Whether or not this effect
> is significant relative to the gains provided by using 64 bit mode is
> dependent on the application and the system (i.e. everything :-().
>
> Now, simplicity and package porter sanity may just say "compile
> 64-bit unless there is a functional reason not to", but 64bit->better
> performance is not a forgone conclusion.
While I recognize that this is true, I'm not happy with the way we
handle archs like sparc64; namely reusing the 32-bit userspace. Many
applications will not benefit from 64-bit capabilities, however there
are packages that *will*. A good example is gnuchess; like most chess
engines it uses 64 bit integers as "bitboards". These are emulated in
software if the package targets a 32 bit userspace, as the debian
package does on sparc. Another example of a type application that
could benefit from 64-bit compilation is a database or anything else
that manages a lot of data. Debian should accomodate users who buy
database servers with 16GB of RAM and want that memory to be usable by
MySQL (for example), not just 4GB of it.
It seems like a waste to buy a 64-bit processor and only use 32-bit
userspace binaries. There are several packages which would clearly
benefit from 64 bit integers, and many others where the benefits are
not obvious but could be determined through benchmarking. I would like
to see a debian/control flag specifying which userspace would be
"best" for a package, but for some reason I don't think this will be a
popular idea.
Reply to: