Horde3D

man gcc / man g++:
-ftree-vectorize: enable vectorization
-ftree-vect-loop-version: duplicates the codes for loops which can be vectorised but it's unknown whether the data is aligned or not; this results in a runtime check and appropriate branching
-ftree-vectorizer-verbose=n: n=1 reports each vectorized loop, ...
Depending on your platform this must be combined with -msse -msse2 or -march=...



pentium3 should include -msse. Which options are you comparing? And how did you benchmark them exactly?

My respects fly out to the dear marciano. After having a quick look at engine I found that Horde3D is really too simple and easy to learn ! So there is no need to change the whole structure of engine to optimize it, just some small pieces of code needs to be changed

Thanks a lot dear Codepoet for help. I've performed the benchmarks again and results was similar, perhaps I was wrong with something !

Given these two code samples:

The compiler should be better able to optimise the union approach.

_________________
Tristam MacDonald - [swiftcoding]

The first code looks better and a bit faster :
But how to sync the x,y and z with m128 ? or compiler syncs them [I mean that their values must be same]

a union is a special struct which has (at least) the size of the largest member. All members share the same memory space, so when one writes to one member one can read back the data using another member. So it's always in sync.
But beware of some problems in regard to aliasing: see man gcc, -fstrict-aliasing
In short: Don't use pointers to union members.

Whichever approach you take, there is going to be a lot of register shifting (SSE to FPU and back), but with the unions we let the compiler do it, and that lets it optimise better.

_________________
Tristam MacDonald - [swiftcoding]

Thanks a lot dear Codepoet and swiftcoder. It seems that there is a lot of things that this n00b must learn from pro members of community and use their great experiences

IMHO by using unions there is no need to change the other sections of engine but we can gain a little performance again by performing some changes on them. So what is your opinions ?

First avoid changing the engine structure and implement a way to show that your changes make Horde3D really faster. If you can improve FPS by say consistently 10% that's a good indicator. But if it's only 1% it will be lost in the noise. To show that it's really faster you need to implement a small timer which shows how much time is spent in the optimized section.
Maybe you can even provide timing details for the different tasks in Renderer::render.

Hi, recently I've tested the utmath_rc5 on a PentiumIV 3.4 + 1GB Memory + Geforce7300 and there is some problems with Knight sample. First it shows a fuzzy screen [it think they are particles] then shows the knight for a small time. Anybody knows whats the problem ? [And there isn't any feelable fps boosts on chicago]

There's no predefined macro GCC_VERSION on gcc
Use __GNUC__. See http://www.delorie.com/gnu/docs/gcc/cpp_22.html

Probably some of the calculations are wrong. I'd check the translation and multiplication stuff first.

Do you have a test suite testing to make sure everything is still working? Ideally comparing the implementations with some well choosen and many random inputs.

Thanks a lot for predefined macro __GNUC__ on gcc tip dear Codepoet, now there isn't any problems with MinGW32 too ! Currently I don't have a complete test suite but I've checked the outputs of Vec3f, Vec4f, Quaternion and Matrix4f classes with random inputs and results are too similar.

utMath_rc6 is now available for download. Now it's using unions and ~1.5x faster than utMath_rc5 + a bugfix on Quaternion Class : slerp() and compilers compatibility.

Special thanks to the Codepoet and swiftcoder

Compiles, but produces very strange results in Chicago and Knight.

Can you describe what exactly happens ? I'll have a test on utMath_rc6 again tomorrow.

There is some problems with MSVC2005 too :I've tested the code with MinGW 4.3 alpha and there isn't any errors

Any body knows how to fix them ?

http://server2.noeding.net/tmp/chicago.png
http://server2.noeding.net/tmp/knight.png

Some of the math is still wrong.