XNA Framework

Re: xbox360 performance problems

JasonD — Wed, 03 Dec 2008 02:42:15 GMT

Reality Shift:
You can also look at the Ship Game starter kit which has a particle system where the bulk of the calculations are done on the GPU.

Ok thanks! I've been lenient at looking at that because I don't want to rewrite the particle system I already have in place. :S Maybe for my next game...

Re: xbox360 performance problems

Reality Shift — Tue, 02 Dec 2008 23:07:01 GMT

You can also look at the Ship Game starter kit which has a particle system where the bulk of the calculations are done on the GPU.

Re: xbox360 performance problems

JasonD — Tue, 02 Dec 2008 21:40:16 GMT

Thanks Tennyson! I'll take a look at that right now. :)

Re: xbox360 performance problems

Tennyson — Tue, 02 Dec 2008 21:31:34 GMT

JasonD:
I'd like to know more about the caching limitations of the Xbox 360. You're talking about the potential of a 1,000 cycles lost due to cache misses. That's insane!

This article might answer a few questions:

http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars

Re: xbox360 performance problems

JasonD — Tue, 02 Dec 2008 21:01:19 GMT

jwatte:
Each PowerPC core on the Xbox is less powerful than a desktop or laptop x86 chip. The reason is that the PPC core is in-order, which means that even though it runs at 3.2 GHz, as soon as it gets a cache miss, it has to wait for the miss to fill, which could be a thousand cycles. It cannot do out-of-order execution to speculate ahead, which means it can't magically pre-fetch, nor can it keep running the rest of the instruction stream while waiting for the cache line to fill.

I've just dawned on the fact that the caching issues of the Xbox 360 are a major source of slowdown (at fault of my code which I can fix, but I didn't realize I had to be so careful). I'd like to know more about the caching limitations of the Xbox 360. You're talking about the potential of a 1,000 cycles lost due to cache misses. That's insane!

Re: xbox360 performance problems

StatusUnknown — Tue, 01 Jul 2008 02:01:37 GMT

ShawMishrak:
StatusUnknown:
foreach/for loops will have the exact same generated code for most collection types.
Most properties get inlined...

Are you sure about that? A foreach loop over a collection will compile into an IEnumerator access, while a for loop will use indexers. In a lot of cases, the difference is moot, but the difference is there. My experience is that the Xbox JIT'er will inline just about no property accesses. Besides, an inlined property access will still generate an additional memory copy operation which can add up if you have a lot of them.

StatusUnknown:
With that said, you will get around 1/4 to 1/6 the performance on a 360 logical cpu core to a pc cpu core, so ratio sounds about right.

Keep in mind that most of this difference is a result of the Xbox JIT'er, not the hardware. There are hardware differences that make an Xbox CPU core slower than a desktop CPU core in the general case, but a smart compiler can all but eliminate the difference.

I should have said 'the XNA performance on a 360 logical cpu' :-)

