[Haskell-cafe] minimizing overhead between c/c++ and Haskell

Joshua Jordan josh3light at gmail.com
Thu Oct 8 19:10:57 UTC 2015


I've been learning Haskell recently and I'm interested in exploring whether
something I have in mind is feasible. I have several projects similar to
the one below, this is just one example:

I have written a plug-in for an existing software (which manages it's own
threading, memory, etc).  The plug-in interface is in c++ and is wrapped in
an extern c call for the final connection to the software.

The actual plugin is rather functional in nature, and at its core simply
accepts float, int, and string values, does a certain amount of internal
processing based on input criteria, and returns float values as a result.
I'd like to re-factor it one day, so instead of doing it in c++, it would
be interesting to rewrite my plug-in with the logic and structure (with
memoization, etc) of the internal processing in Haskell, which is called
from the other executable.  The processing will be called by the c/c++
threads many millions of times in one run, so perhaps the overhead of
separate processes and interprocess communication would be too great, and
I'd hope for minimal time overhead between the c/c++ and Haskell calls.

I imagine the process might go something like this, after looking over the
documentation (Using the FFI with GHC):

------------------------------
--------

-the c/c++ plug-in initializes the GHC runtime in a set-up step

-- begin call: repeated many millions of times
-the c/c++ threads call the haskell function
-the haskell function returns a value to the c/c++ threads
-- end calls

-after everything is finished, the c/c++ plug-in uninitializes the GHC
runtime

--------------------------------------

So before attempting this, my questions would be:
1)  What do you guys think the overhead in this situation would be?
2)  Would you suggest exploring anything besides what I've mentioned, and
am I missing anything?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151008/4a082137/attachment.html>


More information about the Haskell-Cafe mailing list