[Shootout-list] Missing programs and score calculation (Was:

[skaller]

On Sun, 2005-09-18 at 14:08 -0700, Stephen Weeks wrote:

> You may be interested to know that MLton also does lambda lifting
> early, and I believe it is a significant contributor to MLton's
> effectiveness.

Indeed, I am interested (where's that 64 bit MLton? :)

> Regarding MLton this is not correct.  MLton uses traditional stack
> frames; that is, the frames are mutable, variable values are stored
> directly in the frames, and (nontail) procedure call pushes a frame on
> the stack by bumping a stack pointer. 

Ah, ok! Faster than Felix, which must malloc the 
stack frame -- Felix procedures are all threads.
Felix functions aren't threads and either malloc
the frame, or use the hardware stack (determined
by analysis), however in both cases the hardware
stack is used for the return address for C compatibility,
which prevents garbage collection (since the system
does not have control over the C stack layout, there
is no way to find gc heap pointers on it reliably).

As I understand it, the MLton system has its own
stack and uses a generational compacting collector,
which is vastly superior to Felix in the abstract.
In fact, it's the best model I have seen, given 
a preference for native code (i.e. ML code) over C/C++ 
object model compatibility. Indeed, the Felix model prefers 
C/C++ compatibility, but it is still difficult, so it
isn't at all clear to me at the moment the compromise
is worth it.

>  As to boxing, MLton uses
> momonorphisation to avoid much of the boxing one would find in a
> traditional polymorphic-language implementation.

Right. Felix currently does this too .. in fact it
monomorphises everything. Thus, the system currently
lacks any support for intensional polymorphism
(other than using the traditional C technique, namely
casting void* .. :)

> > On the other hand whole frames are cheap to manage,
> > but they cost more storage than individual variable management,
> > and failure to eliminiate dead pointers means the collector
> > has more work to do sweeping the heap.
> 
> This need not be a problem.  For example, MLton is quite careful to
> preserve variable lifetimes and make the liveness information
> available to the runtime.

How and why?

Clearly, on the 'why' front, this allows eliminating
more garbage. However, otherwise the main impact would
be earlier execution of finalisers (and later execution
of initialisers).

I could probably implement this too, but it would cost,
and I'm not sure what the real benefits are.. I'm interested
in your view on that.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net