FFC

Bug #956979
Comment #24

Comment 24 for bug 956979

Revision history for this message

Kristian B. Ølgaard (k.b.oelgaard) wrote on 2012-03-19: Re: [Bug 956979] Re: FFC generate code which cannot be compiled

#24

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

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

> 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