I'm working on a little side project for my big project (an RTS in managed code, just for fun, nothing serious) and have been benchmarking several early approaches to the math problem.

Managed DirectX contains classes for matrix, quaternions, vectors, etc and uses d3dx internally to get things done. Since I want my project to run on several target platforms, but still maintain the best possible performance, I've been benchmarking both .NET math code and managed directx' own implementations. Here I get some odd benchmark results...

My question, seeing these results is the following: Am I doing something wrong with the MDX calls, since a simple implementation in .net code seems to be 'just as fast' as the MDX implementation... I expected the .net code to be quite a bit slower than the native implamantations...

oisyn
—
2006-06-27T10:51:49Z —
#2

lousy cross-forum-poster

Nick
—
2006-06-27T11:13:06Z —
#3

The 'unsafe' code is just a C++ routine that looks exactly like your C# implementation. The only difference is that the former is already compiled and the latter is compiled at run-time (JIT). But they should produce exactly the same code. It doesn't use arrays and such so there's no overhead from safety checks either.

In other words, C# can perform equivalent to C++ in many cases. It does have its limitations but if you're aware of them then you can get really good performance. It doesn't have inline assembly or intrinics support though, so you can't access the blazing fast MMX/SSE instructions. But that's not a big problem for the average project, and you can still write an external C++ function...

The 'unsafe' code is just a C++ routine that looks exactly like your C# implementation.

In essence, yes, but I believe the d3dx matrix mul uses SSE code. And somehow I don't think the jitter actually produces SSE code from that piece of C#.

roel
—
2006-06-27T11:47:49Z —
#6

What is the resolution of your timer? And maybe you can compare the resulting (both JIT generated and C++ compiler generated) asm code to be sure that they are identical. VS2005 allows you to switch to asm view when you are debugging C# code, if I'm correct.

What is the resolution of your timer? And maybe you can compare the resulting (both JIT generated and C++ compiler generated) asm code to be sure that they are identical. VS2005 allows you to switch to asm view when you are debugging C# code, if I'm correct.

The resolution of my timer is the standard windows (16ms?) resolution. I know it's not very accurate for this kind of measurements, but increasing the number of iterations sort of solves that problem.

If I do that, the numbers don't really change. On some hardware (AMD) the .net implementation is even slightly faster than the MDX calls. On intel hardware, MDX seems to be a bit faster, but not much (about 1 to 2 percent).

Comparing the generated asm is not something I have the time for at the moment. However, if people are interested in playing with this, I can post my little benchmark app's source...

Edit: OK, so I checked and this is the assembly view for the .net implementation:

In essence, yes, but I believe the d3dx matrix mul uses SSE code. And somehow I don't think the jitter actually produces SSE code from that piece of C#.

I verified that it doesn't use SSE. So the code being produced for the C# version is practically equivalent to D3DX for C++. :mellow:

oisyn
—
2006-06-29T08:54:58Z —
#10

Hmm, that just plain sucks. I recon they'd optimized the d3dx library. Are you sure you're not looking at the debug version?

On the other hand, you should be able to target every reasonable x86 platform with that library, including the pre-XP athlons that don't have SSE support yet. So maybe it's no surprise after all.

Then again, what serious gamedeveloper is using the d3dx math functions anyway?

Qlone
—
2006-06-29T09:20:00Z —
#11

Its performance slightly disappointed me too. It's very tempting to try to do all math stuff in .NET code now, knowing (assuming) it will be as fast or nearly as fast as D3DX' functions, which should be fast enough for what I'm trying to do.

The only real advantage using d3dx has now is that it's a pre-built and (hopefully) debugged math library, which makes for a nice quick start on that front. Since platform independence is a target for my project, eventually I'll need a platform independent math solution anyway...