From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60604101707v6214a809h516a223bf5d14a06@mail.gmail.com> Date: Mon, 10 Apr 2006 17:07:03 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Good enough approximation for ape/pcc In-Reply-To: <20060410235110.GM28006@submarine> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <229aaef51090aa24504f7f55d106b8c2@quanstro.net> <6.0.2.0.0.20060411100415.01cb6490@pop.monitorbm.co.nz> <200604102304.k3AN4vJN003576@haides.silverbrookresearch.com> <3e1162e60604101618u4e4ce0c1yac9f0246a116a2e5@mail.gmail.com> <20060410235110.GM28006@submarine> Topicbox-Message-UUID: 34773996-ead1-11e9-9d60-3106f5b1d025 On 4/10/06, Roman Shaposhnick wrote: > On Mon, Apr 10, 2006 at 04:18:56PM -0700, David Leimbach wrote: > > Interesting example... > > > > SomeContainer::iterator it =3D SomeContainerObject.begin(); > > > > for (; it !=3D SomeContainerObject.end(); ++it) > > > > is probably a lot faster than > > > > for(; it !=3D 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 =3D 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. >