[MLton] Re: [MLton-user] FFI and pointer relocation

[Matthew Fluet]

On Tue, 27 Nov 2007, Wesley W. Terpstra wrote:
> On Nov 26, 2007, at 11:10 PM, Matthew Fluet wrote:
>> > For now I'll just allocate the cell in C and export a C function to check 
>> > if the cell has changed.
>> 
>> If there is only one cell (which can be statically allocated), then using 
>> MLton's  _address  (with the MLton.Pointer structure) or  _symbol  FFI may 
>> be more efficient.  There is a slight overhead in making a C call, and if 
>> you are simply checking the cell's contents, then the above can all be done 
>> without leaving (the generated) ML code.
>
> Why doesn't the current runtime use this trick, actually? I'm thinking of the 
> especially slow gettimeofday() (and NetHost/ServDB, etc).

I suppose one could use MLton.Pointer functions to fetch the tv_sec and 
tv_usec fields of the statically allocated struct timeval, though the 
overhead of making a C call is really the fact that one needs to move ML 
pointers to the stack, not leaving them in registers.  So, while there is 
some overhead of the subsequent C calls, it probably isn't that much over 
the initial call, especially since the gettimeofday is a system call. 
Also, you need to be robust against changes to the suseconds_t 
representation on different platforms, and the offset in the timeval 
struct.  So, I'm not sure the added complexity is worth it.

> On the topic of gettimeofday, isn't Time.time as an IntInf instead of an 
> Int64 a bit costly?

Not necessarily.  Small IntInf values (< 31 bits or < 63 bits, depending 
on the platform) are maniputated directly, with just a couple of bit 
shifts and arithmetic ops.  It is only if you need more bits that you need 
to use the GMP library code, which is itself pretty fast.

Also, to preserve nanosecond resolution in time values, you either need to 
use IntInf or two fixed integer values, and the added complexity of doing 
the appropriate sec/nanosec pair arithmetic.


So, there is probably some small benefit to be had from these ideas, but 
I doubt you would observe any speed up on the majority of SML programs. 
(Because Time.time manipulations are rare to begin with, and I've never 
seen them be a dominant factor in a program.)  And, there is an added 
complexity in the implementation.