[Dune-devel] [Dune-Bugs][#683] Requesting value_type and unary operator-() in FieldVector.

Oliver Sander sander at igpm.rwth-aachen.de
Mon Jun 29 16:26:33 CEST 2015


I just tested binary operator+ in FieldVector, because that was something I wanted to know anyway.

Unfortunately, I am not a skilled reader of assembler language, but to me it seems that

FieldVector a,b,c [snip]

c = a+b;

does not result in temporaries or additional loops.  At last parts of our old arguments against
binary operators and unary operator- appear obsolete.

Cheers,
Oliver

Am 29.06.2015 um 16:13 schrieb Christian Engwer:
> As we decided a while ago not to implement them I didn't bother with
> starting a new discussion, but feel free to open a dedicated bug
> report. This "multiple-suggestions" issue should not be reopend, as
> parts of it are implemented.
> 
> Christian
> 
> On Mon, Jun 29, 2015 at 03:56:07PM +0200, Jorrit Fahlke wrote:
>> Am Mon, 29. Jun 2015, 10:07:01 +0200 schrieb Christian Engwer:
>>> Date: Mon, 29 Jun 2015 10:07:01 +0200
>>> From: Christian Engwer <christian.engwer at uni-muenster.de>
>>> To: Oliver Sander <sander at igpm.rwth-aachen.de>
>>> Cc: "dune-devel at dune-project.org" <dune-devel at dune-project.org>
>>> Subject: Re: [Dune-devel] [Dune-Bugs][#683] Requesting value_type and unary
>>>  operator-() in FieldVector.
>>>> What's so bad about C++11?  We use that all over the place.  And did you measure the impact
>>>> of those "expensive temporaries"?  I wouldn't be surprised if you had a hard time seeing their
>>>> effect at all.  :-)
>>>
>>> for 2.4 we decided on compiler compatibilities which prohibit the use
>>> of std::move _in_ the core modules. If you want to measure the impact
>>> feel free, but std::move was introduced exactly to avoid these
>>> temporaries, as (in many cases) the compiler can't do this for you.
>>
>> I have to agree with Oli here.
>>
>> 1. std::move has nothing to do with it.  Not for FieldVector, which keeps all
>>    its data within the class, so moves would be just as expensive as copies.
>>    (And possibly even more expensive, because I've seen compilers that don't
>>    do copy constructor elision any more if you explicitly specify std::move,
>>    but that situation has hopefully improved since.)
>>
>> 2. I doubt that after optimization there would be much left of a temporary in
>>    the assembler code (for FieldVector; it depends on the class, of course).
>>
>> Regards,
>> Jö.
>>
>> -- 
>> Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
>> University of Münster, Orleans-Ring 10, D-48149 Münster
>> Tel: +49 251 83 35146 Fax: +49 251 83 32729
>>
>> featured product: Debian GNU/Linux - http://www.debian.org
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20150629/d2218e5a/attachment.sig>


More information about the Dune-devel mailing list