2012/3/22 Kristian B. Ølgaard <email address hidden>:
> 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'm considering some improvements to the graph code in UFL,
as well as enabling derivative of compound expressions.
Maybe we can make an FFC mode based on that later.
It seems to be the translation back and forth between tensor
and scalar quantities that blows up for the visco example,
and the graph strategy doesn't protect fully against that yet.

I'm still finding memory improvements.
Lots of empty dicts for example, 280 wasted bytes each...

Martin