On Wed, Mar 09, 2011 at 05:50:12PM +0100, Gábor Lehel wrote:
> On Wed, Mar 9, 2011 at 5:26 PM, Remi Turk <[email protected]> wrote:
> > 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.
> 
> That describes my situation. Thanks!
> 
> For the record, what units were your measurements in?
> 
> (I notice that the overhead of safe FFI calls seems to be pretty
> smallish, which is also quite heartening.)

Everything is in seconds. So for example, 2 million unsafe calls
to blub0 take 0.03 seconds: ~15ns or ~42 cycles per call
(including replicateM_ overhead).

I just noticed in my little non-scientific benchmark that the
overhead for safe calls is significantly higher when compiling
with -threaded:

       Unsafe FFI   Safe FFI   Safe dynamic FFI   CInvoke
blub0   0.04         0.36       0.35               2.27
blub1   0.05         0.36       0.36               3.52
blub5   0.05         0.37       0.37               5.72

unlink  3.26         3.21       3.56               8.41

Groeten, Remi

_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to