dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Monday 08 February 2010 13:57:34 Johan Hake wrote:
> On Monday 08 February 2010 13:46:20 Anders Logg wrote:
> > On Mon, Feb 08, 2010 at 01:43:35PM -0800, Johan Hake wrote:
> > > On Monday 08 February 2010 13:41:29 Anders Logg wrote:
> > > > On Mon, Feb 08, 2010 at 01:35:16PM -0800, Johan Hake wrote:
> > > > > On Monday 08 February 2010 01:15:12 Anders Logg wrote:
> > > > > > On Sun, Feb 07, 2010 at 11:25:28PM +0000, Garth N. Wells wrote:
> > > > > > > Anders Logg wrote:
> > > > > > > > On Sun, Feb 07, 2010 at 10:58:44PM +0000, Garth N. Wells 
wrote:
> > > > > > > >> Anders Logg wrote:
> > > > > > > >>> This looks a like a non-optimal solution. Are you returning
> > > > > > > >>> the mesh by value? That will lead to creation of a
> > > > > > > >>> temporary and copying of the entire refined mesh.
> > > > > > > >>
> > > > > > > >> So they used say ;). Apparently modern compilers are all
> > > > > > > >> clever enough not to.
> > > > > > > >>
> > > > > > > >> Garth
> > > > > > > >
> > > > > > > > Is that really so? Do you have any good references that
> > > > > > > > explain this in detail?
> > > > > > >
> > > > > > >   http://en.wikipedia.org/wiki/Return_value_optimization
> > > > > > >
> > > > > > > and from 'man gcc'
> > > > > > >
> > > > > > > -fno-elide-constructors
> > > > > > >   The C++ standard allows an implementation to omit creating a
> > > > > > > temporary which is only used to initialize another object of
> > > > > > > the same type. Specifying this option disables that
> > > > > > > optimization, and forces G++ to call the copy constructor in
> > > > > > > all cases.
> > > > > >
> > > > > > ok, seems correct. I tried the following piece of code with some
> > > > > > debugging added to the copy constructor and assignment operator
> > > > > > in class Mesh:
> > > > > >
> > > > > >   Mesh refined_mesh_1 = UniformMeshRefinement::refine(mesh);
> > > > > >
> > > > > >   Mesh refined_mesh_2;
> > > > > >   refined_mesh_2 = UniformMeshRefinement::refine(mesh);
> > > > > >
> > > > > > The first refinement does not lead to any call to either of the
> > > > > > copy constructor or assignment operator.
> > > > > >
> > > > > > The second call leads to one call to the assignment operator.
> > > > > >
> > > > > > This is expected but means we need to be careful with how the
> > > > > > refinement is called (on the same line as initialization).
> > > > > >
> > > > > > Should we have a look and see if there are other places where we
> > > > > > could return by value?
> > > > >
> > > > > The operator* and operator+ were explicitly not included because
> > > > > they needed to be implemented as a return by value method. Now they
> > > > > can be added in the same way as the Python equivalents I think.
> > > >
> > > > You mean in the linear algebra interface?
> > >
> > > Yes.
> >
> > You could try. I wouldn't mind being able to do A = B + C in C++.
> >
> > But perhaps the complexity of the wrapper clases/interfaces will
> > prevent the compiler from finding the suitable optimizations.
> 
> Yes, you mentioned that.
> 
> I think the implementation would just look something like:
> 
>    GenericMatrix opertor+(const GenericMatrix& A)
>    {
>       GenericMatrix B(*this);
>       B += A; // or B.axpy(1.0, A, false);
>       return B;
>    }

The above is of course not valid as GenericMatrix cannot be instantiated. If 
we want to do it this way we need to implement it in the different subclasses. 
Any other suggestions?

Johan

> Which would give the compiler a fair chance of succeeding.
> 
> Johan
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>