Hi,

I've been having speed issues running my physics code on the 360, on PC it works just fine. I ended up disabling everything and finding just adding a few Vector2s will bring the console to a halt. for example...

 

                    Vector2 a = new Vector2(0, 0);
                    Vector2 b = new Vector2(1,1);
                    for(int i=0; i<200; i++)

                            a += b;

 Any ideas on this?

 

 

There are two main reasons this code executes slowly:

1. The Xbox CLR is downright horrible with floating-point code.  Expect an order of magnitude difference between PC and Xbox when working with C#.
2. Overloaded operators incur significant overhead on the Xbox CLR (and on the Desktop CLR to an extent).  Where a good C++ compiler will have no trouble inlining that operator, the Xbox JIT'er will make that a function call to the Vector2::op_Addition method, which causes not only a subroutine call but copies to be made of both operands.  The result is calculated in the method and a copy of the result is returned from the method.  This copy is then copied to your 'a' variable.  Notice the frequent copying, just to add two vectors. :)

My advice would be to manually inline the operator.  It's very easy and clean in this case, just "a.x = a.x + b.x; a.y = a.y + b.y".  This will eliminate point 2 above, and just leave you with point 1.

200 seems to be too few to cause a real problem, unless you do it each frame for each of 100 objects.

However, yes, the Xbox CLR JIT is really poor at generating code for operator overloads, and is also pretty poor at floating point code, and it is also poor at passing structs as arguments or return values.

While reading GDC 2008 "Understanding XNA Framework Performance" slides I found that methods and operators perform identically (when not using references), like the example below:

// Both perform identically
Position = Vector3.Add(Position, Velocity);
Position += Velocity;

Does it only applies to Windows?

Bruno Evangelista:

Does it only applies to Windows?

No, it applies on Xbox as well.




As you can see, both result in a static method call. While the Desktop CLR may decide to inline that (probably not), the Xbox CLR will not.

To see why these static non-reference methods can lead to poor performance, look at the difference between memory operations between the method call and the manually inlined version:

• Position += Velocity
  • Copy Position to temporary variable.
  • Copy Velocity to temporary variable.
  • Call Vector3::op_Addition
    • Create new Vector3 instance
    • Add two parameters and place result in new Vector3 instance
    • Copy the new Vector3 instance into a temporary return variable
  • Copy returned temporary variable into Position.
• Manually inlined
  • Add Position.X and Velocity.X and place in Position.X
  • Repeat for Y and Z

You can see where the big win here is.  Now is Position and Velocity are properties, add four more memory copies to both.

Interesting, looking at your "code diagram" a not inlined code looks really bad, more than I thought.

ShawMishrak:

You can see where the big win here is.  Now is Position and Velocity are properties, add four more memory copies to both.

And this looks even worse.  Why it can't inline simple things like "get { return field; }".. =(

It would be great if someone create a "math code inline tool" that gets your code and outputs it with all the math inlined! =D

To put this in perspective, take the following code:





The Func() method does a simple matrix-multiply using properties and operators. Now look at the generated x86 assembly (this is from the Desktop CLR with optimizations enabled [mode JitOptimizations 1 in CorDbg]):




Look at all of that copying going on!  Granted, the memory copying is fairly optimized in the getters/setters on the Desktop CLR using the rep instruction prefix, but it's still unnecessary copying.

Bruno Evangelista:

It would be great if someone create a "math code inline tool" that gets your code and outputs it with all the math inlined! =D

It's called a macro processor, commonly found in C++. :)

You can use #define() macro's in C#, and run the code through the C++ macro processor as a pre-build step.

I found the relevant GameFest 2007 slide.  It is slide 26 of the Costs of Managed Code presentation.

"inliner does not inline methods with value-type parameters."

Whether "parameters" include return values, I'm not sure.  But remember that value-type setters have an implicit value-type parameter.

I think another problem is that the JIT doesn't pass arguments in registers. On the x86, that's not so bad, because it is largely stack based anyway, but on the PPC, that really hurts performance a lot because it's register based (and the first 8 function arguments are supposed to go in registers AFAICR).

First, just a simple question. =)

ShawMishrak:

 [0022] call        dword ptr ds:[00D90F74h]

DS is data segment? And call is calling a method on data segment position [00D90F74h]?

 

ShawMishrak:

It's called a macro processor, commonly found in C++. :)

You can use #define() macro's in C#, and run the code through the C++ macro processor as a pre-build step.

But macros on C++ are not "type safe", right? Also, I didn't know C# support macros. I was thinking in a pre-build step that just inlines everything on the math classes. That would be helpful while the CLR does not inline it.