[gclist] 64 bit machines and conservatism
Mon, 15 Dec 1997 13:28:05 -0800
On Dec 15, 1:51pm, Marc Feeley wrote:
> However it is unrealistic to double the space requirements of an
> application unless there is a really really compelling reason to do so
> (i.e. more than "look... by dereferencing this pointer I can change
> the settings on my grandma's toaster!"). A more practical approach is
> to somehow segragate 32 bit pointers (local stuff) and 64 bit pointers
> (possibly remote stuff) so that 64 bit pointers only show up in a few
> places. I bet that for most applications the 32 bit pointers
> will far outnumber the 64 bit pointers.
The tradeoffs here actually seem fairly complex to me. Different vendors seem
to handle them differently. There's a lot to be said for a unique pointer
size. You only need one set of libraries, and you don't get the win16/DOS
near/far pointer mess.
There are also some situations in which 32-bit local addresses are not enough.
My impression is that database benchmarks are routinely run on machines with >
4GB primary memory. I suspect a reasonable number of numerical problems also
fall into this category. At $10/MB, 4GB is $40K, which is not at all
unreasonable for a large application. And for PC-style memory, the price is
much less than that. (Of course you can't put 4GB in the average PC, yet.) If
you want to use a single set of libraries and development tools and you want to
target such applications, then local pointers should be longer than 32 bits.
I still suspect that anything near a 4GB garbage collected heap is rare. But
that may not be the only thing you want to address.