[MLton-devel] nucleic benchmark times
Mon, 11 Nov 2002 13:50:26 -0800
> 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.
MLton-devel mailing list