[Haskell-cafe] ANNOUNCE: cinvoke 0.1 released

[Remi Turk]

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 <rturk at science.uva.nl> wrote:
> > Where?
> > Hackage: http://hackage.haskell.org/package/cinvoke
> >
> > Cheers, Remi
> >
> > [1] http://www.nongnu.org/cinvoke/
> 
> 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