FFC

Bug #956979
Comment #25

Comment 25 for bug 956979

Revision history for this message

Johan Hake (johan-hake) wrote on 2012-03-20: Re: [Bug 956979] Re: FFC generate code which cannot be compiled

#25

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?

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

Sure, maybe some code could be shared between the two projects?

Johan