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
That's actually a great idea, especially since the safe variants of the
calls are already in place.
* Carter Schonwald [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
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> wro
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
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 <
> choe...@tbi.univi
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 chun
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 w
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
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 s
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 $ somethingUn
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 wrote:
>
> [ ... re -V0 ]
>> Thanks, this solved the problem.
>>
>> I would like
11 matches
Mail list logo
