Bagley shootout. Was: Lightningspeed haskell

John Meacham
Fri, 2 Mar 2001 02:48:13 -0800

A feature I have always wanted in ghc was the ability to compile a
program with NO heap allocator/ GC whatsoever. basically I want the
program to grab large chunks of memory from the OS with 'sbrk (or
mmap or whatever) and just give out pieces of it as they are requested.
no GC, no keeping track of whats been allocated, just increment a
pointer to the new allocation point and return the old one..
I want this for a number of reasons:

it would be useful when figuring out what the cost of the heap overhead
is, it would be something of a control case when comparing algorithms.

believe it or not, never freeing anything or keeping track of memory is
a valid GC tactic when you can guarentee your program will run in a
finite amount of time and perform a finite amount of heap allocations in
order to acomplish its task (and your OS properly cleans up when
processies exit). (think simple preprocessors, read, modify, spit out,
exit., or mathematical programs which may take a long time to run but
eventually terminate with a useful result. (testing primality of a
single number perhaps)) 

I imagine a good portion of the size of resulting executeables is in the
runtime support routines. it could be used to create ultra small
programs if most of the runtime could be omitted. 

it would be neat to play with.

just a random thought.

On Fri, Mar 02, 2001 at 11:26:06AM +0100, Jan Kort wrote:
> Unless ghc is extremely fast at filling a heap, it's the memory
> allocation. I get 11.8 seconds for ghc with a standard heap and
> 7.3 seconds when I give it enough heap not to do garbage collection.
> Since this is 200M, I don't think there is much time to do
> anything else.
> The input is 2000000 bytes. So, this would be 40M worth of [Char]
> data, I guess lines and unlines make ehm 12*2*2=48M, so that's
> about 100M total. I guess the other 100M is used for function
> applications.

John Meacham
California Institute of Technology, Alum.