[m-dev.] MLDS back-end bootstrapped!

[Fergus Henderson]

On 12-May-2000, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> 
> Congratulations!  Is it a boy or a girl?

Well, I think it reproduces asexually, so I guess that would
make it neuter ;-)

> (You must have known such a post would bring these questions:)  Any feeling
> about ultimate runtime performance relative to the current compiler?

Not yet.  So far I've just been concentrating on getting it working,
and haven't done much work on optimization.  I've been building it
with `-g -O0', which means I don't have much concrete information yet
about how it will perform with optimization enabled.  Also there are
some quite important optimizations which are still not yet implemented
for the MLDS back-end, in particular:

	- optimization of static ground terms
	- making use of a gcc extension (`return' for void-valued functions)
	  to help gcc optimize tail recursion
	- changing the runtime startup code so that in MLDS grades
	  it doesn't allocate the LLDS data areas 
	  (this has a big effect on speed, not just memory usage,
	  since the conservative collector scans those areas)
	- better code generation for switches

as well as a few others that are probably less important, such as

	- middle recursion optimization
	- avoiding unnecessary boxing/unboxing for class method calls
	- inlining and simplification at the MLDS level
	  (gcc can do inlining itself, but it won't be able to
	  optimize away box/unbox pairs; we need to do that ourselves,
	  and hence we may need to do inlining ourselves at the MLDS level
	  to expose opportunities for such simplifications)

Right now I'm still concentrating on correctness.  There's still three
or four outstanding bugs that I know about (e.g. a couple related to
the handling of `float', which doesn't get used much in the compiler,
as well as the dependency problem I mentioned in my earlier mail),
I haven't tested it with intermodule optimization or mmc optimization
levels greater than the default (-O2), and there's also a bit of work
required on integration issues such as modifying the Mmake
installation rules to work with the new back-end and modifying
`configure.in' so that the installation process builds and installs
the new grade.

> Last I
> heard, it sounded like it was faster for some things, a bit slower for
> others, and seemed likely to be a bit faster overall.

Yes, that's still the current status; I don't have much hard data to
back that up yet.

> Also, I know you had
> to shepherd it through building, but do you have a felling yet about compile
> times vs. the current compiler?

Quite a bit slower, when the MLDS compiler was compiled with `gcc -O0',
but that doesn't say much.

> Finally, how big is it stripped?  26 megs
> is a bit heavy; the mother must be exhausted!

It's 6.5M stripped, but again that's compiled with `gcc -O0', so it
doesn't say much.

Probably sometime in the not too distant future I'll do some more
detailed benchmarking and post the results.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------