[m-dev.] where the .NET compiler is slow

[Peter Ross]

On Thu, Feb 27, 2003 at 09:06:30AM +1100, Fergus Henderson wrote:
> On 26-Feb-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > On Wed, Feb 26, 2003 at 03:20:19PM +0100, Peter Ross wrote:
> > > The significantly slow area is dead predicate elimination (phase 02b).
> > > In particular the deletion of all the pred_infos from the
> > > predicate_table.  I am currently about to test a change where rather
> > > than deleting everything from the table we build a new table from
> > > scratch.
> >
> > Using the suggestion the code runs about twice as fast.  The diff is on
> > the way.
> 
> Well, for `mmc --intermodule-optimization -C hello.m' I would certainly
> expect that change to speed it up.  But that's a somewhat skewed benchmark.
> Does it improve performance on larger benchmarks, compiled without
> `--intermodule-optimization'?
> 
The call to dead_pred_elim only occurs when --intermodule-optimization
is enabled.  See mercury_compile.m.

I am currently testing it on larger builds.  However my assumption is
that --read-opt-files-transitively pulls in a lot of preds that aren't
used so you end up eliminating a lot of preds.  Thus you start with a
huge predicate table which you remove most of versus the other option
where you build a small pred table looking up only relatively few
members of the larger pred table hence the significant speed up.

I did have a small play around with comparing the number of needed
predicates versus the number to be deleted when deciding how to adjust
the pred_table. However calculating the number of preds to be deleted is
also a reasonably time consuming operation.  I suspect the best option
is to record in the pred_table itself its size (in fact the next pred_id
is probably a sufficently good estimate) and then one can quickly
compare that with the number of predicates to be kept if they are
roughly the same then deletion should be quicker otherwise building from
scratch probably is.

Pete



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