[m-dev.] for review: passing boxed floats to pragma C code

[Zoltan Somogyi]

> Is that case really worth optimizing?
> It seems to me that tabling of floats would probably be fairly rare.

Any tabled predicate at presents incurs the overhead of one call to GC_malloc
per float output. This is a small number of predicates, but the relative
overhead is quite high.

> Given that this feature is easy to simulate in this manner,
> and that the need for it is rare (after all, the word_to_float()
> and float_to_word() macros are not part of the documented interface,
> so they can only be used within the Mercury implementation),
> I'm not convinced that it would be worth complicating the C code
> interface with this feature.

The complication is quite small; just one extra field for pragma_cs in the
LLDS. I was not proposing to document the new attribute, so it is no
complication at all for users, and I was not proposing changing the MLDS.

The benefit is improved performance on benchmarks. Your proposed workarounds 
all have performance costs of their own, so they are not suitable replacements.

> For the MLDS back-end, we pass float arguments unboxed.
> So in many cases, this would not gain anything.

Since tabling does not work for MLDS, this point is moot.

> For the LLDS back-end, our long-term plan was also to eventually
> pass float arguments unboxed, in separate floating point registers.
> That now appears unlikely, since in the long term we will probably
> shift our focus from the LLDS back-end to the MLDS back-end.

Exactly. In the meantime, however, we get better benchmark numbers.
People at Dassault/Thomson should also benefit if they use tabling.

> I think it would probably be better to worry about correctness
> (e.g. getting tabling to work for nondet code) before worrying
> about optimizations for rare cases.

The two are not related. One can do these kinds of optimizations
while playing Civ 2 in the other window (I did); one cannot debug
model_non tabling while playing Civ 2 (although I did try :-).

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