On Mon, Apr 10, 2006 at 05:07:03PM -0700, David Leimbach wrote: > On 4/10/06, Roman Shaposhnick <[EMAIL PROTECTED]> 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.
