Systematic Gaming

January 13, 2009

Performance: C# vs C++ – Part 2

Filed under: c++ vs c#, optimization, profiling — Tags: , , — systematicgaming @ 1:01 pm

I was pretty content with my previous tests on C# sorting performance, which were pretty disappointing.  Normally I’d be happy to move on, but one commenter did pique my curiosity pointing to a MSDN article about how lousy the 2.0 CLR is with structs.  So I downloaded the Visual Studio 2008 Express Edition to give it a try.  I admit, I was a bit surprised and impressed with the differences.


January 4, 2009

Performance: C# vs C++ – Revisted

Filed under: c++ vs c#, optimization, profiling — Tags: , , — systematicgaming @ 2:18 am

I thought I’d comment on my own post about C# vs C++ performance.  The purpose of the test was to compare the time to sort 128-byte objects in C++ vs C#, nothing more.  Again if you understood that, then you can propbably see that the performance measured has more to do with execution envrionments than languange differences.

That said, I’d like to address out the following issues in my testing:

  1. I used a char array in C# to simulate a similar char array in C++.  This incorrect since C# chars are 16 bits while C++ they are only 8 bits.  I admit this was pretty sloppy.  Replacing char with byte fixes this, and the result is the C# version runs about 15% faster.  Faster, yes, but still not fast enough to make a significant difference.  The most striking thing is that halving the memory usage only gives a 15% difference, in C++ the memory had direct linear impact on runtime.
  2. Some people complained about using the fixed keyword to make the array part of the Data struct.  It’s trivial to replace it with a number of int or float to create a 128-byte struct and makes no difference in performance.  The point was to approximate C++ and to represent a larger class, fixed was a simple way to do this.
  3. Some people complained this isn’t an apple to apple comparison – I disagree.  It’s about as direct a way as possible of comparing two very different languages and operating environments – perform the same task and see how long it takes.
  4. I was running Visual Studio 2005 SP1 for both tests, newer/different versions may have varying results.

The purpose of the previous post isn’t to claim that C++ is better than C#, but many people seem to think that I am – I suppose this is what I get for posting such an inflammatory title. I use C# on a daily basis and like it.

There were a number of comments on my last post claiming to “debunk” my tests referring to what is  posted here.  This debunking itself admits it’s comparing apples to oranges – however it completely misses the point of creating a fixed size array in the first place.   Replacing the fixed array with a heap pointer shows nothing about C# performance – only that copying a smaller struct is faster than copying a larger one.  This is a fact I addressed previously.

The claim is made that this test isn’t representative of what a C# programmer would write.  True, a C# programmer would very rarely used a struct with a fixed array.  However, it’s fairly easy to create objects with 128-bytes or more of data.  That’s 32 4-bytes variables, which isn’t a huge amount of variables to have in a class, especially one with a few parent classes each with a few member variables.

Anyways, other that the char/byte mistake, I stand by the original results – C# takes about 10 times longer to sort an array on my computer, compared to a similar C++ verision.

January 3, 2009

Performance: C# vs C++

Filed under: c++ vs c#, optimization, profiling — Tags: , , — systematicgaming @ 6:02 am

In my last post I discussed cache pressure and how important the cache is for performance.  Out of mild curiosity and a bit of boredom, I decided to see how the same code (or near enough) performed in C#.  Why C#?  A lot of tools are written in C# now, mostly because it’s a nice language with fantastic library support and solid GUI integration.  It’s a more productive environment for all those programs that don’t have to run at 60 fps.

Now given how straightforward the test is – sorting an array – I’d expected performance to not differ by much compared to the C++ version. Before I ran this code I was guessing that C# would be maybe 50% slower and at most half the speed than the C++ version.  Especially since the sorting should be mostly algorithmically and memory bandwidth bound.

You can get both versions of the code here: C++, C# to test for yourself. [EDIT: fixed link to C# code]

Now for the results.

[EDIT: a number of issues were raised about this test in the comments and elsewhere – here’s my response]


December 23, 2008

Patterns in Performance: Cache Pressure

Filed under: game programming, optimization — Tags: , — systematicgaming @ 3:16 am

I’ve been mentioning memory and the cache a lot, because proper cache utilization really is a critical to good performance. This time we’ll look at cache pressure – a term that refers to overworking the memory cache with too many or wasteful memory accesses.  Basically putting pressure on the memory cache means you’re wasting time accessing more memory than you need to.  The main cause is inefficient data access, often by using data structures that are too large, or too sparse reducing any benefit from memory locality.


November 23, 2008

Patterns in Performance – Cache Manipulation

Filed under: optimization — Tags: , — systematicgaming @ 2:37 am

With modern processors greatly outpacing the speed of memory we need to properly utilize the memory cache to achieve high performance.  Whenever we touch a memory address, the memory is pulled into the cache from main memory.  This is a slow operation, taking hundreds of cycles on modern CPUs.

To address this problem we’ll look at another pattern in performance: cache manipulation.  Instead of waiting for the memory controller to fetch memory when at the time we access it, we tell the memory controller to fetch the memory in advance.  By the time we need the memory it has already been put into the cache.

[EDIT: Updated to more correctly show load-wait timings.  Loads cause stalls when the loaded data is first accessed, not when the load instruction is invoked (which is what was previously implied).]


November 7, 2008

Patterns in Performance – Caching

Filed under: optimization — Tags: , — systematicgaming @ 4:20 am

When optimizing code there are a number of techniques than are frequently used – tried and true methods to speed up our code.  These optimization patterns occur again and again.  In this series we’ll look at various patterns in performance than we can apply in numerous situations.

Almost all programming can be viewed as an exercise in caching – Terje Mathisen

The first pattern we’ll look at is caching.  Caching is simply storing the result of calculations for later use.  This is a traditional space-time trade-off, where we use a limited amount of memory to reduce recalculating functions, trading memory of speed.

October 23, 2008

Game Optimization 101

Filed under: game programming, optimization — Tags: , , — systematicgaming @ 6:23 am

In this article we’ll look at the process of optimization.  There’s no single way to optimize a game, but there are optimization methodologies to follow, which will help us prioritize our optimization strategy.

In previous articles we looked at how we can profile parts of our game.  At this point we only know how long sections of our game code are taking.  We haven’t looked into how to use this information to make our game faster.  We need to know how to target the slow parts of our game.

The process of optimization is two parts methodology, one part knowledge and one part intuition.  We’ll start with a simple process and show how it can help us optimize effectively.


Blog at