On 03/22/2012 11:23 AM, Kristian B. Ølgaard wrote:
> 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.

Ok.

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

sfc-optimized code

sfc-nonoptimized code could not be generated. Some bounced into some 
swiginac wall.

   ffc-nonoptimized code is not compilable.
   ffc-optimized code is not generated as memory consumption balloons

And note that those figures need to be taken with a grain of salt, as I 
got them by just comparing the visco form with an inner product of two 
vector functions, which I here assumed would take no time at all to compute.

Johan

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