Re: [GD-General] RE: [Algorithms] C style math libraries versus "proper" C++ maths

[Scoubidou944 \(Hotmail\) <sco...@ho...>]

I remember some passed days in game programming.

3D matrix operations and its implementation on PIII 900MHz.
a class containing an array of float, something very simple.
And for basic operation, you can pass on reference (using & keyword) or =
pointer (* keyword) or pass directly the array (so all floats are placed=
 into stack.
Case 1 & Case 2 : only 4 bytes on the stack but all computing is using a=
 deference (-> operator)
Case 3 : for 4x4 array (x,y,z,w), 16 floats so 16 x 4 =3D 64 bytes per m=
atrix.

At this time the fastest method was the 3.

So better code isn't always the faster one ;)

  ----- Original Message ----- 
  From: Stephane Etienne 
  To: gam...@li... 
  Sent: Saturday, March 25, 2006 11:00 PM
  Subject: [GD-General] RE: [Algorithms] C style math libraries versus "=
proper" C++ maths


  To do a fair comparison, we would need to see your C implementation. Y=
ou implemented operator+, operator*, etc but these return a temporary wh=
ich may or may not be optimized out. The best way to find out is to look=
 at the disassembly. Also, different compiler may do different things. If your C version usage does not need a=
ny temporaries, then it will most likely be faster indeed. However if u =
use operator+=3D or operator *=3D, you should definitely get similar per=
formances. Also never profile debug builds. Even functions marked inline will not be inlined in debug builds for e=
xample.



  Since C99 support the inline keyword, you should not see any differenc=
e between a C and C++ implementation. As Jarkko said, beware of exceptio=
ns. They can easily make your code a lot slower.



  I have a few suggestions regarding your code. They will not improve ex=
ecution speed but you wrote several things that are unnecessary:



  -          the inline keyword is not necessary for inlined method insi=
de the class body (less to read means it is also easier to read)

  -          Initializer list are only useful when the default construct=
or of constructed objects actually does something. Your use of initializ=
er list here does not buy you anything.

  -          Prefer C style functions over C++ member methods. See Scott=
 Meyer, "How non member functions improve encapsulation" for more info.

  -          No need to have a default destructor that does not do anyth=
ing for non virtual classes.

  -          No need to implement the default copy operator unless you n=
eed to do something special. In your case, the default copy constructors=
 and operators provided by the compiler will do just fine.

  -          Your use of statics to implement zero vector, etc could mes=
s with the cache on platforms such the Xbox 360 and the PS3.



  Understand your code. Look at the disassembly and profile over an over=
 again to understand why something is slow.



  Stephan.



  -----Original Message-----
  From: gda...@li... [mailto:gdalgorith=
ms-...@li...] On Behalf Of Richard Fabian
  Sent: Saturday, March 25, 2006 5:40 AM
  To: gda...@li...
  Subject: [Algorithms] C style math libraries versus "proper" C++ maths



  We've always used a math library that has a function per operation you=
 want to apply to each math construct. We do this because "back in the d=
ay" we found that C++ style math libraries lead to lots of unecessary de=
structors being made... at least in debug, but we suspected in release also. 

  its been a few years, two major microsoft compilers later, a new SN co=
mpiler for PS2, and GCC still getting better and better...

  so, after hearing a workmate claim that he was using a C++ math librar=
y "because it was faster" i decided to update my old C++ math library an=
d make myself a profiling testbed. 
  The sad news is: my old and horrible to read and work with function ba=
sed math library still outstrips the C++ math library by about a 5% spee=
d margin, even on trivial stuff.

  I'm not a C++ newb, i do know about constructor return optimisation, o=
perator overloads copy constructors and the like, but as i tend to write=
 code that is more architectural than the low level stuff like math libr=
aries, i wondered what kind of performance difference (and which way) you were seeing. 

  neither math library uses any platform specific optimisations, such as=
 SSE, SIMD, VU. This is pure C++ only.

  I have pasted my C++ math "header" that i was using for profiling if y=
ou want to take a look at my code and maybe point me in a direction of b=
etterly optimised code..

  http://rafb.net/paste/results/P2kY2O59.html