On 21/09/2015 06:49, Artella Coding wrote:
Hi, thanks for the pointers on the ffi.
"I strongly suspect that SML functions like IntArray.update take less time
than the FFI overhead, so no improvement is possible by using C functions."
Yes it seems so. I was hoping that I could somehow achieve the extremely
low overheads that I get when using the haskell ffi (because I think ghc
haskell compiler also uses libffi ;
https://github.com/ghc/ghc/commit/39e206a7badd18792a7c8159cff732c63a9b19e7)
but it is not obvious how I can do that.
The foreign function interface is a very old design. The main
documentation dates from 1994. I updated it to use libffi but didn't
change the basic design. I would like to update it so that when a
foreign function is defined libffi builds the interface once rather than
on every call. It would probably be easier to start from scratch rather
than adapt the current CInterface structure.
Even if it is rebuilt there will still be significant overheads calling
through the FFI. It needs to switch between the ML and C calling
conventions and leave its ML stack and the ML heap in a safe state if
another thread causes a GC while a thread is in foreign code.
It seems that "val previous = IntArray.sub(data,i-1)" and
"IntArray.update(data,i,use+1);" are bottlenecks. For example the following
program :
It's most likely that the overhead has to do with bounds checking.
Arrays and vectors in ML are defined to raise the Subscript exception if
the index is out of range. A clever compiler could probably detect that
checks are redundant in this case and optimise them away but Poly/ML
doesn't do that. It's also more complex in Poly/ML because int is
arbitrary precision.
I ran a check replacing IntArray.sub and IntArray.update with versions
that don't do bounds checking and the time reduced from 48s to 27s. You
may be able to get some of the benefits if you can recast your program
to use some of the more complex functions in Array such as modifyi.
These avoid bounds checking since they can only be applied to the whole
array.
David
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
