mallocForeignPtr vs. C
qdunkan at gmail.com
Mon Jul 12 21:49:59 EDT 2010
On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
>> Yeah, that's definitely the safest and simplest. But the copying
>> defeats the purpose of passing a pointer in the first place, which was
>> to not have to copy the giant array just to pass it.
> Well, if your C code wasn't squirreling away the pointer, you could have
> avoided the copy. Memory copies in C are suprisingly cheap; I'm really
> surprised how often I see memcpy() in high performance code (though, it may be
> the case that the details of the algorithm are a much more important influence
> on performance.)
>From some quick tests, copying 32 32mb chunks takes 0.5 seconds, which
is too much lag for interactive use, but only one is only around 0.01
seconds, which is not a problem. At the moment, I expect 32mb will be
an upper bound, so I think I can get away with copying for now.
However, I'm still curious about the funptr approach. Does a
"wrapper" funptr callback act as a GC root?
On Mon, Jul 12, 2010 at 4:26 PM, Felipe Lessa <felipe.lessa at gmail.com> wrote:
> ... I would try to avoid having the MVar/IOVar as a CAF because of its
> unpredictability. You can always encapsulate it as somewhere else
> (e.g. Reader monad).
Yes, I would prefer a non-horrible hack too, but it's tricky and
invasive to try to get a callback from C to haskell into the main
haskell state monad. I would have to send a "delete this key" msg
which the main loop will later pick up, which is certainly doable,
More information about the Glasgow-haskell-users