Comment 20 for bug 956979

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?

> 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