dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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.

> 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.

Garth


> --
> Anders