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

[Roman Shaposhnick <rvs@sun.com>]

On Mon, Apr 10, 2006 at 05:07:03PM -0700, David Leimbach wrote:
> On 4/10/06, Roman Shaposhnick <rvs@sun.com> wrote:
> > On Mon, Apr 10, 2006 at 04:18:56PM -0700, David Leimbach wrote:
> >   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.

  Or a carefully written one.

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

  Good. The punch line is exactly what I though it would be ;-) I mean,
  with C++ you never know.

> 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 guess I made a stronger statement that I wanted to. I was more concerned
  about somebody using prepackaged iterators (STL for example) not
  realizing the difference between ++a and a++. Somehow I feel that if a
  person took time to *explicitly* write the copy/return sequence (like
  you did in your example) than it would take a really unexperienced
  C++ programmer to not recognize the difference.

  Now, prepackaged iterators are usually part of the C++ environment, hence
  they can exploit all sorts of optimization opportunities available
  in that particular system (yes these are mostly pragmas, but hey -- they
  are invisible to an end user).

  Once again, don't get me wrong -- I'm not claiming that a properly written
  implementation will always equate ++a with a++ in terms of performance,
  but in certain cases it might.

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

  I disagree somewhat. My point was -- that C++ is no longer the only
  thing you are supposed to understand inside and out if you really
  want to know what happens when your code gets executed. Modern hardware
  is very much that way too. Which means that it doesn't really matter
  what language you use -- you never really sure about performance
  implications of even the simplest of constructs (anybody who have touched
  Itanium even with a six foot pole would understand ;-)).

  My point was -- there's no way you can survive without #3 anyway, which
  means that instead of worrying about everything at a coding level -- just
  code away (and yes I agree -- understanding language semantics helps a
  great deal) the most clean code you can possibly afford and rely on
  performance analysis to catch surprises.

Thanks,
Roman.