dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday 09 February 2010 02:28:53 Garth N. Wells wrote:
> 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++.
> 
> You can - with MTL4, uBLAS, Armadillo.

and potentially with much better performance.

> > But perhaps the complexity of the wrapper clases/interfaces will
> > prevent the compiler from finding the suitable optimizations.
> 
> I think that it would get complicated, and it would be hard to ensure
> efficiency. Better to leave this to the specialised libraries.

Ok, it would only be for convenience.

Johan