Donn,
I was able to duplicate my problem in C using SIGVTALRM.
Can someone explain the impact of using -V0 ? What does it do to performance,
etc?
Mike
Sent from my iPad
On Aug 13, 2014, at 9:56 AM, Donn Cave d...@avvanta.com wrote:
[ ... re -V0 ]
Thanks, this solved the problem.
I
Greetings everybody,
I happen to be a bit confused with regards to unsafe foreign imports and
parallelism.
Assume the following C function:
foreign import ccall unsafe cfun
cfun :: CInt - IO ()
Now, cfun does some work:
go xs = unsafePerformIO $ do
forM_ xs $ cfun
return $
Hi!
On Thu, Aug 14, 2014 at 5:54 PM, Christian Höner zu Siederdissen
choe...@tbi.univie.ac.at wrote:
However, due to the way ghc handles unsafe imports, namely block
everything else whenever 'cfun' is called, I happen to have only one
active 'go'. Lets assume 'cfun' is cheap and would suffer
On Thu, Aug 14, 2014 at 11:54 AM, Christian Höner zu Siederdissen
choe...@tbi.univie.ac.at wrote:
go xs = unsafePerformIO $ do
forM_ xs $ cfun
return $ somethingUnhealthy
I wonder if this is your real problem. `unsafePerformIO` does some extra
locking; the FFI specifies a function
I'm no judge of what's true about safe and unsafe, but this account of
the system has at least to my ear the ring of authenticity:
http://blog.melding-monads.com/2011/10/24/concurrency-and-foreign-functions-in-the-glasgow-haskell-compiler/
The FFI section is short and readable.
With respect to
if your computation in the C call takes more than 400 nano seconds, the
overhead of the safe ffi convention is less onerous and you should do that
when applicable.
an alternative is so use forkOn to setup a worker thread on various GHC
capabilities, and have them in parallel work on different
I have to agree with Brandon's diagnosis: unsafePerformIO will
take out a lock, which is likely why you are seeing no parallelism.
Edward
Excerpts from Brandon Allbery's message of 2014-08-14 17:12:00 +0100:
On Thu, Aug 14, 2014 at 11:54 AM, Christian Höner zu Siederdissen
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
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 Höner zu Siederdissen
choe...@tbi.univie.ac.at
That's actually a great idea, especially since the safe variants of the
calls are already in place.
* Carter Schonwald carter.schonw...@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
glad I could help,
https://github.com/wellposed/hblas/blob/master/src/Numerical/HBLAS/BLAS/Internal.hs#L146
is
an example of the choose to do the safe vs unsafe ffi call trick
in the case of blas / lapack routines, i can always estimate how long a
compute job will take as a function of its inputs,
11 matches
Mail list logo
