[MLton-devel] nucleic benchmark times

[Matthew Fluet]

> > There was talk about using different back-end toolkits for people,
> > like the mlton team, who want to concentrate on front-end issues,
> > including high- and mid-level optimization strategies.  That's fine,
> > but will these back-end teams continue to support their code? Will
> > it be ported to new architectures that come out?
>
> I agree that using those toolkits is a risky proposition.  This is why
> we decided years ago to not use MLRISC and C--, and continue to decide
> so today.  Even with all the problems of targeting C, I think it is
> still by far the best way to achieve portability.

I'm not convinced, although I'd lean towards MLRISC rather than C-- as a
portable backend.  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.  Etc.
Etc.  Presumably, though, gcc once itself faced problems like that.

Again, the other problem is that it isn't a short-term task to try and
tune another backend.  Nor is it trivial to extract the pros and cons of
individual decisions.  My belief is that a huge win in the native codegen
is the ability to assert that stack and heap locations don't alias.
(Actually, that would be fairly easy to check.)  Another suspected win is
avoiding trampolining (but, as Brad pointed out, this could probably go
away with computed gotos?).  After that, I think most other possibilities
for improvements are peanuts -- but there really isn't any way to tell.

I don't know if I have a real point, other than that dismissing portable
backend projects out of hand is a little strong.  I do think that gcc is a
"safe" proposition for portability, 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).

As a side note, I came across this comment by Simon Peyton-Jones in the
Haskell Communities & Activites report:
"Push-enter looks very attractive for lazy languages, but it has many
small costs scattered through the code generator and run-time system. For
one thing, it seems to be practically impossible to compile it into C--,
even though C-- was designed to be as flexible a code generator as
possible (http://www.cminusminus.org): we just couldn't think of a clean
way to design C-- to deal with push-enter. (Except by using C-- in the
unsatisfactory way we currently use C, namely ignoring the C stack and
using an explicitly-managed stack instead.)  So we have spent quite a bit
of effort rejigging GHC's back end and run-time system to use eval-apply
instead of push-enter."
Not that MLton uses a push-enter convention, but it's a mark against the
expressibility of C--.







-------------------------------------------------------
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