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