[m-users.] Documenting univ data passing to and from the C FFI
fabrice nicol
fabrnicol at gmail.com
Fri May 21 03:21:07 AEST 2021
>> > "*Why do you need to pass univs across the Mercury-C boundary?*
>> *Why do you need to unpack them in C code?"*
>>
>> Performance issues.
> In other words, the output of your
> code should not be a value of type univ, but a value of a type like this:
>
> :- type r_to_mer
> ---> r2m_int(int)
> ; r2m_float(float)
> ; r2m_int_list(list(int))
> ; r2m_string(string)
> ; ....
>
> Mercury code operating on values of this type would be a lot faster
> than Mercury code doing equivalent operations on univs, because
> a switch is much faster than a type check.
>
> It would also be much simpler to implement, since all you have to do
> would be export to C some Mercury functions that take as input
> e.g. a float, and wrap r2m_float() around it.
Great Zoltan. I'm obliged you took the pain and time to look into the
issue this seriously.
Yes, I'll implement this all the more easily as the work in progress
already has this kind of "catch-all" type (I do not know how to term it
exactly, say univ-like). Then I'll run a benchmark and report back on
performance results.
Perhaps a word or two on the performance issues you mentioned about univ
would be useful as caveats in verses 3.1.2.3 or 11.4 or the Bible.
Fabrice
More information about the users
mailing list