[SDL] Pygame-1.0 Released

Pete Shinners shredwheat at mediaone.net
Tue Apr 10 00:13:05 PDT 2001

> > <rant>
> > Folks : if you're GOING to make arguments like this anyways, BACK IT UP!
> > with nice solid provable facts.  Argghh.  I thought logic was a required
> > subject for anyone who programmed!
> > </rant>
> >
> > Any decent optimizer will clean this up - my experiences with g++ (not
> > the most optimal of compilers/linkers anymore) suggest it can handle this
> > fine...
> What it can handle fine?

He's saying g++ can handle optimizing the wrapper so it isn't slow.  My 
personal stance on this, however, based on experience, is that if you are 
writing portable code, it's better not to rely on a compiler optimizing for 
you.  Not all compilers can optimize, and not all do a very good job of it 
either.  If you know what you are doing, it's better for you to do what you 
can to speed things up.  Then you can expect better results on whatever 
platforms it goes to.  C/C++ gets you about as close to assembly as any other 
programming language that I know of, so it's only slightly worse than doing 
assembly, and it's still portable.

> Yes. C and C++ code have a same speed mainly due to the fact that C is
> subset of C++.

That isn't necessarily the reason, unless you are writing C++ code that is 
pretty must just C anyway.  If you go heavily into the C++ realm, it's going 
to use very different code than a C version would, and so if they time about 
the same at that point, you can't just say it's because C is just a subset of 

> But I can supposed that the power of C++ is in extensions, such as
> templates and overloading.
> According to my observations, template based libs are clear and faster then
> C libs. This is an origin of my wonder about suggestion to write wrappers
> around C libs.

I'm not sure I'd agree that the are clearer.  As far as faster, I've never 
timed them so I wouldn't know.

> I think that g++ code can be usually improved with assembler by factor
> 1.2-1.6, MSVC 5.0 - by factor 1.05-1.1.
> <math> qsort work 4 times slower then STL sort.
> This is my very subjective opinion.

qsort() uses a function callback, which means that you function call overhead 
times the number of iterations it needs to go through.  Definately not going 
to be very speedy if you have a lot of iterations.  You'd be better off 
writing your own sort code and optimizing it.  You might even beat STL.  Not 
sure how it works exactly.

More information about the SDL mailing list