Xbox Support

Jan 5, 2008 at 3:26 PM
Are there any plans for future Xbox support? If so, is there a timeframe? I am evaluating physics solutions for a project, and JigLibX definitely seems to be a good candidate for a pure-managed physics engine. However, I noticed the released code does not build for Xbox without modification.
Coordinator
Jan 5, 2008 at 5:35 PM
Hi, i dont have an XBox, but someone wrote me a mail saying that JigLib runs fine on the xbox with some modifications. I asked him to send me the source code but didn't get an reply yet.
Jan 5, 2008 at 6:03 PM
It seems like the engine should work just fine on Xbox360, just the controls are different. The engine doesn't use and hard core rendering tools like render targets that behave slightly differently on Xbox360 than on a PC, so it should be pretty easy to get running on an Xbox360. Just have to foot the $100 fee to Microsoft ;)
Jan 5, 2008 at 6:37 PM
Thanks for the response. This is a great project and I hope to see you continue with it!

I was able to get it to build on Xbox. My main concern was with performance. On most of the sample scenes, the frame rate is around 5-7 FPS until everything freezes. Are there any plans for multi-threading any of the solvers?

The only two changes for Xbox are putting all mouse handling code within conditional compilation directives (#if XBOX ... #endif) and initializing all Vector3 data types. For example, in Box.cs, the method:

        public Vector3 GetHalfSideLengths()
        {
            Vector3 result;
            result.X = sideLengths.X * 0.5f;
            result.Y = sideLengths.Y * 0.5f;
            result.Z = sideLengths.Z * 0.5f;
 
            return result;   // Error Here.  Cannot return uninitialized type.
        }

must be changed to:

        public Vector3 GetHalfSideLengths()
        {
            Vector3 result = new Vector3();    // Initialize Vector3
            result.X = sideLengths.X * 0.5f;
            result.Y = sideLengths.Y * 0.5f;
            result.Z = sideLengths.Z * 0.5f;
 
            return result;
        }

The controls are fine as long as you dont need the mouse. You can use a USB keyboard on the Xbox. Some gamepad controls would be a nice addition though.

Coordinator
Jan 11, 2008 at 1:43 PM
I uploaded an XBox360 Version to the alpha release.
Thanks to Ben who converted the project.
Jan 14, 2008 at 4:15 PM
Thanks for making this port of jiblib. The reason for the xbox 360 performance issues can be many, but note that the 360 has a RISC cpu so that certain constructs does not perform as well (or quite horrible) as compared to an intel/amd cpu. Operator overloading is one of those, and by looking at the code it is performed quite frequently.

I know this is just an alpha port, but the performance is an order of magnitude slower than the c++ version. Take the test where it builds a "pyramid" of boxes. The C++ version can handle about 128 boxes at the bottom line, vs about 10-12 on the manged version before performance suffers.

I went through the code and looked and timed where time is spent, and the worst offender were HandleAllConstraints (with force inelastic it performs about 30% slower).

I will try to spend some time to see if I can find some low hanging fruit to optimize. One thing inside that method which can be fixed is;

MaterialPairProperties prop = collisionsi.MatPairProperties;
prop.Restitution = 0.0f;
collisionsi.MatPairProperties = prop;

change to

collisionsi.MatPairProperties.Restitution = 0.0f;

It saves allocation of one pointer.

Changing this code to use multiple cores should not be that hard (I'll look into using my second cpu core for jiglib later and adding proper multithreaded code), but I would not spend time on solving this as it will not give much performance increase. There are some manged code issues which needs to be solved first.

Good job though. The simulation seems fairly stable.

Thanks for all the hard work!


Coordinator
Jan 14, 2008 at 7:41 PM
Thank you for your feedback. You are absolutely right, it's time to make things faster. (Find slow code like in your example (thanks for this one!) or use unsafe methods)

The goal was to port everything over and than let the xna community find the bugs and optimize code parts (Since I don't have that much time)...

Are you interested in joining the team? I would just add you to the member list so you are able to change source whenever you find something.

Coordinator
Jan 15, 2008 at 1:35 PM
Another thing which should be mentioned:
The Xna version is running with 12 contact iterations and 4 collision iterations. the demos of jiglib only run with 3 contact and 1 collision iteration but with the solver accumulated instead of normal. The accumulated solver doesn't work very well at the moment so i used the normal solver and increased the number of contact and collision iterations to make it more stable. 16/4 Iterations = 4:1
Jan 15, 2008 at 2:53 PM
My problem is that I do not remember much about physics / math anymore. And my education did not extend to include solvers and so forth. I do however know quite a bit about the .net framework. I has also been a while since I looked at the XNA framework, and I am please to see that we can use unsafe code if needed (unsafe code also works on the 360).

My challenge with optimizing the code is that I do not have enough knowledge to correct algorithms; I can only correct the implementations of them.

Jan 17, 2008 at 3:15 AM
Edited Jan 17, 2008 at 3:17 AM

twospoons wrote:

The reason for the xbox 360 performance issues can be many, but note that the 360 has a RISC cpu so that certain constructs does not perform as well (or quite horrible) as compared to an intel/amd cpu. Operator overloading is one of those, and by looking at the code it is performed quite frequently.


Language constructs like operator overloading do not directly affect performance on a specific processor, it is the compiler (in this case, the CLR) that either produces good machine code or poor machine code for these language constructs. In the case of operator overloading, the Compact Framework CLR on the Xbox is extrememly poor at inlining and optimizing overloads, which is why is appears that operator overloading is a slow construct. It really has nothing to do with the construct, just the poor code generation.

The Xbox CPU is a PowerPC RISC processor, but this only matters to the code generator in the compiler. Specifically, the in-order execution of the Xbox CPU makes compiler instruction scheduling more important than for Intel/AMD hardware. Virtual calls in particular are painfully slow on Xbox, along with general floating-point math (which is truly unfortunate for a project like a physics simulator).

Unfortunately, the main roadblock to Xbox performance is the CLR, which is outside of end user control. There are certainly ways to optimize the C#/IL like manual inlining (the Xbox CLR is horrible at inlining) but at the end of the day, you'll see around an order of magnitude performance difference between C# code execution on Xbox and Windows. I really hope the XNA team improves on this. Don't forget that the Xbox CLR is not optimized specifically for the Xbox hardware, while the Desktop CLR is specifically optimized for Intel/AMD hardware.

I'm well aware of the general performance issues of the Xbox CLR, I'm just curious what your team's plans were for improving on the JigLibX code to maximize the Xbox performance.
Jan 18, 2008 at 7:58 PM
Edited Jan 18, 2008 at 8:29 PM


shawmishrak wrote:

Language constructs like operator overloading do not directly affect performance on a specific processor, it is the compiler (in this case, the CLR) that either produces good machine code or poor machine code for these language constructs. In the case of operator overloading, the Compact Framework CLR on the Xbox is extrememly poor at inlining and optimizing overloads, which is why is appears that operator overloading is a slow construct. It really has nothing to do with the construct, just the poor code generation.



This is just semantics.

A is slow because B is slow even though C is fast.

Assuming A is your MSIL and B is the poorly optimized jitted MSIL and C is the CPU.

Since you cannot change B you should avoid doing A.

Jan 18, 2008 at 9:01 PM
Granted. The point I was trying to make was that you need to look at the root cause of why a certain piece of code performs poorly. If you blindly replace an operator overload with a method call, you're not going to help yourself because the method call will suffer the same issues as the overload: lack of inlining and pass-by-value (bad for large data types).
Jan 18, 2008 at 9:43 PM
Edited Jan 18, 2008 at 10:06 PM
Most parameters which are passed around in managed code are reference types, so it is slower to pass those by ref unless you need to change what the reference type actually points to.

Passing value types by ref can give somewhat of a performance boost (depending on how the refereced value type is used inside the method).

Look at this code:

private int NoRef(int a)
{
a += 43;
return a;
}

private int NoRefVer2(int a)
{
int b = a;
b += 43;
return b;
}

private int Ref(ref int a)
{
a += 43;
return a;
}

private int RefVer2(ref int a)
{
int b = a;
b += 43;
return b;
}

Take a guess which ones perform the best?

Jan 18, 2008 at 10:17 PM
Correct, I am referring to value types, such as structs. It's a moot point for reference types and tiny data types like ints. Reference passing can even hurt performance with ints, bools, etc.. However, passing around large value types like XNA Matrix types by value can be insanely slow. All I'm saying is that's why operator overloading on larger value types is slow, especially on Xbox. All the extra copying adds up. This also occurs with value-type properties. Accessing Matrix types through properties incurs a significant memory copying overhead (again, more substantially on Xbox) that can add up if used often enough in tight loops.