#13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari):
I have did some benchmarks​ here, my conclusion is that under concurent disk I/O situations, safe FFI can cause a slow down up to 50%.
I can't reproduce this result. I've checked out your benchmark and see the following, == unsafe == {{{ [1250 ben@ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m real 0m0.657s user 0m0.000s sys 0m1.035s [1251 ben@ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m real 0m1.766s user 0m0.000s sys 0m1.912s [1251 ben@ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m real 0m1.460s user 0m0.008s sys 0m1.570s }}} == safe == {{{ [1252 ben@ben-laptop diskIO(master)] $ time bin/safe-ffi 10m real 0m0.867s user 0m0.000s sys 0m0.966s [1252 ben@ben-laptop diskIO(master)] $ time bin/safe-ffi 10m ^[[A real 0m0.473s user 0m0.001s sys 0m0.636s [1252 ben@ben-laptop diskIO(master)] $ time bin/safe-ffi 10m real 0m0.794s user 0m0.009s sys 0m0.864s }}} If anything, it seems that `safe` FFI is dramatically **faster** than `unsafe`. Admittedly this is rather surprising, but I wouldn't expect a factor of two slower for this particular test. In the `safe` case `perf` confirmed that less than 3% of runtime was spent in `suspendThread` and `resumeThread` combined. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13944#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler