Horde3D

After some discussions about utMath with Volker, we decided to use C functions to optimize utMath to avoid the runtime problems and make the code more secure. [final optimizations and profilings are on the way]

note : Now there is no need to include NOSPACK in Horde3D engine and now they are two separate things.

I will release the new version of NOSPACK a few days [or hours] later to amend the features such as min/max finding, sqrt, ... that utMath lacks; By using NOSPACK for in game optimizations you can make your life more easier by using SSE [SSE2, SSE3, SSE4.x and multithreading are on the way]

Please don't forget to report me the performance boosts and bugz

utMath_rc2 contains some bug fixes and these two functions has been optimized too : rayAABBIntersection, nearestDistToAABB

The current version crashes because the variables used to store the output variables are not SSE_ALIGNED. After I added the macro to all outputs the application does not crash any more but does not work correctly. I guess there is something wrong somewhere in the calculations. Don't have the time to check it in detail.

I'll take a look in calculations to find the problems [perhaps the problem is bad array managements]

Thanks a lot dear Volker for programming tips and helping me to find bugs and finish the job as soon as possible

Hi, most of bugs and compatibility problems has been fixed.Check out the new utMath_rc3 !

Please don't forget to report me the performance boosts and bugs

Special thanks to the Volker and DarkAngel

Today I've performed some minor optimizations on Matrix4f class : determinant and inverted functions.So I decided to measure the code speed inverted function speed :

MSVC 2005 compiled code :
utMath : 10s
utMath_rc3 : 19s
optimized utMath_rc3 : 26s

MinGW 3.4.5 compiled code :
utMath : 6s
utMath_rc3 : 16s
optimized utMath_rc3 : 23s

[PentiumIII 750 + 256MB memory]

The results are too confusing, utMath_rc3 is 2x slower than original utMath
This is the results of that memory copyings, I must fully change the code structure, anybody have any ideas ?

BTW, MinGW 3.4.5 compiled code is faster than MSVC 2005

I don't have any ideas, but this confirms short tests I had with your versions. Using the Chicago Demo together with software skinning the framerate dropped on my notebook from ~7fps with the original utMath to ~4.5fps with your version.

Thanks for testing the code dear Volker.As marciano said the code will be slower than before because of extra memory copyings.

I/We must fix this problem, but currently I don't have any ideas.I must have some researchs about this problem

http://www.cs.technion.ac.il/~zdevir/main1.html
it uses unions

Thanks dear kal.I'll have a l00k @ kode

There is a composite function in Intel C++ intrinsics : _mm_set_ps(z,y,x,w)
This removes that num1 and num2 arrays and there is no need to load them into __m128 variables using _mm_load_ps(num1) and _mm_load_ps(num2).IMHO this reduces that extra memory copyings and makes the code a bit faster without fully changing the utMath structure.

I must have a deeper lOOk in Intel's SSE manuals and perform some benchmarks again.

Also a great article, although still using inline asm an not intrinsics:

http://www.cortstratton.org/articles/OptimizingForSSE.php

Yes, this is it ! I've benchmarked the original utMath, utMath_rc3 and optimized utMath_rc3 [using _mm_set_ps] : sum of 2x Matrix4x4

utMath : 1s
utMath_rc3 : 4s
optimized utMath_rc3 : 2s [I've just optimized the Matrix4f + operator]

I'm going to remove that extra array copyings

Thank you very much dear marciano for that great article !

I know that inline asm code is a bit faster than intrinsics, but IMHO it's better to use C++ intrinsics because by this way compiler knows what you are going to do and performs the related optimizations on code and compiled code will be faster than inline asm code [I'm not sure but I think there is also some problems in inline asm with non MSVC compilers]

For learning purposes, it could be interesting for you to look at Nebula and Bullet.