FFC

Bug #956979
Comment #23

Comment 23 for bug 956979

Revision history for this message

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

#23

On 03/19/2012 09:29 AM, Kristian B. Ølgaard wrote:
> On 19 March 2012 07:47, Johan Hake<email address hidden> wrote:
>> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>>> wrote:
>>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>>> wrote:
>>>>>
>>>>> On 16 March 2012 15:17, 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.
>>>>>>>
>>>>>
>>>>> Which explode when linearised.
>>>>
>>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>>> might help.
>>>>
>>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>>> rooted in the repr are which grow quite large during a compile. Not
>>>> sure how to profile memory use in python...
>>>
>>> For speed, objects are cached in FFC (and I believe also in SFC the
>>> last time I checked) so as the expression become more and more
>>> complex the memory usage will increase. The simplify_expression
>>> optimisation strategy for FFC is particular poor in this regard as it
>>> relies on first expanding the expression before trying to optimise it
>>> which results in a lot of temporary expressions (objects) being
>>> created.
>>
>> What algorithm are you talking about that stores all these temporary
>> objects. I have at least found out that the memory explosion happens within:
>>
>> ffc:extract_monomial_integrand
>>
>> within the call to
>>
>> ufl:purge_list_tensors
>>
>> Which indicates that UFL is actually the leaker her. This also makes
>> sense as SFC show the same huge memory usage.
>
> BTW, did you find a memory profiler for Python?

Plenty, but none which I have been able to use. They were mostly home
brewed libraries... :(

Johan

>
>> Will file a speate bug to UFL for this.
>>
>> Johan
>>
>>>> Johan
>>>>
>>>>>>> But Johan, did you try _with_ ffc optimization? I believe
>>>>>>> that may improve the size of the generated code.
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> This doesn't impact on the generation time, just the runtime.
>>>>>
>>>>> The linearisation of complicated functions (fractions, etc) can
>>>>> really blow up.
>>>>>
>>>>> Garth
>>>>>
>>>>>> -- Anders
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>
>>>>>> To manage notifications about this bug go to:
>>>>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>>>>>
>>>>>
>>>>> -- Garth N. Wells Department of Engineering, University of
>>>>> Cambridge http://www.eng.cam.ac.uk/~gnw20
>>>>>
>>>>> -- 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 09:29 AM, Kristian B. Ølgaard wrote:
> On 19 March 2012 07:47, Johan Hake<956979@bugs.launchpad.net>  wrote:
>> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 16:56, Johan Hake<956979@bugs.launchpad.net>
>>> wrote:
>>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<956979@bugs.launchpad.net>
>>>> wrote:
>>>>>
>>>>> On 16 March 2012 15:17, 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.
>>>>>>>
>>>>>
>>>>> Which explode when linearised.
>>>>
>>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>>> might help.
>>>>
>>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>>> rooted in the repr are which grow quite large during a compile. Not
>>>> sure how to profile memory use in python...
>>>
>>> For speed, objects are cached in FFC (and I believe also in SFC the
>>> last time I checked) so as the expression become more and more
>>> complex the memory usage will increase. The simplify_expression
>>> optimisation strategy for FFC is particular poor in this regard as it
>>> relies on first expanding the expression before trying to optimise it
>>> which results in a lot of temporary expressions (objects) being
>>> created.
>>
>> What algorithm are you talking about that stores all these temporary
>> objects. I have at least found out that the memory explosion happens within:
>>
>>    ffc:extract_monomial_integrand
>>
>> within the call to
>>
>>    ufl:purge_list_tensors
>>
>> Which indicates that UFL is actually the leaker her. This also makes
>> sense as SFC show the same huge memory usage.
>
> BTW, did you find a memory profiler for Python?

Plenty, but none which I have been able to use. They were mostly home 
brewed libraries... :(

Johan

>
>> Will file a speate bug to UFL for this.
>>
>> Johan
>>
>>>> Johan
>>>>
>>>>>>> But Johan, did you try _with_ ffc optimization? I believe
>>>>>>> that may improve the size of the generated code.
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> This doesn't impact on the generation time, just the runtime.
>>>>>
>>>>> The linearisation of complicated functions (fractions, etc) can
>>>>> really blow up.
>>>>>
>>>>> Garth
>>>>>
>>>>>> -- Anders
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>
>>>>>> To manage notifications about this bug go to:
>>>>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>>>>>
>>>>>
>>>>> -- Garth N. Wells Department of Engineering, University of
>>>>> Cambridge http://www.eng.cam.ac.uk/~gnw20
>>>>>
>>>>> -- 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
>