On 21/01/2012 15:35, Sanket Agrawal wrote:
Hi Edward,
I was just going to get back to you about it. I did find out that the
issue was indeed one GHC thread dealing with 5 C threads for callback
(1:5 mapping) - so, the C threads were blocking on callback waiting for
the only GHC thread to be
On 21/01/2012 20:39, Edward Z. Yang wrote:
Excerpts from Edward Z. Yang's message of Fri Jan 20 23:44:02 -0500 2012:
If multiple assignment is rare enough in straight line code, I might
be able to take the conservative approach and just say
a - used multiple times
Which I don't think
Hi Simon,
I'm not certain that your explanation matches what I observed.
All of my tests were done on a 4-core machine, executing with +RTS
-N, which should be the same as +RTS -N4 I believe.
With 1 Haskell thread (the main thread) and 4 process threads (via
pthreads), I saw a significant
I'll need to analyse the program to see what's going on. There was a
small change to the scheduler between 7.2.1 and 7.2.2 that could
conceivably have made a difference in this scenario, but it was aimed at
fixing a bug rather than improvement performance.
Another possibility is a difference
I agree the OS scheduler is likely to contribute to our different
observations. I'll try to test with ghc-7.4-rc1 tonight to see if I
get similar results to 7.2.1.
If you want to see some code I'll post it, although I doubt it's
necessary. I would appreciate it if you (or someone else in the
Excerpts from Heka Treep's message of Mon Jan 23 13:56:47 -0500 2012:
adding the message queue (with Chan, MVar or STM) for each process will not
help in this kind of imitation.
Why not? Instead of returning a thread ID, send the write end of a Chan
which the thread is waiting on. You can send
2012/1/23, Edward Z. Yang ezy...@mit.edu:
Excerpts from Heka Treep's message of Mon Jan 23 13:56:47 -0500 2012:
adding the message queue (with Chan, MVar or STM) for each process will
not
help in this kind of imitation.
Why not? Instead of returning a thread ID, send the write end of a Chan
Excerpts from Heka Treep's message of Mon Jan 23 15:11:51 -0500 2012:
import Control.Monad.STM
import Control.Concurrent
import Control.Concurrent.STM.TChan
spawn f = do
mbox - newTChanIO
forkIO $ f mbox
Quoting Heka Treep zena.tr...@gmail.com:
actor mbox = do
empty - atomically $ isEmptyTChan mbox
if empty
then actor mbox
else do
val - atomically $ readTChan mbox
putStrLn val
actor mbox
This looks a bit silly. Why not just this?
actor mbox = forever $
2012/1/23, Edward Z. Yang ezy...@mit.edu:
Excerpts from Heka Treep's message of Mon Jan 23 15:11:51 -0500 2012:
import Control.Monad.STM
import Control.Concurrent
import Control.Concurrent.STM.TChan
spawn f =
Excerpts from Heka Treep's message of Mon Jan 23 16:20:51 -0500 2012:
actor :: TChan String - IO ()
actor mbox = forever $ do
putStrLn call to actor...
msg - atomically $ do
isEmpty - isEmptyTChan mbox
if isEmpty then return Nothing else readTChan mbox = return . Just
when
I recently switched from ghc --make to a parallelized build system. I
was looking forward to faster builds, and while they are much faster
at figuring out what has to be rebuilt (which is most of the time for
a small rebuild, since ld dominates), compilation of the whole system
is either the same
12 matches
Mail list logo
