On Thu, Mar 22, 2012 at 10:23:40AM -0000, 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.

That sounds good.

--
Anders


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