← Back to team overview

ffc team mailing list archive

Re: [Ufl] [Bug 769811] [NEW] JIT cache problem with id(form)

 

On Tuesday April 26 2011 08:07:47 Anders Logg wrote:
> On Tue, Apr 26, 2011 at 03:59:52PM +0100, Garth N. Wells wrote:
> > On 26/04/11 15:55, Anders Logg wrote:
> > > On Tue, Apr 26, 2011 at 03:45:22PM +0100, Garth N. Wells wrote:
> > >> On 26/04/11 13:51, Anders Logg wrote:
> > >>> On Tue, Apr 26, 2011 at 02:00:50PM +0200, Anders Logg wrote:
> > >>>> It feels good that you trust me enough to handle it. ;-)
> > >>>> 
> > >>>> Will add it sometime this afternoon and then we can revisit the JIT
> > >>>> compiler caching.
> > >>> 
> > >>> I'm getting confused here... Looking at preprocess.py in UFL, I see 
this:
> > >> It is confusing. Does the function 'preprocess' do anything that the
> > >> old FormData class didn't? It would be easier to follow if Form just
> > >> had a member function form_data() that computes and stores data (like
> > >> it used to), or if Form had a 'preprocess' function. Having the
> > >> function preprocess return a new form is really confusing.
> > > 
> > > I don't find that particularly confusing. It's the same as
> > > 
> > >   refined_mesh = refine(mesh)
> > 
> > Which is the whole problem. By creating a new object, FormData is thrown
> > away. The preprocessing should just compute some more data, just like we
> > *don't* do
> > 
> >   initialised_mesh = mesh.init(0)
> > 
> > What was wrong with Martin's original design that necessitated the
> > change?
> 
> As I explained, I thought it was better to have an explicit call to
> preprocess since that makes it clear that one makes a call to a
> function which may take some time to execute (instead of just calling
> a member function which seems to just return some data).
> 
> But as I say above: I added the caching back at some point (maybe even
> the day after I removed it 2 years ago) so we don't need to discuss
> why I removed it (as I realized myself I shouldn't have removed it and
> added it back a long time ago).
> 
> What has me confused now is that the caching seems to be in place but
> we still need the extra caching in FFC/DOLFIN and I don't see why.

What extra caching? The caching of preprocessed forms are removed from FFC 
with no penalty in speed, because we no fallback on something similare to 
Martins original design. But as stated in my other email we need to do some 
more fixes to get it going without potential memory leaks.

Johan

> --
> Anders
> 
> > Garth
> > 
> > >> Garth
> > >> 
> > >>> def preprocess(form, object_names={}, common_cell=None):
> > >>>     ...
> > >>>     
> > >>>     # Check that form is not already preprocessed
> > >>>     
> > >>>     if form.form_data() is not None:
> > >>>         debug("Form is already preprocessed. Not updating form
> > >>>         data.") return form
> > >>>     
> > >>>     ...
> > >>>     
> > >>>     # Attach form data to form
> > >>>     form._form_data = form_data
> > >>>     
> > >>>     # Attach preprocessed form to form data
> > >>>     form_data._form = form
> > >>> 
> > >>> And when I look at the blamelist (bzr annotate), it looks like I
> > >>> added those lines, so I must have come to my senses and added it
> > >>> back at some point (way back). So in conclusion, calling
> > >>> preprocess() should not taking any time.
> > >>> 
> > >>> What am I missing?
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp



References