dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/11/1 Johan Hake <hake@xxxxxxxxx>:
> On Saturday 01 November 2008 17:10:09 Martin Sandve Alnæs wrote:
>> 2008/11/1 Garth N. Wells <gnw20@xxxxxxxxx>:
>> > Martin Sandve Alnæs wrote:
>> >> Are there any plans for multicore support in DOLFIN, that is
>> >> automatic utilization of multiple CPU cores without significant
>> >> user intervention, in the near future? (For example using OpenMP).
>> >
>> > No immediate plans (message passing is the immediate priority), but
>> > obviously this would be very nice to have and we don't want our design to
>> > preclude it.
>>
>> Ok.
>>
>> >> If yes, am I the only one who thinks it would be a good idea
>> >> to consider this in the new Function design?
>> >
>> > You may be the only that knows enough about multi-threaded programming to
>> > be in a position to think properly about it.
>>
>> Ok, but I don't really know that much about it.
>>
>> >> I just want to point this out since I think this issue has been too
>> >> downplayed in the design discussions. And I don't think anyone
>> >> wants yet another redesign of Function within the next months...
>> >>
>> >> The main issue is that iterating over cells in a mesh and calling a
>> >> Function currently involves side effects, modifying its mutable members
>> >> cell and facet. Thus the user would have to construct multiple Function
>> >> objects for a Function to be used in basically any multicore situation.
>> >> Any solution to this must involve sending all kinds of cell data needed
>> >> as arguments to eval. Exactly how this should look is a design
>> >> discussion.
>> >
>> > So if we remove
>> >
>> >  mutable Cell* _cell
>> >  mutable int _facet
>> >
>> > from the private member data of Function, does this resolve the biggest
>> > design issue for running multi-threaded?
>>
>> Yes. Otherwise the threads will overwrite each others current cell all the
>> time.
>
> Would it be possible to store the present Cell* and facet in two vectors of
> length #threads. Then we either have to call the cell(), facet() and normal()
> with the present thread number or if it is possible to implement a static
> function that returns the present thread number in these functions. If the
> last option is not possible we need to call the eval function with the
> present thread number.
>
>> User functions need to be threadsafe too though, but we can't do
>> anything about that.
>
> Passing the thread number to eval would make it possible to write thread safe
> functions.

Passing around the thread number would destroy the simple interface.
Then there would be no point in avoiding cell as an argument to eval,
would there?
But openmp can give you the thread number.

> This is probably a quite common problem which has been solved in many previous
> applications.

Writing functions without side effects is the general solution.
Since nobody here are experts on the subject, I believe going
for this simple and obvious solution is the best.

--
Martin