[std-interval] C++ interval std

[Alan Eliasen]

Steve Clamage wrote:


>> Bill Clarke wrote:
>>
>>> This experiment is extremely platform specific, as you probably are
>>> aware.  Most platforms in use today other than x86 will be the other way
>>> around (add-by-value will be faster than add-by-const-ref).

Alan Eliasen wrote:
>>    How can that assertion possibly be made?  As you know, if a parameter
>> is passed by value, then the copy constructor is automatically called
>> for each object (e.g. twice for an add operator) on function entry, and
>> then the destructor is called (twice) on function exit.
> 

Steve Clamage wrote:
> A simple object like complex or interval should have no user-defined
> copy constructor or destructor. That is, the default copy constructor
> generated by the compiler does the right thing and does not need to be
> user-defined. The destructor has nothing to do, and so should not be
> user-defined. In that case, pass-by-value can be optimized into register
> passing with no additional copying.

   You still agree, though, that even if the implementation doesn't do
memory allocation in the constructor, the compiler will still generate a
copy constructor and a destructor, (perhaps pretty simple and efficient)
and these will get normally get called in a pass-by-value.  Again, a
very smart compiler can optimize these away if it realizes that the copy
is unnecessary, but by simply specifying call-by-constant-reference, we
don't have to hope that the compiler is very smart.  We simply eliminate
even the possibility of calling the copy constructor and destructor.

> It is possible to construct a test case where pass-by-value gives worse
> performance than pass-by-reference, and your example does indeed run
> faster with pass-by-reference using Sun compilers at low optimization.

   As noted, it should always be the case that pass-by-value is at least
as slow as pass-by-constant-reference because of the overhead of calling
the copy constructors and destructors, which are almost always
unnecessary and can be trivially eliminated by specifying the calling
convention.  If it's ever faster, I'd argue that it's because the
compiler missed obvious optimizations for pass-by-constant-reference, or
is allocating registers badly.

> At high optimization, the compiler eliminated the loops and all but one
> call to "add", which it inlined. I played with the test case for a short
> time, but was unable to defeat the optimizer with minor changes.

   Heh!  That's a smart compiler!  I had considered adding some
randomization to the values to eliminate this possibility, but the
timing values would have likely been swamped by the random number generator.

-- 
  Alan Eliasen                 |  "When trouble is solved before it
  eliasen at mindspring.com       |    forms, who calls that clever?"
  http://futureboy.us/         |              --Sun Tzu