This is probably a hard question to be asking in the forums, since it deals with my specific implementation of a pipeline, but I figured I'd give it a try since I'm kinda stuck in my debugging and just need some more hints on where to look.

I have a problem that lends itself greatly to a pipeline. I have a file that contains a list of objects which I just read out serially. Then I need to calculate "attributes" of those objects which get saved into another file that is just a list of attributes.

Schematically this it looks like this

Hi,
I am trying to parallelize an ITK application. The application has a very promiment loop with 50 iterations. I parallelized this loop using parallel_reduce() and ran the parallelized application on a 8-core machine. I noticed that a grain size of 1 is giving a better performance larger grain sizes. I am puzzled at this and wondering how this could be possible or under which condition this happens. Can anybody shed some light?

thanks,
fiju

Hi all,

I have a simple parallel_for loop that basically runs on the blocked_range<0, TASKS, 1), or in other words, creates exactly TASKS tasks. To measure scalability, I tried varying the number of tasks from 2 to 8 on an 8-core machine (2x4). I always initialize without specifying the number of threads, so I assume 8 are created.

I found parallel_for always (if possible) try to adjust the grainsize to a smaller value in order to split whole range into a number of 2^N chunks. Are there any necessities that does in such a way? As I know, say, 4-cores processor with Hyper-Threading, theoretically total 8 threads are available. But it does not mean that a program can get all of these resources, depend upon the operating system situation at the time. This brings no problem, just would like to know. For the simplicity of parallel_for, it has a primitive approach to generate threads of any numbers justprogramsinvoke.