Horde3D

I've created a handy wrapper to use SSE instruction set to optimize the Horde3D engine and games very easy ! I will add some SSE2, SSE3 and multithreading features to the NOS PACK.

So I decided to first optimize the "utMath.h" because it's used in most of Horde3D code pieces. Currently more than 90% of utMath has been optimized. Hoping that this amends a bit of my duty to the Horde3D's admirable community !

Very interesting! I'm going to have a much closer look at this when I get home from work.

At first glance (without testing) I fear that all of these for loops might cancel out the performance gains from using SSE:Maybe we could eliminate all this extra copying by having the vector/matrix class store SSE types internally? Something like this:

Anyway, I'll try this out later and let you know how it goes

Good idea! I'll remove those for loops. Thanks for having a look at code

Edit : I've removed for loops in utMath beta2
Edit : I've removed for loops in NOSPACK beta2

Excuse me about my n00b programming style and making the code too complex

I've just started looking at the code on my home PC, but I realized that the alignment syntax doesn't work on MSVC, so I've made a macro that should be portable:So instead of writing this:We can write this:...and it will work on both GCC and MSVC

Thank you very much dear DarkAngel for compatibility tip.
I've installed the MSVC2005 and your patch solved the compatiblity problems with MSVC. But I prefer to use Code::Blocks + MinGW 3.4.5 compiler.

When I'm compiling the project using MinGW I'm getting the "Unrecognised compiler" error while the GCC and MinGW compilers are too similar.I think changing your patch to this will solve the problem with MSVC and other GCC like compilers such as MinGW in my case :



These changes are available at NOSPACK beta3

Is there anybody to test the new utMath.h + NOSPACK ? I want to be notified if there is any problems and solve them.

I can't run the Horde3D engine , because I have not the required hardware. I'm using PIII750 + Radeon7000

Could you redesign it a bit. I guess using C functions instead of member functions would be better. You have to rename the functions so that they don't clash with the system internal functions. That would avoid the construction of a NOSPACK object in every method. It's currently also a problem that the functions are not exported from the DLL. This way the Horde3DUtils and the applications using the Matrix class can't be compiled anymore.

Hey Siavash, basically I like what you are doing and it looks promising. But I suspect that the way it is currently realized, it is probably slower than before. You need a plenty of support code to get your SEE instruction started for simple operations like vector multiplication or addition. I had a quick look and saw much data copying happening. I think in general you will only profit from SIMD instructions for a more "complex" problem like matrix multiplication.
But my practical experience with SSE is quite limited, all I did was one hand-coded assembler SSE matrix mult function. Your code needs to be tested to see how it behaves in practice. Since you can't run the engine, I think it would make sense to write a small synthetic benchmark that does some vector math and measures the time with and without vectorization/optimization. I think this extra benchmark would even make sense if you could run the engine

http://nebuladevice.svn.sourceforge.net ... c/mathlib/
http://softwarecommunity.intel.com/arti ... g/2494.htm
dunno if they are related or helpful

I never said that I'm going to leave optimizations like this and these are some beta versions so I will profile the code after finding all of the problems.Currently my big problem is that these two new files [utMath, NOS PACK] has been created in a 3 hardworking days and I've never tested the code since those 3 days. Recently I've tested the code on a Sempron3600+ Geforce6200 and results were too confusing, after waiting for ~3mins nothing apears on the screen [excuse me team]. And I don't know where is the problem, my mathematic calculations or function conflicts with system ?

I'm going to redesign the NOS PACK and finding a way to reduce that data copying between arrays but any ideas and tips or learning resources are welcome

Thanks for your respect !

I want to change the NOS usage structure to something like this. IMO this avoids the array copyings and makes the code more secure and reduces the runtime errors because of wrong management of arrays and the final code will be to easier than before to read.



Any body have any idea ?

Perhaps using an anonymous union, like this?

_________________
Tristam MacDonald - [swiftcoding]

Would that work? Inside the CPU, the m128 would be stored in a 128 bit SSE register while the float's would be stored in 3 80-bit FPU registers.
I'm not sure if the compiler would be clever enough to retrieve the right values if you quickly accessed the float's after modifying the m128.
I guess there's one way to find out

I don't know how much you guys are familiar with SSE programming but we can't use m128, m128d and m128i types like normal int or float types and you must load an array of float, double and ... to them.Their usage is something like this :

BTW, the new releases will be available at next 2 weeks or a bit later after some redesigning and code profilings [Don't worry I'll do my best to release them as soon as possible ]

It should be clever enough, but the union may force some odd register usage.

Once someone has a working SSE vector class, it would be interesting to benchmark it against the original vector class, with GCC 4 and 'auto-vectorise' enabled - I think that GCC should be able to fully vectorise the class, but I might be wrong.

_________________
Tristam MacDonald - [swiftcoding]