compiler stage 3 output

On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
> ** Changed in: ffc
> Milestone: 0.7.1 => 0.9.1

Would it be possible to move the quadrature optimizations to stage 3?
Or are they an integral part of the code generation in stage 4?

--
Anders

On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
> On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
>> ** Changed in: ffc
>>     Milestone: 0.7.1 => 0.9.1
>
> Would it be possible to move the quadrature optimizations to stage 3?
> Or are they an integral part of the code generation in stage 4?

The current optimisations take place after the code has been generated. So it is not possible to move it, but maybe some other optimisations can be implemented although I don't see how this should work right now.

Kristian

> --
> Anders
>
> --
> compiler stage 3 output
> https://bugs.launchpad.net/bugs/424367
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
>
> Status in FEniCS Form Compiler: Confirmed
>
> Bug description:
> When compiling a form one will always get the output:
>
> Compiler stage 3: Optimizing form representation
> ------------------------------------------------
>  Optimization of tensor contraction representation currently broken (to be fixed).
>
> even if the quadrature representation is being used, which is the default.
>
> This output should only become active if:
> ffc -O -r tensor foo.ufl
> was invoked on the command line.
>
> In all other cases there should only be 4 stages.
>
>
>

On Mon, Feb 08, 2010 at 11:20:33AM -0000, Kristian B. Ølgaard wrote:
>
> On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
> > On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
> >> ** Changed in: ffc
> >>     Milestone: 0.7.1 => 0.9.1
> >
> > Would it be possible to move the quadrature optimizations to stage 3?
> > Or are they an integral part of the code generation in stage 4?
>
> The current optimisations take place after the code has been generated.
> So it is not possible to move it, but maybe some other optimisations can
> be implemented although I don't see how this should work right now.
>
> Kristian

ok. I thought you operated on some abstract code or intermediate
representation. Isn't it very costly to operate on the generated code?
Then you have to parse it (?) to know what it means.

It's not very high priority to do this right now. But just have a look
at the comment in quadratureoptimization.py.

I'll close this bug now.

--
Anders

> >
> >
> > Status in FEniCS Form Compiler: Confirmed
> >
> > Bug description:
> > When compiling a form one will always get the output:
> >
> > Compiler stage 3: Optimizing form representation
> > ------------------------------------------------
> >  Optimization of tensor contraction representation currently broken (to be fixed).
> >
> > even if the quadrature representation is being used, which is the default.
> >
> > This output should only become active if:
> > ffc -O -r tensor foo.ufl
> > was invoked on the command line.
> >
> > In all other cases there should only be 4 stages.
> >
> >
> >
>

On 8 February 2010 13:10, Anders Logg <email address hidden> wrote:
> On Mon, Feb 08, 2010 at 11:20:33AM -0000, Kristian B. Ølgaard wrote:
>>
>> On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
>> > On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
>> >> ** Changed in: ffc
>> >>     Milestone: 0.7.1 => 0.9.1
>> >
>> > Would it be possible to move the quadrature optimizations to stage 3?
>> > Or are they an integral part of the code generation in stage 4?
>>
>> The current optimisations take place after the code has been generated.
>> So it is not possible to move it, but maybe some other optimisations can
>> be implemented although I don't see how this should work right now.
>>
>> Kristian
>
> ok. I thought you operated on some abstract code or intermediate
> representation. Isn't it very costly to operate on the generated code?
> Then you have to parse it (?) to know what it means.

Parts of the optimisation like reducing the range of the loops by eliminating zeros in the basis values is done when tabulating the values, this can be done on the intermediate representation (stage 3) but I don't see any real gain in code readability or performance in doing this.
The other optimisations work on the generated expression which is necessary to identify all terms that can be optimised, it is rather costly both in memory and time, which is why I'll be looking into another approach.

> It's not very high priority to do this right now. But just have a look
> at the comment in quadratureoptimization.py.

Done.

Kristian

> I'll close this bug now.
>
> --
> Anders
>
>
>> >
>> >
>> > Status in FEniCS Form Compiler: Confirmed
>> >
>> > Bug description:
>> > When compiling a form one will always get the output:
>> >
>> > Compiler stage 3: Optimizing form representation
>> > ------------------------------------------------
>> >  Optimization of tensor contraction representation currently broken (to be fixed).
>> >
>> > even if the quadrature representation is being used, which is the default.
>> >
>> > This output should only become active if:
>> > ffc -O -r tensor foo.ufl
>> > was invoked on the command line.
>> >
>> > In all other cases there should only be 4 stages.
>> >
>> >
>> >
>>
>
> --
> compiler stage 3 output
> https://bugs.launchpad.net/bugs/424367
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
>
> Status in FEniCS Form Compiler: Fix Committed
>
> Bug description:
> When compiling a form one will always get the output:
>
> Compiler stage 3: Optimizing form representation
> ------------------------------------------------
>  Optimization of tensor contraction representation currently broken (to be fixed).
>
> even if the quadrature representation is being used, which is the default.
>
> This output should only become active if:
> ffc -O -r tensor foo.ufl
> was invoked on the command line.
>
> In all other cases there should only be 4 stages.
>
>
>

