FFI: c/c++ struct on stack as an argument or return value

[Yuras Shumovich]

On Wed, 2014-03-19 at 12:12 +0000, Simon Marlow wrote:
> On 18/03/2014 11:42, Yuras Shumovich wrote:
> > On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
> >>>
> >>> Library implementation can't generate native dynamic wrapper, it has to
> >>> use slow libffi.
> >>
> >> When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.
> >
> > Do you think we can remove native adjustors? I can prepare a patch.
> 
> I believe native adjustors are sufficiently faster than libffi to want 
> to keep them; at least that was what I found the last time I checked. 
> It might be the case that either libffi is now faster, or we could 
> optimise our libffi support enough that it isn't worth keeping native 
> adjustors.  I'd love it if that happened.
> 
> The benchmark I think I used is in nofib/smp/callback002.

callback002 is 10-15% faster with native adjustors then with libffi
(x86_64 linux, BuildFlavour = perf, mode=slow). Not a huge difference,
but it is noticeable.

Native adjustors:

6.53user 0.15system 0:06.69elapsed 99%CPU (0avgtext+0avgdata 2436maxresident)k
0inputs+8outputs (0major+894minor)pagefaults 0swaps
<<ghc: 32640054728 bytes, 58594 GCs (58592 + 2), 0/0 avg/max bytes residency (0 samples), 61418720 bytes GC work, 1M in use, 0.00 INIT (0.00 elapsed), 5.56 MUT (5.56 elapsed), 1.13 GC (1.13 elapsed), 1.13 GC(0) (1.13 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>>


With "UseLibFFIForAdjustors=YES" in mk/build.mk:

7.18user 0.10system 0:07.29elapsed 99%CPU (0avgtext+0avgdata 2440maxresident)k
0inputs+8outputs (0major+893minor)pagefaults 0swaps
<<ghc: 32640054728 bytes, 58594 GCs (58592 + 2), 0/0 avg/max bytes residency (0 samples), 61418720 bytes GC work, 1M in use, 0.00 INIT (0.00 elapsed), 6.21 MUT (6.21 elapsed), 1.08 GC (1.08 elapsed), 1.08 GC(0) (1.08 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>>


However, as Sergei Trofimovich mentioned, we use native adjustors only
on i386 and x86_64. So rts/AdjustorAsm.S and half of rts/Adjustor.c
seems to be a dead code. Unless someone has "UseLibFFIForAdjustors=NO"
in his mk/build.mk.

Thanks,
Yuras

> 
> Cheers,
> Simon
> 
> 
> > It requires minor changes to cache ffi_cif structure. On desugar phase
> > for each wrapper we can generate fresh global variable to store cif
> > pointer and pass it to createAdjustor.
> >
> >>
> >>>
> >>>  From my point of view, at this point it is more important to agree on
> >>> the next question: do we want such functionality in ghc at all? I don't
> >>> want to waste time on it if nobody wants to see it merged.
> >>
> >> I still don’t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we’d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.
> >
> > OK, I don't buy it, but I see your point.
> >
> >>
> >> Manuel
> >>
> >> PS: I’d happily accept language-c-inline patches for marshalling structs.
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >