[MLton-devel] nucleic benchmark times

[Stephen Weeks]

> Here's my situation (he says after mailbombing the MLton development
> list ...).

I agree with all that Henry and Matthew wrote.  I'll add my two cents,
and then we'll not bother you again until we understand what's going
on with nucleic or we make progress on 64 bit archs.  :-)

> It's also important to me that I, and/or some students, can actually
> *complete* the program---I tried it in Fortran as a graduate student
> around 1978, and I failed, I could just never get it debugged.  In
> object-oriented Scheme, it's almost transparent.

Hear hear!  Programmer productivity and correctness is the right
reason for choosing a language, provided the performance is good
enough.  A factor of two in runtime is unlikely to be a good reason in
almost all circumstances.

> 64-bit implementations are important to me (or at least, having arrays
> that are > 16 MB in size is important to me,

MLton doesn't steal any bits from array lengths, which are signed
integers.  So, on 32 bit machines, the maximum array length is 2^31-1.
MLton does require arrays (in fact the entire heap) to be contiguous,
so, you will hit virtual address space problems before you hit the
length limit.

> That's important to me, too, when I have 80 MB single-precision
> floating-point arrays as data sets.

Unfortunately, MLton only has double precision floating point.  One of
the items on our todo list is to add single precision.

> Suresh indicated he might be interested, sometime, in taking the
> central part of my numerical PDE code and translating it to ML to
> see what the performance is on MLton (that code doesn't need a
> 64-bit implementation).  I don't think ML will do significantly
> better than Gambit on that code, but, hey, I like surprises as much
> as the next guy :-).

My guess is that you're right, but I would still like to see the
experiment so we can have another real-world benchmark.  While much of
our focus in MLton is on performance, it is more on eliminating costs
of features (e.g. modules, functions, polymorphism) that might
otherwise discourage programmers from using them and hence decrease
programmer productivity.

> Now, some personal comments on how I see your approach.  It is not
> clear to me that you want MLton to be a production compiler, and not
> just a research project.

We do want MLton to be a production compiler.  By my definition, it
already is.  Henry's company uses code compiled MLton both on site in
their servers and at customer sites.  Another user has hundreds of
thousands of lines of code compiled by MLton and sold as a commercial
product.  Another user has developed and sold games compiled by MLton.
We are actively trying to grow our (commercial) user community.

MLton has only been available since March 1999, so it is unsurprising
that our user community is small.  Nevertheless, it is already the
case that its demands outstrip our resources.  So, two of the most
important things that we do are to try to attract new developers and
to decide which projects to pursue.  Hence, my attempts to recruit you
(or your students) to help us with 64 bit.

When we decide not to pursue a project at any given time, the correct
conclusion to draw is not that we think that it won't improve MLton;
rather, it is to conclude that we think it will improve MLton less
than the other projects that we are working on.  In the case of the C
codegen, your suggestions were very helpful, and in particular the
information that the gcc bugs had been fixed means that we will likely
try computed gotos again when we port to a new architecture.

> My approach has been to bug Feeley to improve Gambit, bug Queinnec
> to improve Meroon, and, later, bug the gcc developers to improve
> gcc.  And, to some extent, I've been successful in all three
> instances.  Sometimes I had to wait a long time ...

We hope to be added to your list of someday.

> (I find it kind of ironic that MLton is using C more or less as a
> typeless language, much as one might naively translate Scheme into
> ML using a single unified type.)

While we could do a better job with C types, some casting is
unavoidable because the C type system is too weak to express things
like stack usage.

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

> (Suresh mentioned interest in a native MLton backend for x86-64;
> where will MLton be in the unlikely event that the Itanic is the
> winner of the 64-bit processor battle? Do you guys really want to
> write a VLIW back end for MLton?)

Doubtful.


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