
On Tue, Mar 08, 2011 at 01:01:58PM +0100, Gábor Lehel wrote:
On Sun, Mar 6, 2011 at 2:38 PM, Remi Turk
wrote: Where? Hackage: http://hackage.haskell.org/package/cinvoke
Cheers, Remi
Is there any information on how this (and libffi I guess) compare to GHC's FFI in terms of performance? Is it equivalent? Once you've loaded a function with loadSymbol and are cinvoking it with various arguments, versus a plain "foreign import" of the same.
Count on it having at least an order of magnitude more overhead. I did some simple test of calling the following three trivial functions (with constant arguments, and ignoring the return values, 2M times) and got the following timings: int blub0() { return 42; } int blub1(int a) { return 42; } int blub5(int a, int b, int c, int d, int e) { return 42; } Unsafe FFI Safe FFI Safe dynamic FFI CInvoke blub0 0.03 0.19 0.20 1.62 blub1 0.03 0.20 0.20 2.44 blub5 0.04 0.20 0.20 4.35 It's not that bad for functions that actually (try to) do something though. For example, trying to remove a non-existent file: unlink 3.06 3.04 3.27 7.15 If I remember correctly, libffi was slightly faster, but mostly thanks to the fact that I didn't make it exception safe yet. So if you care about performance and are able to directly use the FFI, you clearly should.
(Also, I assume cinvoke corresponds to the FFI's 'unsafe' calls, i.e. if the function tries to call back into the GHC runtime then Bad Things will happen, and it'll block threads on the same 'Capability' if it runs too long?)
Actually, it doesn't: Considering the rather large overhead of CInvoke itself, I just import everything 'safe'. Though to be honest I didn't actually test any callbacks into Haskell. Cheers, Remi