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.
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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
