On Sat, Nov 01, 2008 at 07:08:14PM +0100, Johan Hake wrote: > On Saturday 01 November 2008 17:10:09 Martin Sandve Alnæs wrote: > > 2008/11/1 Garth N. Wells <[EMAIL PROTECTED]>: > > > 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.
This is what I've been planning (but I don't know how to implement it). If we can get the thread number, it should be simple. User-defined functions access the cell and facet by the functions cell() and facet(), so those functions may just pick the data from an array. -- Anders > > 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. > > This is probably a quite common problem which has been solved in many > previous > applications. > > > Johan > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
