Re: [9fans] Good enough approximation for ape/pcc

["David Leimbach" <leimy2k@gmail.com>]

On 4/10/06, Roman Shaposhnick <rvs@sun.com> wrote:
> On Mon, Apr 10, 2006 at 04:18:56PM -0700, David Leimbach wrote:
> > Interesting example...
> >
> > SomeContainer::iterator it = SomeContainerObject.begin();
> >
> > for (; it != SomeContainerObject.end(); ++it)
> >
> > is probably a lot faster than
> >
> > for(; it != SomeConatinerObject.end(); it++)
> >
> > And I'd bet that not much more than half of the so-called C++
> > programmers out there in the world know why this is.
>
>   If the punch line here is, in fact, what I think it is, then
>   a good optimizing compiler should be able to make these two
>   pretty close in terms of performance.

Perhaps... but only if the iterator is a real pointer.  If the
iterator itself is an object the compiler can't be smart enough to
know all the side effects of the overloaded ++(int) (yes that's how
you overload postfix ++ in C++, even though there is no integer
argument).  In fact, unless the compiler understands that the
overloaded postfix ++ has the same semantics as postfix ++ on a
regular C-style datatype (like int, char etc), there's no way I want
my compiler to optimize anything :-).

So if I wrote my own datatype and implemented the same semantics that
you'd expect for postfix ++ you'd likely find the following
pseudocode:

copy the iterator;
increment *this;
return the copy.

Do you really want to do that at the end of every loop iteration?  And
what if I add some other logic between increment *this and return the
copy, like some mutex locking/unlocking or whatever... the compiler is
helpless to help my code here, and I throw out a copy in every loop.

>
>   I've been doing optimizing compilers at Sun for quite some time
>   now (C/C++ and Fortran) and one thing that I constantly talk
>   to our customers about is that in todays world of opaque CPU
>   design they actually don't know whether 'a = a + 1;' is slower
>   or faster than 'a++;'. So the best advice I can give them
>   is to:
>
>      1. Express semantics, not how to generate code
>      2. Pick a compiler vendor you can trust.
>      3. Make Performance Analysis part of your debugging.

With C++ you need to understand the side effects of the language.  You
could add profiling and logging to your copy constructor for that
iterator above, but you might not understand why you're making so many
copies, throwing them away and having to run both a constructor and a
destructor at the bottom of the loop.

C hasn't inflcited anything like this on it's user base that I've
seen.  There's apparently very good money in knowing these little
esoteric bits about C++ though :).

Dave

>
>
> Thanks,
> Roman.
>