FFC

Bug #956979
Comment #26

Comment 26 for bug 956979

Revision history for this message

Anders Logg (logg) wrote on 2012-03-22: Re: [Bug 956979] Re: FFC generate code which cannot be compiled

#26

On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> > On 19 March 2012 09:34, Johan Hake<email address hidden>
> > wrote:
> >> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> >>> On 19 March 2012 07:40, Johan Hake<email address hidden>
> >>> wrote:
> >>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> >>>>> On 16 March 2012 16:48, Johan
> >>>>> Hake<email address hidden> wrote:
> >>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
> >>>>>>> Alnæs wrote:
> >>>>>>>> On 16 March 2012 15:49, Johan
> >>>>>>>> Hake<email address hidden> wrote:
> >>>>>>>>> This is really a duplication of bug 897372, which
> >>>>>>>>> compared FFc and
> >>>>>> SFC,
> >>>>>>>>> as SFC compiles the attached form just fine. The
> >>>>>>>>> generated code is
> >>>>>> much
> >>>>>>>>> smaller. Talking with Martin, I get the impression
> >>>>>>>>> that FFC does not
> >>>>>> use
> >>>>>>>>> the information UFL provides about the internal
> >>>>>>>>> structure of the different sub expressions. I got the
> >>>>>>>>> impression that FFC lump the
> >>>>>> whole
> >>>>>>>>> expression into a large string.
> >>>>>>>>
> >>>>>>>> ... for arguments to MathFunctions that is, according
> >>>>>>>> to earlier comments from Kristian.
> >>>>>>>>
> >>>>>>>> Material models for biological tissue often have
> >>>>>>>> rather complex arguments to e.g. exp.
> >>>>>>>>
> >>>>>>>> But Johan, did you try _with_ ffc optimization? I
> >>>>>>>> believe that may improve the size of the generated
> >>>>>>>> code.
> >>>>>>
> >>>>>> No, that was turned of to improve performance of FFC, which
> >>>>>> was fixed by my previous commit. Will test with
> >>>>>> optimization on.
> >>>>>
> >>>>> The fix you added is in a function which is pre-UFL. It was
> >>>>> part of a set of functions that could optimise code passed as
> >>>>> a string. It is currently only used to compute the number of
> >>>>> operations in non-optimised code, kudos for the fix though.
> >>>>
> >>>> Ok, good to know :)
> >>>>
> >>>> It was however a show stopper for the attached form. Now FFC
> >>>> manage to generate the code, at least when no optimization
> >>>> (simplification) is done to the expression. But as said before
> >>>> the code wont compile because of that one darn long line.
> >>>>
> >>>>>>> I thought the issue was the number of quadrature points
> >>>>>>> used by FFC trying to integrate the expression exactly.
> >>>>>>> Does it not help to reduce the quadrature order?
> >>>>>>
> >>>>>> It definitely helped but here I am using quadrature order
> >>>>>> 2.
> >>>>>
> >>>>> Switching on optimisations will reduce the size of the code,
> >>>>> as terms and tables will be reused. Reducing the quadrature
> >>>>> order from ridiculous to 2 will also help as tables will be
> >>>>> smaller, but to a less extent (and you already did that).
> >>>>
> >>>> Yes, and I guess your optimziation algorithm works on the
> >>>> already assembles string, which is very long. I think operating
> >>>> on such a big string forces FFC to its knees.
> >>>>
> >>>> SFC does not have this problem at all, as it make the
> >>>> simplification (optimization) based on the UFL expression. SFC
> >>>> never contracts the whole expression.
> >>>
> >>> No, FFC translates UFL to an intermediate representation of the
> >>> expression using symbols (objects defined in
> >>> ffc/quadrature/fraction.py ffc/quadrature/product.py etc.). This
> >>> expression can then be optimised in various ways.
> >>
> >> Ok, I based that assumption on something Martin said. But I guess
> >> there are optimizations to be done, as it works pretty nice in SFC,
> >> where FFC chokes.
> >
> > There's definitely room for optimisations w.r.t. speed and memory
> > consumption in FFC for hyperelastic forms and the like. Using floats
> > instead of Constant, in your form, FFC will produce a reasonable
> > result with -O -feliminate_zeros -fprecompute_basis_const, but I'd
> > suggest using SFC for this class of problems at the moment.
>
> Ok.
>
> > After
> > all, SFC was designed with hyperelasticity in mind while the
> > quadrature representation and optimisation was developed (and tested
> > on) plasticity problems. This is no excuse for not improving the
> > performance though, it just won't happen in near future.
>
> Sure, maybe some code could be shared between the two projects?

That would make sense. At least when possible. There are some
different strategies used for generating the code.

--
Anders

> Johan
>
> >> Johan
> >>
> >>>> Johan
> >>>>
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Subdividing this string is probably suboptimal
> >>>>>>>>> compared to using the information already stored in
> >>>>>>>>> UFL.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Title: FFC generate code which cannot be compiled
> >>>>>>>>>
> >>>>>>>>> Status in FEniCS Form Compiler: New
> >>>>>>>>>
> >>>>>>>>> Bug description: I have a viscoelastic biomechanics
> >>>>>>>>> form which generate an .h file which is 45M large,
> >>>>>>>>> with a single line length of 44M characters long.
> >>>>>>>>> This wont compile with gcc. No optimization enabled
> >>>>>>>>> at all.
> >>>>>>>>>
> >>>>>>>>> To manage notifications about this bug go to:
> >>>>>>>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> -- You received this bug notification because you are a member of
> >>>>>>> FFC Core Team, which is subscribed to FFC.
> >>>>>>> https://bugs.launchpad.net/bugs/956979
> >>>>>>>
> >>>>>>> Title: FFC generate code which cannot be compiled
> >>>>>>>
> >>>>>>> Status in FEniCS Form Compiler: New
> >>>>>>>
> >>>>>>> Bug description: I have a viscoelastic biomechanics form
> >>>>>>> which generate an .h file which is 45M large, with a
> >>>>>>> single line length of 44M characters long. This wont
> >>>>>>> compile with gcc. No optimization enabled at all.
> >>>>>>>
> >>>>>>> To manage notifications about this bug go to:
> >>>>>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >>>>>>
> >>>>>>
> >>>>>>>
> -- You received this bug notification because you are a member of
> >>>>>> FFC Core Team, which is subscribed to FFC.
> >>>>>> https://bugs.launchpad.net/bugs/956979
> >>>>>>
> >>>>>> Title: FFC generate code which cannot be compiled
> >>>>>>
> >>>>>> Status in FEniCS Form Compiler: New
> >>>>>>
> >>>>>> Bug description: I have a viscoelastic biomechanics form
> >>>>>> which generate an .h file which is 45M large, with a single
> >>>>>> line length of 44M characters long. This wont compile with
> >>>>>> gcc. No optimization enabled at all.
> >>>>>>
> >>>>>> To manage notifications about this bug go to:
> >>>>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >>>>>
> >>>>
> >>>> -- You received this bug notification because you are a member
> >>>> of FFC Core Team, which is subscribed to FFC.
> >>>> https://bugs.launchpad.net/bugs/956979
> >>>>
> >>>> Title: FFC generate code which cannot be compiled
> >>>>
> >>>> Status in FEniCS Form Compiler: New
> >>>>
> >>>> Bug description: I have a viscoelastic biomechanics form which
> >>>> generate an .h file which is 45M large, with a single line
> >>>> length of 44M characters long. This wont compile with gcc. No
> >>>> optimization enabled at all.
> >>>>
> >>>> To manage notifications about this bug go to:
> >>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >>>
> >>
> >> -- You received this bug notification because you are a member of
> >> FFC Core Team, which is subscribed to FFC.
> >> https://bugs.launchpad.net/bugs/956979
> >>
> >> Title: FFC generate code which cannot be compiled
> >>
> >> Status in FEniCS Form Compiler: New
> >>
> >> Bug description: I have a viscoelastic biomechanics form which
> >> generate an .h file which is 45M large, with a single line length
> >> of 44M characters long. This wont compile with gcc. No optimization
> >> enabled at all.
> >>
> >> To manage notifications about this bug go to:
> >> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >
>

On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> > On 19 March 2012 09:34, Johan Hake<956979@bugs.launchpad.net>
> > wrote:
> >> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> >>> On 19 March 2012 07:40, Johan Hake<956979@bugs.launchpad.net>
> >>> wrote:
> >>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> >>>>> On 16 March 2012 16:48, Johan
> >>>>> Hake<956979@bugs.launchpad.net> wrote:
> >>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<logg@simula.no>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
> >>>>>>> Alnæs wrote:
> >>>>>>>> On 16 March 2012 15:49, Johan
> >>>>>>>> Hake<956979@bugs.launchpad.net> wrote:
> >>>>>>>>> This is really a duplication of bug 897372, which
> >>>>>>>>> compared FFc and
> >>>>>> SFC,
> >>>>>>>>> as SFC compiles the attached form just fine. The
> >>>>>>>>> generated code is
> >>>>>> much
> >>>>>>>>> smaller. Talking with Martin, I get the impression
> >>>>>>>>> that FFC does not
> >>>>>> use
> >>>>>>>>> the information UFL provides about the internal
> >>>>>>>>> structure of the different sub expressions. I got the
> >>>>>>>>> impression that FFC lump the
> >>>>>> whole
> >>>>>>>>> expression into a large string.
> >>>>>>>>
> >>>>>>>> ... for arguments to MathFunctions that is, according
> >>>>>>>> to earlier comments from Kristian.
> >>>>>>>>
> >>>>>>>> Material models for biological tissue often have
> >>>>>>>> rather complex arguments to e.g. exp.
> >>>>>>>>
> >>>>>>>> But Johan, did you try _with_ ffc optimization? I
> >>>>>>>> believe that may improve the size of the generated
> >>>>>>>> code.
> >>>>>>
> >>>>>> No, that was turned of to improve performance of FFC, which
> >>>>>> was fixed by my previous commit. Will test with
> >>>>>> optimization on.
> >>>>>
> >>>>> The fix you added is in a function which is pre-UFL. It was
> >>>>> part of a set of functions that could optimise code passed as
> >>>>> a string. It is currently only used to compute the number of
> >>>>> operations in non-optimised code, kudos for the fix though.
> >>>>
> >>>> Ok, good to know :)
> >>>>
> >>>> It was however a show stopper for the attached form. Now FFC
> >>>> manage to generate the code, at least when no optimization
> >>>> (simplification) is done to the expression. But as said before
> >>>> the code wont compile because of that one darn long line.
> >>>>
> >>>>>>> I thought the issue was the number of quadrature points
> >>>>>>> used by FFC trying to integrate the expression exactly.
> >>>>>>> Does it not help to reduce the quadrature order?
> >>>>>>
> >>>>>> It definitely helped but here I am using quadrature order
> >>>>>> 2.
> >>>>>
> >>>>> Switching on optimisations will reduce the size of the code,
> >>>>> as terms and tables will be reused. Reducing the quadrature
> >>>>> order from ridiculous to 2 will also help as tables will be
> >>>>> smaller, but to a less extent (and you already did that).
> >>>>
> >>>> Yes, and I guess your optimziation algorithm works on the
> >>>> already assembles string, which is very long. I think operating
> >>>> on such a big string forces FFC to its knees.
> >>>>
> >>>> SFC does not have this problem at all, as it make the
> >>>> simplification (optimization) based on the UFL expression. SFC
> >>>> never contracts the whole expression.
> >>>
> >>> No, FFC translates UFL to an intermediate representation of the
> >>> expression using symbols (objects defined in
> >>> ffc/quadrature/fraction.py ffc/quadrature/product.py etc.). This
> >>> expression can then be optimised in various ways.
> >>
> >> Ok, I based that assumption on something Martin said. But I guess
> >> there are optimizations to be done, as it works pretty nice in SFC,
> >> where FFC chokes.
> >
> > There's definitely room for optimisations w.r.t. speed and memory
> > consumption in FFC for hyperelastic forms and the like. Using floats
> > instead of Constant, in your form, FFC will produce a reasonable
> > result with -O -feliminate_zeros -fprecompute_basis_const, but I'd
> > suggest using SFC for this class of problems at the moment.
>
> Ok.
>
> > After
> > all, SFC was designed with hyperelasticity in mind while the
> > quadrature representation and optimisation was developed (and tested
> > on) plasticity problems. This is no excuse for not improving the
> > performance though, it just won't happen in near future.
>
> Sure, maybe some code could be shared between the two projects?

That would make sense. At least when possible. There are some
different strategies used for generating the code.

--
Anders