I may be talking out of my other end here, but... if you want something like parMap to calculate all the pixels in parallel, then... can't you use parMap itself? Something like: weirdParMap action = sequence_ . map action . parMap (id $!) This evaluates all the elements of the list using parMap (the expensive part, right?), and then sequentially applies the action on the current thread. JCAB On Sun, 15 Apr 2007 12:56:02 -0700, Mitar wrote:

Hi!

On 4/15/07, Spencer Janssen wrote:

...

This version will fork a new thread for each action:

\begin{code} import Control.Concurrent import Control.Monad

parSequence_ xs = do m <- newEmptyMVar mapM_ (\x -> forkIO x >> putMVar m ()) xs replicateM_ (length xs) (takeMVar m)

parMapM_ f xs = parSequence_ $ map f xs \end{code}

OpenGL bindings successfully crash. The functional calculations in f should be done in parallel, but those few OpenGL actions should still be done sequentially. I am attaching the code in question. It is a simple voxel raycasting engine.

(Any suggestions on other memory/performance improvements are more than welcome.)

Mitar

:-) Thank you for your kindness. I mean... your frankness. I had another issue in that code which clearly shows that I don't know how to use parMap or strategies in general. Maybe this is better: weirdParMap action = sequence_ . map action . parMap rwhnf (\x -> x `seq` x) or maybe that's overkill and this is sufficient: weirdParMap action = sequence_ . map action . parMap rwhnf id or this: weirdParMap action list = sequence_ $ map action (list `using` rnf) (which I guess would require the appropriate NFData instanbe for the pixel type) or maybe I still don't know enough about this Parallel Haskell thingy. In any case... couldn't something like this be what was needed in the OP? JCAB On Tue, 17 Apr 2007 17:56:27 -0700, Stefan O'Rear wrote:

On Tue, Apr 17, 2007 at 05:49:11PM -0700, Juan Carlos Arevalo Baeza wrote:

...

I may be talking out of my other end here, but... if you want something like parMap to calculate all the pixels in parallel, then... can't you use parMap itself?

Something like:

weirdParMap action = sequence_ . map action . parMap (id $!)

This evaluates all the elements of the list using parMap (the expensive part, right?), and then sequentially applies the action on the current thread.

You are. I'm devoting most of my brain cells to automatic deriving of TTypeable atm, but note that id is already strict, so (id $!) is equivalent to id.

Stefan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Apr 15, 2007, at 8:23 PM, Spencer Janssen wrote:

parSequence_ xs = do m <- newEmptyMVar mapM_ (\x -> forkIO x >> putMVar m ()) xs replicateM_ (length xs) (takeMVar m)

mapM_ above spawns (length xs) threads blocking on a single "lock", right? replicateM_ then makes sure that the lock is "unlocked" as many times as threads spawned, right? Since all the threads block on a single MVar how do they run in parallel? Thanks, Joel -- http://wagerlabs.com/

Hi! On 4/16/07, Bertram Felgenhauer wrote:

...

Since all the threads block on a single MVar how do they run in parallel?

The idea is that before the threads block on the MVar, they run their action x to completion.

The rendering crashes. I will have to precompute the values in threads someway and then sequentially draw it? Any suggestion how to do that? Mitar

Mitar wrote:

Hi!

On 4/16/07, Bertram Felgenhauer wrote:

...

...

Since all the threads block on a single MVar how do they run in parallel?

The idea is that before the threads block on the MVar, they run their action x to completion.

The rendering crashes. I will have to precompute the values in threads someway and then sequentially draw it? Any suggestion how to do that?

I'm guessing this is becuase of the thread-local state used by OpenGL, which is the reason we have forkOS. All your OpenGL calls must be executed by the same Haskell thread, and it must be a bound thread (i.e. either the main thread, or a thread created with forkOS). Cheers, Simon

Hi! On 4/17/07, Sebastian Sylvan wrote:

I would suggest chunking up your work (assuming that calculating your colour is indeed a significant amount of work) in tiles or something, then fork off a thread for each of them, sticking the final colours in a Chan. Then you have another thread just pick tiles off the Chan and copy the results to the frame buffer.

Is there some completely different and maybe better way of rendering the image? Because I noticed that in fact I do not really have any use for OpenGL (I draw pixels on a 2D plane). So maybe is there some other portable way of rendering a 2D image, which would be easier to parallelize? Maybe of precomputing the image in completely functional way and then only draw the whole image at once to the screen buffer (now I call OpenGL draw pixel function for every pixel I want to draw - this is probably not the best way). Mitar