On Mon, Feb 08, 2010 at 12:33:46PM -0000, Kristian B. Ølgaard wrote:
>
> On 8 February 2010 13:10, Anders Logg <email address hidden> wrote:
> > On Mon, Feb 08, 2010 at 11:20:33AM -0000, Kristian B. Ølgaard wrote:
> >>
> >> On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
> >> > On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
> >> >> ** Changed in: ffc
> >> >>     Milestone: 0.7.1 => 0.9.1
> >> >
> >> > Would it be possible to move the quadrature optimizations to stage 3?
> >> > Or are they an integral part of the code generation in stage 4?
> >>
> >> The current optimisations take place after the code has been generated.
> >> So it is not possible to move it, but maybe some other optimisations can
> >> be implemented although I don't see how this should work right now.
> >>
> >> Kristian
> >
> > ok. I thought you operated on some abstract code or intermediate
> > representation. Isn't it very costly to operate on the generated code?
> > Then you have to parse it (?) to know what it means.
>
> Parts of the optimisation like reducing the range of the loops by eliminating zeros in the basis values is done when tabulating the values, this can be done on the intermediate representation (stage 3) but I don't see any real gain in code readability or performance in doing this.
> The other optimisations work on the generated expression which is necessary to identify all terms that can be optimised, it is rather costly both in memory and time, which is why I'll be looking into another approach.

ok, I just imagine it would be more efficient to manipulate/optimize
the expression if it were stored as some kind of symbolic AST instead
of as a string. Then it would fit naturally into stage 3.

> > It's not very high priority to do this right now. But just have a look
> > at the comment in quadratureoptimization.py.
>
> Done.

Looks good.

--
Anders

> Kristian
>
> > I'll close this bug now.
> >
> >
> >
> >> >
> >> >
> >> > Status in FEniCS Form Compiler: Confirmed
> >> >
> >> > Bug description:
> >> > When compiling a form one will always get the output:
> >> >
> >> > Compiler stage 3: Optimizing form representation
> >> > ------------------------------------------------
> >> >  Optimization of tensor contraction representation currently broken (to be fixed).
> >> >
> >> > even if the quadrature representation is being used, which is the default.
> >> >
> >> > This output should only become active if:
> >> > ffc -O -r tensor foo.ufl
> >> > was invoked on the command line.
> >> >
> >> > In all other cases there should only be 4 stages.
> >> >
> >> >
> >> >
> >>
> >
> >
> > Status in FEniCS Form Compiler: Fix Committed
> >
> > Bug description:
> > When compiling a form one will always get the output:
> >
> > Compiler stage 3: Optimizing form representation
> > ------------------------------------------------
> >  Optimization of tensor contraction representation currently broken (to be fixed).
> >
> > even if the quadrature representation is being used, which is the default.
> >
> > This output should only become active if:
> > ffc -O -r tensor foo.ufl
> > was invoked on the command line.
> >
> > In all other cases there should only be ...

On 8 February 2010 13:43, Anders Logg <email address hidden> wrote:
> On Mon, Feb 08, 2010 at 12:33:46PM -0000, Kristian B. Ølgaard wrote:
>>
>> On 8 February 2010 13:10, Anders Logg <email address hidden> wrote:
>> > On Mon, Feb 08, 2010 at 11:20:33AM -0000, Kristian B. Ølgaard wrote:
>> >>
>> >> On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
>> >> > On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
>> >> >> ** Changed in: ffc
>> >> >>     Milestone: 0.7.1 => 0.9.1
>> >> >
>> >> > Would it be possible to move the quadrature optimizations to stage 3?
>> >> > Or are they an integral part of the code generation in stage 4?
>> >>
>> >> The current optimisations take place after the code has been generated.
>> >> So it is not possible to move it, but maybe some other optimisations can
>> >> be implemented although I don't see how this should work right now.
>> >>
>> >> Kristian
>> >
>> > ok. I thought you operated on some abstract code or intermediate
>> > representation. Isn't it very costly to operate on the generated code?
>> > Then you have to parse it (?) to know what it means.
>>
>> Parts of the optimisation like reducing the range of the loops by eliminating zeros in the basis values is done when tabulating the values, this can be done on the intermediate representation (stage 3) but I don't see any real gain in code readability or performance in doing this.
>> The other optimisations work on the generated expression which is necessary to identify all terms that can be optimised, it is rather costly both in memory and time, which is why I'll be looking into another approach.
>
> ok, I just imagine it would be more efficient to manipulate/optimize
> the expression if it were stored as some kind of symbolic AST instead
> of as a string. Then it would fit naturally into stage 3.

