FFC

Bug #956979
Comment #27

Comment 27 for bug 956979

Revision history for this message

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

#27

On 03/22/2012 08:37 AM, Anders Logg 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.

I guess, so it wont probably happen without refactorizing large part of
either code. That said, FFC's optimization code fails to be generated
with the attached form, where SFC generate optimized code. 1/4 of the
time is spent in GenericTensor.add and 3/4 in tabulate_tensor.

Johan

> --
> 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 03/22/2012 08:37 AM, Anders Logg 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.

I guess, so it wont probably happen without refactorizing large part of 
either code. That said, FFC's optimization code fails to be generated 
with the attached form, where SFC generate optimized code. 1/4 of the 
time is spent in GenericTensor.add and 3/4 in tabulate_tensor.

Johan