On 22 March 2012 08:52, Johan Hake <email address hidden> wrote:
> 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.

Quite different. The 'reuse' would then reduce to copying small chunks
of code, but some FFC can definitely be inspired by the latest work by
Martin on reduced caching.
However, we could have an optimisation option -fsfc (with a better
name of course) which would use the SFC graph strategy to generate
code, it would need to modify
parts of the SFC generator code, but large parts could be reused.

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

Are those timings for SFC code, or FFC non-optimised code?
I'm sure FFC compares terrible to SFC in this case.

Kristian

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