[m-dev.] for review: use type_ctor_rep for unify, index and compare

[Zoltan Somogyi]

Warwick wrote:
> Mainly just curious.  It seems to me that with things like this the 
> trade-off point could be different for different architectures, and I 
> wondered if there was one in particular you used to decide what was a 
> worthwhile and what wasn't.

Mostly I used ender because I could do speed runs on it without worrying
about interference from other users. However, given that we use so few
registers on x86s, the speed gain from avoiding the save/restore of the
Mercury abstract machine registers is smallest on that platform. Therefore
I think it likely that the speedup would be larger on Alphas, SPARCs, and
MIPS machines (if we still had any usable MIPS machines).

> I'm also currently beating my head against a wall trying to figure out why 
> our HAL benchmarks are running slower now than they were a few months ago.  
> It could be any number of things, but currently I suspect that I just 
> compiled the Mercury code and/or libraries with a different set of flags 
> then than I have now (e.g. turned some optimisations that I didn't think I 
> had or something).

Once upon a time, I added an optimization (I think it was a new peephole
pattern) that only ever deleted code, never added or modified any; a diff
of the C code generated with and without the optimization confirmed this.
Nevertheless, enabling this optimization made the code slower. This means
that something like a cache effect must have been responsible.

Maybe the same is true for the slowdown you are seeing. Or maybe the cache
on your CPU developed a fault, and the BIOS switched it off for you :-(
Don't laugh; things like that *can* happen.

BTW, I am just committing the change for adding a new option,
--checked-nondet-tailcall, that we discussed during my visit to Monash;
it has been sitting in one of my workspaces for several months. Please
try it out and see what impact it has on the speed and on the stack
consumption of HAL programs.

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