← Back to team overview

dolfin team mailing list archive

Re: Use of Array<type> class (in assembly)

 

On Jan 27, 2012 12:58 AM, "Anders Logg" <logg@xxxxxxxxx> wrote:
>
> On Wed, Jan 25, 2012 at 03:21:12PM +0100, Joachim Berdal Haga wrote:
> > Hi,
> >
> > I'm looking a bit on assembly performance at the moment. It looks like
> > a lot of time (almost 25% in poisson/linear lagrange) of the time is
> > spent in these two lines of GenericFunction::evaluate():
> >
> >   Array<double> _values(value_size(), values);
> >   const Array<double> x(cell.geometric_dimension,
> > const_cast<double*>(coordinates));
> >
> > This seems to be because of the instantiation of boost::shared_arrays.
> > The ownership of the array data is not transferred (the data will be
> > deleted by the caller of evaluate()), so this does not really add any
> > safety.
> >
> > I don't have a complete picture of how Array<> is used, does the
> > Python layer rely on the shared semantics (in other places)? If not,
> > it might be better to make them non-shared and create copies for use
> > in Python where needed.
>
> Would it help if we do this:
>
> 1. Make GenericFunction::evaluate an inline function that just calls
>   a new version of GenericFunction::eval.
>
> 2. The new version of GenericFunction::eval has the same
>   implementation as the current evaluate() function.
>
> The result would be that we get two eval() functions, one with plain
> pointers and one with Array(). A C++ user (and the JIT-compiled
> expressions) would use the plain pointer version, while the Array
> version gets wrapped for Python subclassing (where I assume the extra
> cost will not make a difference).

I would discourage this solution as it diverge the interfaces between C++
and Python, introduce an interface change which cannot be backported and it
circumvents the original problem of Array<> being costly to instantiate.

Johan

> --
> Anders
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

Follow ups

References