← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Add a 'mpi_jit_decorator' function which generalizes the paralell jit

 

On Saturday 29 August 2009 15:22:08 Anders Logg wrote:
> On Sat, Aug 29, 2009 at 03:14:27PM +0200, Anders Logg wrote:
> > On Sat, Aug 29, 2009 at 12:31:24AM +0200, Johan Hake wrote:
> > > On Friday 28 August 2009 22:35:08 Anders Logg wrote:
> > > > On Wed, Aug 19, 2009 at 01:41:50PM +0200, DOLFIN wrote:
> > > > > One or more new changesets pushed to the primary dolfin repository.
> > > > > A short summary of the last three changesets is included below.
> > > > >
> > > > > changeset:   6801:d3897056b4c92df1a2decddb8481f01011468683
> > > > > tag:         tip
> > > > > user:        "Johan Hake <hake@xxxxxxxxx>"
> > > > > date:        Wed Aug 19 13:41:45 2009 +0200
> > > > > files:       site-packages/dolfin/compile_extension_module.py
> > > > > site-packages/dolfin/jit.py description:
> > > > > Add a "mpi_jit_decorator" function which generalizes the paralell
> > > > > jit compilation algorithm.
> > > > >
> > > > >    It utilize a nice feature in Python: decorators
> > > > >    To apply it to a jit_compiler just import the decorator and
> > > > > decorate your jit function:
> > > > >
> > > > >    @mpi_jit_decorator
> > > > >    def some_jit_compiler(some):
> > > > >       ....
> > > >
> > > > Pretty cool, but why the threads? I don't understand why that should
> > > > be needed.
> > >
> > > If we want a message that tells the user that a form will be jit
> > > compiled on the first process, only when it actually is compiling, I
> > > couldn't find another non-intrusive way to implement it.
> > >
> > > The same process that starts the compiling needs to find out if an
> > > actual compilation has started. This is done using a thread. It starts
> > > it, wait a while 0.2 s I think, using the join function), check if the
> > > thread is alive. If the thread is alive, assume it is compiling and
> > > issue a message. If the thread is not alive we assume the module is
> > > picked up from cache, and we proceed without issuing a message. Also
> > > note that if the cache is used, the present thread will finish the join
> > > statement before the 0.2 s.
> >
> > Maybe it's enough that we get a message from the actual JIT function
> > that it is compiling? That message will only appear (at least from
> > FFC) when code is not cached.
>
> I removed this so that the threads are not needed. We can set a prefix
> "Process 0:" for the FFC (UFL) log system which will accomplish the
> same thing.

Ok.

Johan

> --
> Anders


References