[Haskell-cafe] Re: Re: Hugs vs GHC (again)was: Re: Somerandomnewbiequestions

[John Meacham]

On Sat, Jan 15, 2005 at 07:56:03PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> Pete Chown <1 at 234.cx> writes:
> 
> >> of course, [mmap] can only be done on a limited type of file on some
> >> architectures, so it should be an optimization under the hood rather
> >> than an exposed interface.
> >
> > In particular, you have to be careful not to run out of address space on
> > 32-bit architectures.  If you try to do file access by mapping the whole
> > file into virtual memory, you won't be able to handle files larger than 2G
> > or so.  You also have to be careful not to map a number of file chunks,
> > which in total exceed the address space available.
> 
> Which means that it *should* be explicit, rather than done under the
> hood. It's a tradeoff, the programmer should be aware when to apply it,
> the runtime should not impose a policy which would be hard to reverse.

I was thinking of it as a better implementation of a stream interface
(when available). a user-visible mmap facility would also be good but
unrelated. In any case it is purely an implementation issue and not very
relevant to the discussion (as long as we don't mandate anything that
would rule out alternate implementations, which would be tough to do
since we have to marshall between haskell and something else anyway). 

some papers on the subject for those that are interested are:

Exploiting the advantages of mapped files for stream I/O
 http://www.cs.toronto.edu/pub/reports/csrg/267/267.ps

IO-Lite: A Unified I/O Buffering and Caching System 
 http://www.cs.rice.edu/CS/Systems/ScalaServer/io-lite-tocs.pdf
(this one talks about an alternate OS interface to files which we might
want to take advantage of if available)

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