Stephane Marchesin wrote:
> On Thu, Oct 23, 2008 at 19:52, Ioannis Papadopoulos
> <[EMAIL PROTECTED]> wrote:
>
>> Well, I'm working all the time with pthreads, OpenMP and MPI. I'm also
>> familiar with Intel's TBB. The all have their pros and cons - and I'm
>> only talking for shared-memory applications, as a distributed memory
>> implementation would have too much latency (people have been using MPI
>> even for applications on shared-memory machines with mixed results).
>>
>> I was thinking about pthreads, but the problem is:
>> 1) there is no portable way of supporting atomic operations (OpenMP has
>> a directive for that). Moreover, you have to maintain coherency and
>> avoid race-conditions using the volatile keyword and locks. In OpenMP
>> all this is done by the compiler.
>>
>
> Well, pthreads are not intended to handle atomic operations, that's
> what semaphores are for.
>
I was talking about #pragma omp atomic which is quite useful when it is
actually supported by the compiler/architecture.
>> 2) one has to implement the scheduling and task management (OpenMP does
>> that already and OpenMP 3.0 which is around the corner will support that
>> even better - there is already a nearly done branch for v3.0)
>>
>
> Pthreads don't need to be scheduled by hand either, the OS does it.
>
>
I should have written "task scheduling and management". Yes, the threads
are OS handled but everything else has to be handled by a runtime
system. This means using some efficient way one has to create and
schedule tasks to achieve maximum speedup. Moreover, the threads have to
be able to be reused for different tasks, taking care about cache
affinity etc. - these are all handled rather successfully by OpenMP.
>> 3) OpenMP is easy even for beginners in parallel processing
>> 4) you can always remove OpenMP by telling the compiler that you don't
>> want support (ok, even for pthreads you can do that, but manually)
>>
>>
>
> Well, in my experience, OpenMP also has a number of disadvantages.
> Granted it is very easy to write your first parallel program with it,
> but it is also extremely fragile, because the parallel semantics can
> be left implicit (which in my experience leads to a high number of
> bugs that are difficult to find). Basically, once you tackle bigger
> programs, you end up adding a lot of shared/private statements
> everywhere, which becomes untractable inside big codes like mesa.
>
Likewise, the pthread solution needs to put the locks in the correct
places, use volatile etc The worse is that you have to maintain it as well.
>
>> On the other hand pthreads allow you to micromanage everything - what to
>> execute where etc. thus maybe you can achieve optimal parallelism.
>>
>
> Well, in the mesa case I don't think OpenMP would have much added
> value over other techniques - the parallel section would just be the
> rasterization phase, so the choice of the API doesn't matter much as
> it's not much work in itself. The real work would be making the
> rasterizer {pthread,OpenMP,MPI} safe...
>
> Stephane
>
Although normally I'm not a very strong advocate for OpenMP, in this
case I think it fits the task completely: I tend to see OpenGL as just
operations on matrices, which means that data parallelism is there and
can be best exposed using OpenMP.
Giannis
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
