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]


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.


October 12, 2008

Game Profiling 102

Filed under: game programming, profiling — Tags: , — systematicgaming @ 1:41 am

In the last article we implemented a simple stopwatch, but didn’t really do much with our timing data other than print it out.  Simply printing out our timing isn’t very helpful either, first of all you can’t always see standard output on a console, and secondly it’s a pretty awkward way to collect our data, we can do much better.

Our goal this time is to design a system that allows us to profile out entire game and display the results in realtime.   We’re not going for detailed performance data, just a high level picture of our game’s performance.  The key goals are:

  • Collect data from each major subsystem
  • Present our profiling data to the user in an understandable format
  • Keep a multi-frame history of our data to detect performance spikes


September 30, 2008

Game Profiling 101

Filed under: game programming, profiling — Tags: , — systematicgaming @ 8:21 am

On this blog I keep mentioning efficiency, resource usage and optimization as key requirement for any well designed game system.  When discussing memory I put a large emphasis on tracking and profiling memory usage.

This time we’ll look at the various ways we can profile our game. We’ll also look at how to instrument our game for custom profiling, focusing on CPU usage.


Blog at