dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 08, 2012 at 01:14:40PM +0000, Garth N. Wells wrote:
> On 8 March 2012 12:36, Johan Hake <hake.dev@xxxxxxxxx> wrote:
> > On Thu, Mar 8, 2012 at 12:40 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >> The obvious first step to simplifying dolfin:Array is to minimise its
> >> use. Any objections to changing dolfin::Array to std::vector in the
> >> GenericFoo abstract linear algebra classes?
> >
> > It is only GenericVector that uses Array at the moment. Are you
> > thinking of changing all double* to std::vector too?
> >
> >> The consequence on the Python side will be copying of data. I don't
> >> think that this is an issue since the interfaces are low-level and
> >> only likely used from Python for prototyping or debugging. In such
> >> cases, I would expect that other aspects of the Python overhead to
> >> swamp to cost of the data copy.
> >
> > Where it makes sense I am inclined to keep the Array class, and even
> > if get,set are low level functionalities they are something that
> > potentially will be called many times.
>
> Will they ever be called many times from Python in production code?
> They will be called from low-level C++ code, but using std::vector
> will make no difference in this case since it will be passed by
> reference.
>
> >  I do not have a benchmark
> > telling you that it makes a difference, but from my perspective it
> > doesn't make sense to change to std::vector just for the sake of it.
> >
>
> The point is to simplify dolfin::Array. The most important usage is in
> GenericFunction::eval, in which case it has fixed length. It was the
> usage of dolfin::Array in this context that Joachim picked up the
> performance issue. I favour dolfin::Array being as simple as possible
> and targeted to handle the call-back type situation in
> GenericFunction::eval both efficiently and safely (from both Python
> and C++).

I agree completely with this. My take is that there is a set of
operations that we should allow for convenience (one is matrix random
access that we've discussed many times before) and they don't need to
be very efficient.

But I don't know the implications of removing the get/set operations
for the SWIG layer.

--
Anders



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