ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Aug 29, 2009 at 02:49:42PM +0200, Kristian Oelgaard wrote:
> Quoting Anders Logg <logg@xxxxxxxxx>:
>
> > On Fri, Aug 21, 2009 at 12:56:32PM +0200, Kristian Oelgaard wrote:
> > > Quoting FFC <ffc@xxxxxxxxxx>:
> > >
> > > > One or more new changesets pushed to the primary ffc repository.
> > > > A short summary of the last three changesets is included below.
> > > >
> > > > changeset:   1621:96ac3d15dc2c4dbbb5c4fdaefbc8581684c43cf2
> > > > tag:         tip
> > > > user:        "Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>"
> > > > date:        Fri Aug 21 11:49:02 2009 +0100
> > > > files:       ffc/compiler/compiler.py ffc/compiler/integrals.py
> > > > ffc/compiler/tensor/tensorgenerator.py ffc/compiler/ufcformat.py
> > > > test/regression/reference/quadrature/Biharmonic.h
> > > > test/regression/reference/quadrature/Constant.h
> > > > test/regression/reference/quadrature/Elasticity.h
> > > > test/regression/reference/quadrature/Equation.h
> > > > test/regression/reference/quadrature/FacetIntegrals.h
> > > > test/regression/reference/quadrature/FunctionOperators.h
> > > > test/regression/reference/quadrature/Heat.h
> > > > test/regression/reference/quadrature/Mass.h
> > > > test/regression/reference/quadrature/MixedPoisson.h
> > > > test/regression/reference/quadrature/NavierStokes.h
> > > > test/regression/reference/quadrature/NeumannProblem.h
> > > > test/regression/reference/quadrature/Optimization.h
> > > > test/regression/reference/quadrature/Poisson.h
> > > > test/regression/reference/quadrature/PoissonDG.h
> > > > test/regression/reference/quadrature/PoissonSystem.h
> > > > test/regression/reference/quadrature/QuadratureElement.h
> > > > test/regression/reference/quadrature/ReactionDiffu
> > > >  sion.h test/regression/reference/quadrature/StabilisedStokes.h
> > > > test/regression/reference/quadrature/Stokes.h
> > > > test/regression/reference/quadrature/SubDomains.h
> > > > test/regression/reference/quadrature/TensorWeightedPoisson.h
> > > > test/regression/reference/quadrature/VectorLaplaceGradCurl.h
> > > > test/regression/reference/tensor/Constant.h
> > > > test/regression/reference/tensor/Elasticity.h
> > > > test/regression/reference/tensor/Equation.h
> > > > test/regression/reference/tensor/FacetIntegrals.h
> > > > test/regression/reference/tensor/Heat.h
> > > > test/regression/reference/tensor/Mass.h
> > > > test/regression/reference/tensor/MixedPoisson.h
> > > > test/regression/reference/tensor/NavierStokes.h
> > > > test/regression/reference/tensor/NeumannProblem.h
> > > > test/regression/reference/tensor/Optimization.h
> > > > test/regression/reference/tensor/Poisson.h
> > > > test/regression/reference/tensor/PoissonSystem.h
> > > > test/regression/reference/tensor/ReactionDiffusion.h
> > > > test/regression/reference/tensor/StabilisedStokes.h
> > > > test/regression/reference/tensor/Stokes.h test/regres
> > > >  sion/reference/tensor/SubDomains.h
> > > > test/regression/reference/tensor/VectorLaplaceGradCurl.h
> > > > test/regression/test.py test/unit/test_reduce_operations2.py
> > > > description:
> > > > Use loop to reset element tensor. Bug fix in regression test.py when same
> > > > file fails for both representations.
> > >
> > > I changed the generated code inside the tabulate_tensor() function, such
> > that we
> > > use a loop:
> > >
> > > // Reset values of the element tensor block
> > > for (unsigned int j = 0; j < 10000; j++)
> > >   A[j] = 0;
> > >
> > > instead of:
> > >
> > > A[0] = 0;
> > > ...
> > > A[9999] = 0;
> > >
> > > which saves an awful lot of lines for higher order elements.
> > >
> > > No loop is generated if the tensor only has one entry e.g., functional:
> > >
> > > A[0] = 0;
> > >
> > > We can set the limit for when to use one or the other reset method to
> > whatever
> > > we like of course, but most compiler should be able to figure the simple
> > loop
> > > out with no overhead.
> >
> > Would it be good to use std::fill for this?
>
> I don't know how the efficiency between this function and the loop compares, but
> it shouldn't be hard to change of course.

I think GCC will pick the best option (loop, unroll, or other methods)
depending on the size of the array. At least this page claims that is
the case for memset which is the C equivalent of std::fill. I would
think the same is true for std::fill.

http://gcc.gnu.org/gcc-4.3/changes.html

--
Anders

Attachment: signature.asc
Description: Digital signature