'import ccall unsafe' and parallelism

Christian Höner zu Siederdissen choener at tbi.univie.ac.at
Thu Aug 14 21:38:37 UTC 2014


That's actually a great idea, especially since the safe variants of the
calls are already in place.

* Carter Schonwald <carter.schonwald at gmail.com> [14.08.2014 23:10]:
>    have a smart wrapper around you ffi call, and if when you think the ffi
>    call will take more than 1 microsecond, ALWAYS use the safe ffi call,
>    i do something like this in an FFI i wrote, it works great
> 
>    On Thu, Aug 14, 2014 at 1:20 PM, Christian HAP:ner zu Siederdissen
>    <choener at tbi.univie.ac.at> wrote:
> 
>      Thanks,
> 
>      I've played around some more and finally more than one capability is
>      active. And indeed, unsafe calls don't block everything. I /had/
>      actually read that but when I saw the system spending basically only
>      100% cpu time, I'd thought to ask.
> 
>      One problem with this program seems to be that the different tasks are
>      of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7
>      elements inducing waits with the larger problem sizes.
> 
>      We'll keep the program single-threaded for now as this also keeps memory
>      consumption at only 25 gbyte instead of the more impressive 70 gbyte in
>      multi-threaded mode ;-)
> 
>      Viele Gruesse,
>      Christian
> 
>      _______________________________________________
>      Glasgow-haskell-users mailing list
>      Glasgow-haskell-users at haskell.org
>      http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140814/04040c92/attachment.sig>


More information about the Glasgow-haskell-users mailing list