[std-interval] C++ interval std

Alan Eliasen eliasen at mindspring.com
Wed Apr 5 05:52:50 PDT 2006


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

   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.  The passed-in
objects should not be modified in the interim.  So pass-by-value
*always* has completely unnecessary overhead.  There is absolutely no
reason to copy and subsequently destroy the objects being passed in.
Passing by constant reference will *always* be faster in this respect,
as the copy constructors and destructors will never be called.

   The architecture doesn't matter.  Say, for an addition operator, if
you pass by value, you're *always* incurring the additional overhead of
two unnecessary object copies and two unnecessary object destructions.
There is simply no advantage to pass-by-value over
pass-by-constant-reference in any way.  Your compiler might be smart
enough to optimize out the copies and destructions, but pass-by-value
should *never* be faster with a reasonable compiler.

   Why would one ever want the compiler to potentially call copy
constructors and destructors when we *know* they're a total waste of
cycles?  We can simply prevent that inefficiency in advance for all
compilers.

> (Was this 64-bit code?  I thought x86_64 would be faster with
> pass-by-value since I got the impression the ABI passed parameters in
> registers)

   As I mentioned in my original message, I did the test with both
x86_64 code and x86.  The x86_64 code was 64-bit code, and those were
the numbers cited.  The difference in performance, as I noted, was even
greater on the x86.  (Pass-by-value was about 1.7 times slower on
x86_64, about 2.6 times slower on x86.)  Registers don't enter into the
picture.  Pass-by-constant-reference arguments can be passed in
registers too, of course.

   The difference is that pass-by-value is likely to perform unnecessary
copy constructors and unnecessary destructions.  There is simply no
advantage to this, when we can be smart and tell even the dumbest
compilers that these copying and destroying operations should never even
be attempted.  Silly, useless performance problems (e.g. unnecessary
copy constructor calls) will be avoided in advance.  That's a good thing.

> With inlining then they should be identical (perhaps you could re-run
> your experiment with inlining to verify this?).

   The constructor was inlined.  I fail to see how inlining could ever
make pass-by-value faster, as it always has unnecessary overhead.  A
smart compiler could make it *as* fast as pass-by-constant-reference,
but I can't see how it could ever make it faster.  Specifying
pass-by-constant-reference would simply eliminate a source of
inefficiency with broken compilers.

> Surely it is possible to permit the implementer to choose the parameter
> passing convention, between pass-by-value and pass-by-const-ref?  It
> should have no visible impact on the programmer which is used.

   I agree that it should have no visible impact on the library user.
But there is really no reason to *not* use pass-by-constant-reference.
 Even if you are doing lazy operations and need to modify some part of
the passed-in object, you can always use the "mutable" keyword.

   In short, if you can find a compiler that does pass-by-value faster
than pass-by-constant-ref, I'll show you a broken compiler.

   Specifying pass-by-constant-reference also allows the compiler to
detect and prevent accidental modification of the objects being passed
in, or erroneous programmer attempts to modify a passed-in object (which
is probably never what you want to do, and should always fail.)

   Const-correctness is also a desirable goal, in my opinion.  It
becomes prohibitive and breaks code to add const-correctness late in the
game, which is why we should get it right the first time.

   If you're interested, you can dowload the really simple test programs
here and run them on your own computer:

   http://futureboy.us/temp/Interval.h
   http://futureboy.us/temp/Interval.cc

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


More information about the Std-interval mailing list