[Haskell] GHC 64bit?

[S. Alexander Jacobson]

Dell's poweredge server with the max 12gb RAM costs $15k.
Moore's law says that
1. you only need an extra bit/year.
2. processing that extra bit will cost 50% less next year

Though perhaps processing time is not linear with
the number of bits for historical/architectural
reasons....?

I presume that, if we are conservative in the
number of bits we use then we don't run into the
ptr driven storage problem that Axel described.

In particular, if we need only 2 or 4 times as
much memory, we should only grow pointers by 1 or
2 bits...rather than growing immediately all the
way to 64...

Perhaps there could be a command line option to
specify desired ptr size.  I assume it is
impossible to adjust pointer size dynamically at
runtime depending on memory consumption (I
assume you would do it at garbage collection time
if it were possible).

-Alex-

_________________________________________________________________
S. Alexander Jacobson                  mailto:me at alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com





On Fri, 13 Feb 2004, Simon Marlow wrote:

>
> > alex:
> > > Is there a maximum memory GHC can use/reach?
> > > Specifically, can GHC address more than 4gb of
> > > memory?
> >
> > SimonM may want to comment, but at the moment I think GHC is
> > limited to
> > 4G, but only due to lack of 64bit machines/demand on the developers.
> >
> > If you look in ghc/rts/MBlock.h you'll see some references to this.
> >
> > I *think* it would be easy to overcome this limit.
> >
> > (this should really be on glasgow-haskell-users)
>
> In principle, there's no problem.  In practice, GHC's storage manager
> needs a (fast) function of type
>
>    Ptr a -> Bool
>
> to indicate whether a particular address is part of the dynamic heap or
> not.  This is currently implemented as a bytemap, which is 4k long on a
> 32-bit machine.  To cover the whole of a 64-bit address space, this
> method isn't practical.  Nevertheless, we can extend the bytemap to
> cover a lot more real memory, as long as we have a way to map from
> virtual memory addresses to elements of the bytemap - this is the tricky
> bit.  So far we haven't tackled this problem in a general way.
>
> Cheers,
> 	Simon
>