[m-dev.] benchmarks for finite domain solvers with --generate-trail-ops-inline

Julien Fischer juliensf at cs.mu.OZ.AU
Fri Dec 16 18:53:53 AEDT 2005

Here are the results of using the new `--generate-trail-ops-inline' option on
the finite domain solvers in the g12 repository.  On the basis of these
results (+ the ones for the compiler) I think we should make
generate-trail-ops-inline the default.

`libcall' is the existing method of implementing trailing (by inserting calls
to library predicates).  `inline' is using the new option.  LLDS grades are
always effectively `inline' since in those grades trail ops have always
been emitted directly during code generation.

	hlc.gc.tr (libcall)
	size: 2336584
	time: 6277

	hlc.gc.tr (inline)
	size: 2344776
	time: 4521

	hl.gc.tr (libcall)
	size: 2332488
	time: 6007

	hl.gc.tr (inline)
	size: 2352968
	time: 4674

	size: 3161772
	time: 4772

There are a couple of things to note here.  Firstly hlc.gc.tr with trail ops
inlined is about 5% faster than asm_fast.gc.tr.  This is consistent with the
recent benchmarking that Samrith has been doing on the compiler, where hlc.gc
and hl.gc have been consistently faster than asm_fast.gc.

Secondly, (and I'm not sure why this is happening), hl.gc.tr is quite a bit
faster with the library call method, but the results swap around when inlining
trail ops.  I checked that one several times and the result seems genuine, i.e
it's not the machine doing funny things.

On a related note, I haven't tried running the above tests with trail usage
analysis enabled, so it's also possible there may be some improvement there.

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

More information about the developers mailing list