Subject: [Ufl] Triggers of recompilation of large forms

From: Johan Hake <[email-masked]>
Date: Thu, 3 Mar 2011 15:02:10 -0800

Hello!

I have some large forms, including some 40 exterior facet integrals. I am 
starting to get annoyed by a constant recompilation of these forms. I have 
made pretty clear that each one does not contain any numbers that changes from 
simulation to simulation (Using Constant or Expression for changing 
coefficients). But at arbitrary times, reompilations are triggered and with 
many integrals per form this take times ~5-20min each... The generated code is 
not large, no complex forms, just many integrals. I also use MixedSpaces with 
Real, see other email, with some 10 Real spaces.

I have tried to eliminate any possible triggers for recompilations within my 
own code, change all dicts to ordered dicts and so on. Becuase the forms are 
so big it is almost impossible to debug any signature string from the form. 
They are hundreds of konsole lines long...

Do any of you have any clue of where, for example in UFL I can start debug 
this? 

  * Do all math operators in UFL preserve the orignial order?
  * Are there any dicts involved in storing internal information in a form,
    which the __repr__ command depends on?

Is there another way to represent the uniqeness of a form which might 
eliminate this error?

Johan

---

From: Anders Logg <[email-masked]>
Date: Fri, 4 Mar 2011 00:37:11 +0100

> They are hundreds of konsole lines long...

Does the hash sum change?

--
Anders

> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

---

From: Johan Hake <[email-masked]>
Date: Thu, 3 Mar 2011 16:12:37 -0800

On Thursday March 3 2011 15:37:11 Anders Logg wrote:
> > starting to get annoyed by a constant recompilation of these forms. I
> > have made pretty clear that each one does not contain any numbers that
> > changes from simulation to simulation (Using Constant or Expression for
> > changing coefficients). But at arbitrary times, reompilations are
> > triggered and with many integrals per form this take times ~5-20min
> > each... The generated code is not large, no complex forms, just many
> > integrals. I also use MixedSpaces with Real, see other email, with some
> > 10 Real spaces.
> > 
> > I have tried to eliminate any possible triggers for recompilations within
> > my own code, change all dicts to ordered dicts and so on. Becuase the
> > forms are so big it is almost impossible to debug any signature string
> > from the form. They are hundreds of konsole lines long...
> 

I suspect that, because otherwise it would not trigger a recompile. 

But the hash sum is dependent on the repr of the form. I suspect that there 
might be some randomness built into this. 

Eventhough a simple case:

  a = u*v*dx
  a += u*v*ds(1)
  a += u*v*ds(2)

should create the same form each time, (This particular simple example 
probably does), I have much more complicated forms building up which I suspect 
don't create the same repr all the time. I haven't been able to debug it 
further as the repr of the forms are hundreds of konsole line...

Johan

> --
> Anders
> 
> > Do any of you have any clue of where, for example in UFL I can start
> > debug this?
> >

---

From: Anders Logg <[email-masked]>
Date: Fri, 4 Mar 2011 10:23:28 +0100

> I suspect that, because otherwise it would not trigger a recompile.

Could you check? Try storing the values returned by __hash__ and
signature in JITObject in FFC to a file, and print some messages like
"not in cache, need to generated code", "found in cache" etc, together
with some numbers:

1. sfdirwe2349sf9wr98sdf9wer987wer97wer98we7wer9wef: not in cache
2. f09fs09wr09s8fd09s8df09we09sd8s0d9f8s0df98sdf98s: found in cache
3. ...

Then do the same thing with the full signatures in a separate
file. Then locate the form that triggers recompilation, confirm that
the hash is changed, and then compare the full signatures.

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 4 Mar 2011 15:32:29 +0100

> the hash is changed, and then compare the full signatures.

Are you using UFL files or PyDOLFIN? If the latter I would start
looking at the UFL subclasses classes that PyDOLFIN implement.

No randomness was a fundamental design criteria in UFL after all the
problems I had with the randomness in GiNaC... Any randomness should
be considered a critical bug.

--
Martin

---

From: Johan Hake <[email-masked]>
Date: Fri, 4 Mar 2011 08:21:35 -0800

On Friday March 4 2011 06:32:29 Martin Sandve Alnæs wrote:
> >> > > I have some large forms, including some 40 exterior facet integrals.
> >> > > I am starting to get annoyed by a constant recompilation of these
> >> > > forms. I have made pretty clear that each one does not contain any
> >> > > numbers that changes from simulation to simulation (Using Constant
> >> > > or Expression for changing coefficients). But at arbitrary times,
> >> > > reompilations are triggered and with many integrals per form this
> >> > > take times ~5-20min each... The generated code is not large, no
> >> > > complex forms, just many integrals. I also use MixedSpaces with
> >> > > I have tried to eliminate any possible triggers for recompilations
> >> > > within my own code, change all dicts to ordered dicts and so on.
> >> > > Becuase the forms are so big it is almost impossible to debug any
> >> > > signature string from the form. They are hundreds of konsole lines
> >> > > long...
> >> > 
> >> But the hash sum is dependent on the repr of the form. I suspect that
> >> there might be some randomness built into this.
> >> 
> >> probably does), I have much more complicated forms building up which I
> >> suspect don't create the same repr all the time. I haven't been able to
> >> debug it further as the repr of the forms are hundreds of konsole
> >> line...
> >> 
> >> Johan
> 

Good point! Will do!

> be considered a critical bug.

He, he, remember discussing this issue before!

Johan