And yes, for the more common collection types, a foreach will be no more expensive than a for loop (Certainly for arrays and generic list's). The compiler is smart enough to know it doesn't need an enumerator. There are exceptions though, such as using ICollection as the collection type.

Re: xbox360 performance problems

jwatte — Mon, 30 Jun 2008 22:57:43 GMT

I started thinking about what kind of knowledge a compiler could build to improve cache efficiency of generated code, but came up mostly blank. I suppose the best it could do would be to issue a prefetch for addresses it knows will be dereferenced as far ahead of the dereference as possible, but too aggressive pre-fetching may turn out to be a performance loss, and often the dereference is indirect and can't be known until it's actually done. The main problem is that, in a language like C++, the data structure layout is fixed and can't be re-arranged by the compiler. I suppose in the CLR JIT you might be able to get incremental gains through re-arranging, but the real gain is had when the user re-defines his/her data structures, which the compiler can't actually do.

Re: xbox360 performance problems

ShawMishrak — Mon, 30 Jun 2008 20:27:30 GMT

jwatte:
There is nothing that a smart compiler can do about the problem that once you miss the cache, the PowerPC core in the Xbox will stall waiting for memory. (Actually, it will switch to the second hyperthread -- that's why hyper-threading makes sense on this implementation)

That's the point. A smart compiler will throw sequential program order out the window and rely on data/control dependencies during code generation. The fact that cache misses guarantee a stall (not just increase the probability) can be coded into the compiler's cost vs. benefit analysis algorithm. As long as the compiler can make reasonable guesses as to the cache size and availability, it can theoretically partition data accesses to maximize cache efficiency. This has a lot to do with compilers.

Re: xbox360 performance problems

jwatte — Mon, 30 Jun 2008 18:20:25 GMT

There is nothing that a smart compiler can do about the problem that once you miss the cache, the PowerPC core in the Xbox will stall waiting for memory. (Actually, it will switch to the second hyperthread -- that's why hyper-threading makes sense on this implementation)

On the PC, even if a given memory access is stalled waiting for memory, instructions after can still be fetched and dispatched, because of the out-of-order architecture. That's what allows PC CPUs to effectively hide a lot of memory latency. That has nothing to do with compilers. For good performance on the Xbox, you should do all you can to make your accesses cache local.

When it comes to foreach vs for, a foreach over a native language array will not go through IEnumerator. Also, that foreach will be more efficient than a for loop, because there will be no index range checking on access. If you're using List<X> then you won't get that benefit, because List<X>[int] will always check the range. Then, you have to trade the overhead of index range checking versus the garbage of the IEnumerator. Even in an unchecked context, List<X>[int] will check for range, because the List class wasn't compiled as unchecked.

Meanwhile, a native array will run the fastest if you use a for loop over indices, inside an unchecked context, because it will then not do range checking. It's up to you to make sure you don't have a bug at that point! In fact, at that point, you might as well use unsafe code with a fixed pointer to the array, to hoist out that final memory dereference per access, in case the GC moved the element. If you're not allocating memory inside the loop, using fixed is not much of a problem. Beware that other threads may allocate memory, and fixing the pointer would make the job of a parallel GC harder when it runs for those threads. I believe that the XBox JIT is dumber than dirt, though, and does stop-and-collect, with lock-out.

Oh, how useful it would be if we could get a tool like VTune for the XBox CLR...

Re: xbox360 performance problems

ShawMishrak — Mon, 30 Jun 2008 03:35:40 GMT

StatusUnknown:
foreach/for loops will have the exact same generated code for most collection types.
Most properties get inlined...

Are you sure about that? A foreach loop over a collection will compile into an IEnumerator access, while a for loop will use indexers. In a lot of cases, the difference is moot, but the difference is there. My experience is that the Xbox JIT'er will inline just about no property accesses. Besides, an inlined property access will still generate an additional memory copy operation which can add up if you have a lot of them.

StatusUnknown:
With that said, you will get around 1/4 to 1/6 the performance on a 360 logical cpu core to a pc cpu core, so ratio sounds about right.

Keep in mind that most of this difference is a result of the Xbox JIT'er, not the hardware. There are hardware differences that make an Xbox CPU core slower than a desktop CPU core in the general case, but a smart compiler can all but eliminate the difference.

Re: xbox360 performance problems

StatusUnknown — Mon, 30 Jun 2008 03:04:50 GMT

zziemke:

We tried various perfomance optimizations:

ref Texture2D

foreach -> forr

replace properties with fields

your optimisations aren't really...

Passing a Texture2D by ref won't help you. Passing by ref will only help with value types, in fact passing a class by ref is most likely less efficient (although you'd never notice it).

foreach/for loops will have the exact same generated code for most collection types.

Most properties get inlined...

With that said, you will get around 1/4 to 1/6 the performance on a 360 logical cpu core to a pc cpu core, so ratio sounds about right. If you are drawing each particle as a single draw call, then 12,000 particles is extremly good.

Re: xbox360 performance problems

JoKie — Sun, 29 Jun 2008 09:28:00 GMT

For those interested in HLSL and particle-systems I found some nice articles:

HLSL Introduction

Particle Tutorial Series

Particle Systems (Catalin Zima - XNA and HLSL blog)

Re: xbox360 performance problems

JoKie — Sun, 29 Jun 2008 09:06:29 GMT

Thank you for the information!

If I understand you right, there's nothing we can do in this case as long as it is limited to the CPU and we should try to port our particle-system to the GPU.

Well, then it looks like I'll have to get into shader-programming! XD

Re: xbox360 performance problems

jwatte — Sat, 28 Jun 2008 23:54:38 GMT

Each PowerPC core on the Xbox is less powerful than a desktop or laptop x86 chip. The reason is that the PPC core is in-order, which means that even though it runs at 3.2 GHz, as soon as it gets a cache miss, it has to wait for the miss to fill, which could be a thousand cycles. It cannot do out-of-order execution to speculate ahead, which means it can't magically pre-fetch, nor can it keep running the rest of the instruction stream while waiting for the cache line to fill.

Second, the compact CLR JIT that is used on the Xbox is not written for high performance. It will not inline even small functions, and it will not generate very good code for floating point math. Thus, the C# implementation will be significantly hampered compared to a C++ implementation of the same code for the Xbox.

Third, most of the Xbox floating point power comes from the vector extensions (AltiVec, with small modifications). Unfortunately, there is no way to get at those extensions at all from C#, and the compact CLR JIT doesn't know how to use them, either.

So, no, there's no way that the Xbox will run the same code as the PC as fast, when it is CPU limited. However, the GPU in the Xbox is very nice, has great fill rate, and can run rings around most PC graphics cards (except for the most expensive ones). Thus, when you are fill rate limited, or perhaps vertex transform limited, you will likely find the Xbox to perform very well.

Re: xbox360 performance problems

JoKie — Sat, 28 Jun 2008 20:56:35 GMT

We aren't using multiple threads yet, but shouldn't it be possible to get it running on 360 at least as fast as on PC without multiple threads?

Our particle-methods:

    
                    public void Update(GameTime gameTime, Vector4 segmentBounds) 
        
                    { 
        
                        if (amount <= 0) 
        
                            SetRandomMove(segmentBounds); 
        
                        amount += (float)gameTime.ElapsedGameTime.TotalSeconds / moveTime; 
        
                        this.localPosition = Vector2.SmoothStep(pointA, pointB, amount); 
        
                        this.Position = new Vector2(segmentBounds.X, segmentBounds.Y) + this.localPosition; 
        
                        this.Scale = Vector2.SmoothStep(new Vector2(ScaleA), new Vector2(ScaleB), amount).X; 
        
                        if (amount >= 1f) 
        
                            amount = 0f; 
        
                    } 
        
                    private void SetRandomMove(Vector4 segmentBounds) 
        
                    { 
        
                        pointA = this.localPosition; 
        
                        pointB = Utilities.GetRandomPosition(GetParticleField(segmentBounds), this.Origin); 
        
                        ScaleA = this.Scale; 
        
                        ScaleB = Utilities.Range(MyPlayer.SnakeAttributes.ParticleMinScale, MyPlayer.SnakeAttributes.ParticleMaxScale); 
        
                        moveTime = baseSpeed + Utilities.Range(-speedVariation, speedVariation); 
        
                    } 
        
                    private Vector4 GetParticleField(Vector4 segmentBounds) 
        
                    { 
        
                        return new Vector4(-((segmentBounds.W * MyPlayer.SnakeAttributes.ParticleMoveRegionMultiplicator - segmentBounds.W) / 2f), 
        
                                           -((segmentBounds.Z * MyPlayer.SnakeAttributes.ParticleMoveRegionMultiplicator - segmentBounds.Z) / 2f),  
        
                                           segmentBounds.W * MyPlayer.SnakeAttributes.ParticleMoveRegionMultiplicator,  
        
                                           segmentBounds.Z * MyPlayer.SnakeAttributes.ParticleMoveRegionMultiplicator); 
        
                    }