[MLton-devel] nucleic benchmark times

[Stephen Weeks]

> I'm not convinced, although I'd lean towards MLRISC rather than C-- as a
> portable backend.

Don't forget that MLRISC is not written in SML and is effectively for
us written in a different language.

> But, it may be that we're caught in a chicken-n-egg problem: won't
> know until we try, won't try until we know.  The problem is, the
> cycle runs bigger than that.  MLton won't use MLRISC because they
> may not continue to support it.  MLRISC won't continue development
> because no one is using it.  MLton can't grow as fast as we'd like
> because there isn't support.  XYZ won't use MLton because it doesn't
> run on PPC.

Right.  So it seems to me that the right approach is to grow slowly
and safely, never backing yourself into a corner.  We simply can't
afford depending in any significant way on a project that may fail.

> Another suspected win is avoiding trampolining

I actually don't believe this.  To get terminology straight, there are
two costs in the C codegen: trampolining (jumping from one C function
to another via a return and then a call) and using integers for return
labels and switches on integers to return.  I don't think trampolining
is costly, because it doesn't happen that much.  Chunkification works
pretty well.  I have less justification for claiming that the cost of
using integers for return labels is small.  I believe it mostly
because MLton goes to so much effort to eliminate procedure calls and
create loops.  I think it at least means that we will see less
improvement from computed gotos than was seen in Gambit.

> I don't know if I have a real point, other than that dismissing portable
> backend projects out of hand is a little strong.

Fair enough.  They should always first be considered, and then rejected
:-).  (just kidding)

> but as we've discussed, you can't push the information we want
> through C to the backend.  You'd really need to hook into the
> compilation at a much later stage than is exposed (at least as far
> as I know).

Finding a way to hook into gcc at the right place, or convincing the
gcc developers to extend their IL so that that could be done, seems
like a much better direction to me than portable backends.  Said
another way, the right way to do a portable backend project is to use
as much of gcc's optimizer and codegenerator as possible.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel