FFC

Bug #956979
Comment #28

Comment 28 for bug 956979

Revision history for this message

Kent-Andre Mardal (kent-and) wrote on 2012-03-22: Re: [Bug 956979] Re: FFC generate code which cannot be compiled

#28

On 22 March 2012 08:37, Anders Logg <email address hidden> wrote:

> 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
>

Unified Form Compiler?

Kent

>
>
> > 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
> > >
> >
>
> --
> You received this bug notification because you are 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 22 March 2012 08:37, Anders Logg <logg@simula.no> wrote:

> 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
>

Unified Form Compiler?

Kent

>
>
> > 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
> > >
> >
>
> --
> You received this bug notification because you are 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
>