I've been having 360 performance issues and I'm thinking most of the work is related to CPU. After seeing "Understanding XNA Framework Performance" I saw a little recommendation people don't seem to mention much, multithreading. The problem is, a lot of my game relies on sequential data. I'm sort of new to the idea of multithreading so pardon me if this sounds stupid, but would it maybe be possible to split certain updates to different threads. For example, right now I update all my characters collision one at a time; Could I perhaps update one character on one thread, another character on another and so on until I run out of threads then start over on the original thread and continue the main thread when all the characters have been updated?

It seems pretty logical to me, but I'm suspecting there could be a problem in my theory....

Have you profiled before you head down this route? Perhaps you are generating garbage, perhaps you are stalling the graphics pipeline - there are many things you could be doing that cause your performance issues.

I'm at the point I'm doubting garbage is that much of a problem. I have keys that cut off Rendering, Collision detection, etc... and the areas causing problems all seem to be cpu related. I'm not sure what you mean by stalling the graphics pipeline but seeing as I've turned rendering off and things still moved slow I'm guessing that i'm not.

Anti:

Could I perhaps update one character on one thread, another character on another and so on until I run out of threads then start over on the original thread and continue the main thread when all the characters have been updated?

In short, yes. Multithreading can really increase the effeciency of updates but you need to be pretty careful when you are doing multithreading since you can cause the program to crash if you are changing values with one core while trying to read the same values from another core. Basically if you decide to go that route you need to ensure that each thread can run independently of all the others. There are some good resources online that explain how to do it correctly, I will see if I can find my bookmark to one later tonight.

Good to know! I'll start looking into it.
Much obliged!

Anti:

I've been having 360 performance issues and I'm thinking most of the work is related to CPU. After seeing "Understanding XNA Framework Performance" I saw a little recommendation people don't seem to mention much, multithreading. The problem is, a lot of my game relies on sequential data. I'm sort of new to the idea of multithreading so pardon me if this sounds stupid, but would it maybe be possible to split certain updates to different threads. For example, right now I update all my characters collision one at a time; Could I perhaps update one character on one thread, another character on another and so on until I run out of threads then start over on the original thread and continue the main thread when all the characters have been updated?

It seems pretty logical to me, but I'm suspecting there could be a problem in my theory....

Things that are a good fit for multithreading would be things that don't require much interaction with the rest of your game's data/logic.  That is, things that are self-contained.  If your character collisions tests use data that is changing at the same time (say collisions with other characters, and those characters positions are being changed), then it might not be a good fit.

There's something you can try now though, to see if that is really your problem. If you artifically limit the number of character collision tests, does your frame rate improve?

mtnPhil:

Things that are a good fit for multithreading would be things that don't require much interaction with the rest of your game's data/logic.  That is, things that are self-contained.  If your character collisions tests use data that is changing at the same time (say collisions with other characters, and those characters positions are being changed), then it might not be a good fit.

There's something you can try now though, to see if that is really your problem. If you artifically limit the number of character collision tests, does your frame rate improve?

There are two things really getting in the way.

I update the animation of each vertex indepedently which I now know I should use the gpu to do somehow but I really don't want to right now.
The collision slowing me down is only level collision.

I turned off both and instantly boosted up 60fps. None of the collision detection or the animation updates rely on other characters so I think it should fit well!

I haven't tried specifically limiting collisions for some characters but, even though it could relate to multiple problems, removing characters does speed the game up.

Then it sounds like it might be a good fit.  But before resorting to multithreading and all the headaches that may ensue (it is not easy to get right!), make sure you've profiled your collision code to identify any performance bottlenecks that could be fixed without having to multithread.

I agree with Phil. I think that making sure you've optimized the existing code as best you can before resorting to multithreading is a good idea. Sometimes is can be as simple as exiting a few loops early after a varaible meets certain criteria. If you are doing enough checks with the same loop even little things can help.

Multi-threading is possible, but it may or may not make your code faster. You may find that you need to synchronize for as much time as your code was taking to run in one thread.

If you suspect your slowdown is CPU related it is likely worth your while to run a profiler on a Windows version of your game if at all possible. This will help you pinpoint the areas of your code that are taking the most CPU to run, giving you a place to start optimizing.

You guys may be right. For some reason I pictured multithreading to work a lot better in my head it seems passing large functions are what its made for. I got a load of slowdown from a quick and dirt attempt at it which was probably my error but was enough to tell me its not a going to be a picnic to do. It still bothers me theres an extra core lying around just doing nothing.

I'll start looking for some other solutions but I have to ask, are windows processors generally better than the 360 processor? What's the general excuse why JigLibX runs slower on Xbox 360? I'm running a Intel Pentium D 3.19ghz processor and if that for some reason is a fair deal faster, I can face facts and try optimizing code. I'd just like to know if I'm trying to optimize code in general or am I looking for things the 360 cannot handle properly.

Floating point calculations will be a lot slower on the Xbox, due to the assembly that the .NET compact framework's JIT outputs (not necessarily due to the processor).

So it's true that profiling your code on Windows won't give you an exact picture of what's slow on on the Xbox.  Hopefully it will be close enough though, and any improvements you can make on the Windows side will also result in improvements on the Xbox.  Unfortunately there isn't any way for us to profile code on the Xbox.

I have a ton of those... that's quite unfortunate. I believe that may be what I'm truly dealing with which helps a lot towards finding a solution.
I'll update this post as soon as I get things running smoothly and see if that's indeed the case.

I should probably change the title....

Okay it seems several things were slowing me down...

A. Running in Debug Mode
B. Collision Code needed tuning (I'm really not sure how much its helped though)
C. Garbage Collection in Animation
D. Constantly redrawing level using a vertex cache instead of storing data (I.E wasting CPU)
This was only evident on the unnoticeably larger scenes so it was fairly easy to miss.

A and D seem to be the main culprits. I was thinking there would be some sort of big magical solution... ah well
Everything runs at about 52fps now (up from about 25) so there's still some things I have to look into.

I'm still not exactly sure why sorting the data into the cache caused that much of a ruckus. All it does is sort, and copy data to arrays.
It all feels a little open ended but I'm satisfied for the most part.

Thanks for the help!