StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>what is the performance impact of making calls in to it</p> </blockquote> <p>Assuming you start the Haskell runtime up only once (<a href="http://www.haskell.org/haskellwiki/Calling_Haskell_from_C" rel="noreferrer">like this</a>), on my machine, making a function call from C into Haskell, passing an Int back and forth across the boundary, takes about <strong>80,000 cycles</strong> (<strong>31,000 ns</strong> on my Core 2) -- determined experimentally via the <em>rdstc</em> register</p> <blockquote> <p>is it going to be possible for me to keep that 20kB of data as a global immutable reference somewhere that is accessed by the Haskell code</p> </blockquote> <p>Yes, that is certainly possible. If the data really is immutable, then you get the same result whether you:</p> <ul> <li>thread the data back and forth across the language boundary by marshalling;</li> <li>pass a reference to the data back and forth;</li> <li>or cache it in an <code>IORef</code> on the Haskell side. </li> </ul> <p>Which strategy is best? It depends on the data type. The most idiomatic way would be to pass a reference to the C data back and forth, treating it as a <code>ByteString</code> or <code>Vector</code> on the Haskell side.</p> <blockquote> <p>I'd like to parallelize this</p> </blockquote> <p>I'd <em>strongly</em> recommend inverting the control then, and doing the parallelization from the Haskell runtime -- it'll be much more robust, as that path has been heavily tested.</p> <p>Regarding thread safety, it is apparently safe to make parallel calls to <code>foreign exported</code> functions running in the same runtime -- though fairly sure no one has tried this in order to gain parallelism. Calls in acquire a capability, which is essentially a lock, so multiple calls may block, reducing your chances for parallelism. In the multicore case (e.g. <code>-N4</code> or so) your results may be different (multiple capabilities are available), however, this is almost certainly a bad way to improve performance.</p> <p>Again, making many parallel functions calls from Haskell via <code>forkIO</code> is a better documented, better tested path, with less overhead than doing the work on the C side, and probably less code in the end.</p> <p>Just make a call into your Haskell function, that in turn will do the parallelism via many Haskell threads. Easy!</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload