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.

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
>