On 16/12/2015 14:00, Artella Coding wrote:
Hi, so if my interpretation of the above is correct the timings shouldn't
be changing (i.e. one shouldn't be expecting the timings to improve)? The
benchmarks seem to indicate this. I modified the second benchmark in
http://lists.inf.ed.ac.uk/pipermail/polyml/2015-October/001673.html [the
one with "(* This uses new FFI *)" at the top] to the following, and the
time to compute was roughly the same :
***************************************************************************
***************************************************************************
open Foreign;
val mylib = loadLibrary "./intArray.so";
val c1 = buildCall1((getSymbol mylib "createIntArray"),cInt,cPointer)
val c2 = buildCall1((getSymbol mylib "destroyIntArray"),cPointer,cVoid)
val c3 = buildCall3((getSymbol mylib
"setIntArray"),(cPointer,cInt,cInt),cVoid)
val c4 = buildCall2((getSymbol mylib "getIntArray"),(cPointer,cInt),cInt)
val c5 = buildCall1((getSymbol mylib "getSumIntArray"),(cPointer),cInt)
fun c_createIntArray (size) = c1 (size);
fun c_destroyIntArray (p) = c2 (p);
fun c_setIntArray (p,elem,value) = c3 (p,elem,value);
fun c_getIntArray (p,elem) = c4 (p,elem);
fun c_getSumIntArray (p) = c5 (p);
Correct. You're defining the functions at the top level so there's no
problem. The problem with the old, curried, form was the temptation to
write:
call3 (getSymbol mylib "setIntArray") (cPointer,cInt,cInt) cVoid
(pData2,0,c_getIntArray(pData2,size-1))
inside the loop.
It's even more of a problem with passing functions because the old
mechanism of passing the ML function as an argument resulted in the
creation of a LibFFI closure for the argument each time the C function
was called.
David
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