This is actually almost what is going on. The quadrature transformers takes the UFL expression tree and in the case to non optimised quadrature strings are generated on the fly. For the optimised version symbols are created instead and then I use these symbols to manipulate the expression in order to reduce the total operation count needed to evaluate the expression.

So I guess if we move the transformers to before stage 3 the optimisations (symbol manipulations) could take place at stage 3, then the code generation stage would just be printing strings.

Kristian

>> > It's not very high priority to do this right now. But just have a look
>> > at the comment in quadratureoptimization.py.
>>
>> Done.
>
> Looks good.
>
> --
> Anders
>
>
>> Kristian
>>
>> > I'll close this bug now.
>> >
>> >
>> >
>> >> >
>> >> >
>> >> > Status in FEniCS Form Compiler: Confirmed
>> >> >
>> >> > Bug description:
>> >> > When compiling a form one will always get the output:
>> >> >
>> >> > Compiler stage 3: Optimizing form representation
>> >> > ------------------------------------------------
>> >> >  Optimization of tensor contraction representation currently broken (to be fixed).
>> >> >
>> >> > even if the quadrature representation is being used, which is the default.
>> >> >
>> >> > This output shoul...

On Mon, Feb 08, 2010 at 01:07:21PM -0000, Kristian B. Ølgaard wrote:
>
> On 8 February 2010 13:43, Anders Logg <email address hidden> wrote:
> > On Mon, Feb 08, 2010 at 12:33:46PM -0000, Kristian B. Ølgaard wrote:
> >>
> >> On 8 February 2010 13:10, Anders Logg <email address hidden> wrote:
> >> > On Mon, Feb 08, 2010 at 11:20:33AM -0000, Kristian B. Ølgaard wrote:
> >> >>
> >> >> On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
> >> >> > On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
> >> >> >> ** Changed in: ffc
> >> >> >>     Milestone: 0.7.1 => 0.9.1
> >> >> >
> >> >> > Would it be possible to move the quadrature optimizations to stage 3?
> >> >> > Or are they an integral part of the code generation in stage 4?
> >> >>
> >> >> The current optimisations take place after the code has been generated.
> >> >> So it is not possible to move it, but maybe some other optimisations can
> >> >> be implemented although I don't see how this should work right now.
> >> >>
> >> >> Kristian
> >> >
> >> > ok. I thought you operated on some abstract code or intermediate
> >> > representation. Isn't it very costly to operate on the generated code?
> >> > Then you have to parse it (?) to know what it means.
> >>
> >> Parts of the optimisation like reducing the range of the loops by eliminating zeros in the basis values is done when tabulating the values, this can be done on the intermediate representation (stage 3) but I don't see any real gain in code readability or performance in doing this.
> >> The other optimisations work on the generated expression which is necessary to identify all terms that can be optimised, it is rather costly both in memory and time, which is why I'll be looking into another approach.
> >
> > ok, I just imagine it would be more efficient to manipulate/optimize
> > the expression if it were stored as some kind of symbolic AST instead
> > of as a string. Then it would fit naturally into stage 3.
>
> This is actually almost what is going on. The quadrature transformers
> takes the UFL expression tree and in the case to non optimised
> quadrature strings are generated on the fly. For the optimised version
> symbols are created instead and then I use these symbols to manipulate
> the expression in order to reduce the total operation count needed to
> evaluate the expression.
>
> So I guess if we move the transformers to before stage 3 the
> optimisations (symbol manipulations) could take place at stage 3, then
> the code generation stage would just be printing strings.

Yes, that sounds very good. It's what we do in the tensor
representation. Stage 2 computes an IR consisting of the values of the
big tensor and indices and dimensions to loop. Then that IR is
modified in stage 3 and stage 4 just takes the IR and translates to
C++ code.

--
Anders

> Kristian
>
> >> > It's not very high priority to do this right now. But just have a look
> >> > at the comment in quadratureoptimization.py.
> >>
> >> Done.
> >
> > Looks good.
> >
> >
> >
> >> Kristian
> >>
> >> > I'll close this bug now.
> >> >
> >> >
> >> >
> >> >> >
> >> >> >
> >> >> > Status in FEniCS Form Compiler: Confirmed
> >> >> >
> >> >> > Bug description:
> >> >>...