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:[EMAIL PROTECTED] 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 > _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell