Horde3D

Thanks a lot dear marciano !

I've a little question : Why MSVC 2005 compiled code is slower than MinGW 3.4.5 ? It seems that MinGW/GCC rocks in code optimizations !

MinGW 3.4.5 : optimized utmath_rc3 : ~1s
MSVC 2005 : optimized utmath_rc3 : ~4s

Just to be on the safe side: you compiled in Release mode in VC, right?

Yes, I've compiled the code in release mode + /Ox

Different compiler implement different optimisations - particularly if you are on an older machine (PIII or earlier), GCC may have more effective optimisations. I wouldn't necessarily expect GCC to beat VS2008 for a modern machine though.

_________________
Tristam MacDonald - [swiftcoding]

Compiler optimizations may also depend on the complexity of your test code. If you use Visual Studio's PGO you may get big performance improvements on simple test code, but far less speed improvements on more complex code. At least in a short test with some thousands matrix multiplications and no other code the PGO optimized version was about 100 times faster. In a more complex code it nearly made no difference.

Most of that extra memory copyings has been removed in utMath_rc4 and it's a bit [~1.5x] faster than utMath_rc3.

There is a lot of things that I must to learn about SSE to 100% utilizing my old cpu powers

Depending on this topic in msdn forums MSVC is not good with SSE optimizations.

Hi, I've used unions to remove extra memory loadings in Vec3f class


after benchmarking this piece of code with original utmath in adding two vectors I'm getting this results :
utmath_org : ~200ms
utmath_sse : ~500ms

So I decided change this piece of code too


after benchmarking this piece of code with original utmath in adding two vectors I'm getting this results :
first code : ~550ms
second code : ~650ms

Anybody knows how to eliminate that SSE_ALIGNED( float out1[4] ) to make the code a bit faster?

After having a look at fvec.h I decided to eliminate that output arrays by this way :

and here is the benchmark result on :

utmath_org : 190ms
utmath_rc4 : 591ms
utmath_rc4 : 731ms [using unions]
utmath_rc4 : 1012ms [using unions + extractm128]

But it seems that using unions is too much slower than utmath_rc4, it's going to make me mad

That shouldn't help at all, and may hurt a lot. You are forcing the compiler to generate code that saves the SSE register to memory, loads it back into 3 regular registers, and then writes it out again. Why do you need to extract it at all for this sort of operation? Just initialise the new vector directly with the SSE value.

_________________
Tristam MacDonald - [swiftcoding]

I'm glad/sorry to tell you that I was a bit wrong with benchmarks. I've tested the code with MSVC too and results was too shocking ! 0s for utmath_org, so I thought that both of MSVC and MinGW/GCC are cheating with normal FPU code because of predefined values and I decided to use random values to avoid the related optimizations
I've changed the benchmark code to this :

Welcome to the desert of the truth :
Compiled with MinGW 3.4.5 @ PIII 750MHz + 256MB RAM + WinXP Pro SP2

utmath_org : ~490ms
utmath_rc4 : ~410ms [using unions]
utmath_rc4 : ~370ms [using DIVPS]
utmath_rc4 : ~330ms [using MULPS and RCPPS instead of DIVPS]

Hmmmm....Yummy ! Atleast 30% performance boost ! IMHO it's better to fully forget about unions because the original utmath_rc4 is fastest on memory loadings [and 2x faster than utmath_rc3].
About using MULPS and RCPPS instead of DIVPS I must to say that results are not too accurate [the max diff is about ~0.01].

I'll put a detailed log of performance boosts a few days later here, wait for your fastest experience with engine
BTW, Blue pill or Red pill ?

Here is some useful links for code optimizing enthusiasts

http://www.agner.org/optimize/
http://gruntthepeon.free.fr/ssemath/

Finally the fastest SSE optimized utMath fully compatible with current structure of engine has been released, utMath_rc5 !
Most of unused memory loadings has been reduced and replaced by SHUFPS and depending on my benchmarks with utMath_rc5 it's ~10% faster than original utMath.

Now I'm going to redesign the utMath and perform some changes on engine to use m128 variables instead of normal floats used in Vec3f and Matrix4f to fully remove that unnecessary memory loadings to perform everything in cpu cache to fully utilize the real power of SSE.

Anybody wants to help me to perform the related changes on engine [because I'm not too friendly with other sections of engine]

So the necessary changes should be to convert all accesses to x, y or z of a vector to function calls x(), y() and z() - and similarly for the Matrix, where the function calls extract the necessary float from the m128? I have a feeling that you wont get any better performance this way than letting the compiler generate the same code automatically using unions.

_________________
Tristam MacDonald - [swiftcoding]

Yes, I want to do the same thing like this : Accessing the necessary floats from m128 unions by using getX(),getY(),getZ() from Vec3f and getCol()/getRow or overloading [] operator in Matrix4f.And changing the current structure of engine to :Instead of :
Can you describe your opinion a bit more, it's too interesting

I've upgraded my compiler from MinGW/GCC 3.4.5 to MinGW/GCC 4.3 alpha. By using which flag compiler enables the auto-vectorize feature? Currently I'm using -fexpensive-optimizations flag.
Why PIII optimized code [-march=pentium3] is slower than using -msse ?