Comment 10 for bug 956979

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.

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

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