On and off during the last month or so, I’ve worked toward finishing a project I wrote about last year. It’s an Amstrad CPC Emulator, written in C# using the Microsoft XNA library. I’ve written plenty about the background and motivation in the previous blog post. This post is just here to announce the finished product, and touch a little on the things I’ve worked on recently.

The picture above is from Hewson’s “Nebulus”. Now that the emulator has a pretty complete feature set; games like these are very playable now. It makes a world of difference having the audio fully working now, for example. It also is great to finally be able to play at the original, full frame rate on Xbox 360. Surprisingly the 360 had trouble emulating this seemingly primitive machine!

Anyway, after the jump is a video showing the emulator in action on the 360…

XNACPC In Action

Here you go! This video shows a number of games running on the emulator. It’s taken with a point-and-shoot camera, in a poorly lit room. So the quality isn’t too great, unfortunately. Some games have pretty washed out colors and bad contrast; some look fine though.

I guess I could have captured it from my PC, but the whole point of the emulator was to get it running on the Xbox 360. The fun part is showing it off on the real thing.

CRTC – Good Timing and Accurate Video

My first pass at XNACPC last year, used the same technique which I employed when I wrote my CPC emulator back in the 90′s. I used a pretty naive approach, that had surprisingly good results for the early crop of launch games for the CPC.

I fudged the interrupts simply so that they occurred at 300Hz, which they’d be at on a real CPC. I wasn’t emulating the HSYNC correctly, nor the counters which are based off the HSYNC and generate interrupts. I also had to fudge the VSYNC signal which is read from one of the PPI ports. Whilst it was a primitive approach, it worked pretty well. Even ‘Sorcery’; a split-screen game, looked and played like the original.

Fixing the CRTC to behave properly was at the top of my list. I was pleased that I managed it. The best reference I found for it was probably here:

• http://www.grimware.org/doku.php/documentations/devices/crtc

Grimware CRTC Timing Reference

So I threw away my old video implementation and did it the proper way. Many games which previously didn’t work, now played just fine. I also used to draw the entire screen at the end of the frame. When I switched to drawing it line-by-line after each HSYNC, it eliminated flickering artifacts in many games. “Monty on the Run” for instance, looked awful in many places when I was updating the whole screen at once.

“Monty On The Run” – Fullscreen vs. Line-by-line

Audio – Silence Isn’t Golden

I actually traded off the audio work with the CRTC work. I’d switch between them when I hit a wall, to keep things interesting. When I first worked on the emulator last year it actually wasn’t possible to implement emulated audio at all. That only became possible when XNA 4.0 was released, with the addition of DynamicSoundEffectInstance.

The audio on a CPC is pretty simple in it’s concept, but it did take me a little while to get the timing correct. It’s essentially based on square waves, where the audio signal is either on or off. The signal does have volume control, so it’s possible to produce pretty decent sounding music with it.

AY8912 Audio Square Waves

There’s three main parts to the AY audio chip used in the CPC:

• Three channels of tone generators. Producing square waves at given independent periods.
• A single noise generator. It generates random noise, which can be used by any combination of channels instead of the tone generator output.
• A single envelope generator. This allows any combination of channels to progressively change the volume over time, in a manner that doesn’t need any CPU assistance.

Of the three channels; two of them represent the left and right speakers, and the other one is mixed between each speaker.

That’s the gist of it. The audio was pretty satisfying to implement; since I’d never tried to get it working, back in the emulator I developed in the 90′s. Unfortunately the addition of the audio was taxing enough for the Xbox to drop under the 50fps that a CPC runs at. This meant I had to refactor the audio code somewhat, from a nice C#-style to a more brute-force C-style.

Z80, PPI and Other Hardware Bugs

There was a fun little period after I had the CRTC emulation all working correctly. With the last big hurdle overcome, I now had to fix bugs in my hardware implementation. This was the period where suddenly lots of other dead non-working games would spring to life.

Coming back to the source code after over a year was fine for the most part, but I did forget about a number of functions which I stubbed out. The PPI was a big one, I just did the basics to get the most primitive games running. So there I had to go back to the hardware documents and fill in the more obscure parts of the implementation. After doing that, a bunch more games would run.

One other key fix I remember was to the Z80 emulation. The HALT instruction was broken. I took the Z80 CPU emulator originally from an older C# Spectrum emulator. I’d made a number of modifications to get it to play nice with the CPC; mostly around timing and interrupts. When I noticed a couple of games dying on the HALT instruction, I went back to the Z80 documentation and implemented HALT correctly. As well as getting some games to run, it also amusingly fixed the broken ‘pelvic thrust’ animation in the intro to ‘Rocky Horror Picture Show’.

“The Rocky Horror Picture Show” – Intro

CRT Shader – A Bit of Polish

Once I finally had the majority of the games looking pretty much perfect, I had an inkling to go a little further. I’m not much of a graphics programmer, by today’s standards. I used to be really into graphics programming back in the mid to late 90′s. Michael Abrash’s “Zen of Graphics Programming” was one of my favorite books. I also remember fondly working through the ‘Asphixia VGA Trainers’. It’s about the last time I think I wrote more than just a handful of lines of assembly code at once.

It’d been a few years since I last experimented with shaders, so I decided to try writing a simple shader to give the emulator a ‘CRT effect’. I only spent a small amount of time on it; it’s nothing fancy. The gist of my effect works as follows:

• Each CPC pixel is exactly three ‘XNA pixels’ high. My shader uses modf() to modolo based on this, so I can do something different for each of the three rows of pixels.
• Row One: I leave the color alone. Sample goes straight through.
• Row Two: 90% of the color I take from original sampled value. 5% I actually sample from the next CPC pixel scanline. Then, 5% left out to make it darker.
• Row Three: 75% of the color I take from original sampled value. 15% I sample from the next scanline. Then, 10% left out to make it darker.

Sampling a little of the next scanline down, introduces a little color bleeding; which seems to work well. It’s pretty decent-looking considering how simple my shader was. Here’s a zoomed picture, below. It looks it’s best though at 1:1 resolution, as you can see from the “Nebulus” shot at the very top of this blog post.

“Ikari Warriors” – 2x Zoomed Shot of my CRT Shader Effect

Xbox 360 – Compact Framework Creaking Under Pressure

Getting the emulator running at the full frame rate of the original CPC, wasn’t much fun. On PC it was fine, no problems there. I think Task Manager shows ~2% CPU usage on my PC when it’s running. When I turned the frame-rate limiting off, I think it ran at >300fps. I’m talking specifically here about emulation of the CPC, not just drawing and updating the screen. So when I run it with the frame-limiter off, the machine runs so fast that any game is essentially unplayable.

Now, the Xbox 360. Some of you with experience with C# and the 360, will likely think I’ll mention garbage collection? Actually this wasn’t an issue for me. For any emulation runtime code, I made sure I wasn’t doing anything bad there. I generate absolutely no garbage when the game runs. I do allow for garbage in my “Pause Menu” code, however. But that’s really nice and easy to handle, just perform a full collection when unpausing. I like that approach for being able to write quick-and-dirty UI code, and keep the actual game clean.

So, not garbage? Nah, it’s just a raw CPU throughput problem. I hear someone shouting “JIT”…? Indeed; it does help a lot. The version of the emulator I’ve uploaded today runs at about half the speed of a CPC, when I have the debugger attached to the Xbox. So yeah: Release Build. No debugger attached. No garbage collection. This is as good as it gets.

I did a few things to drag the emulator kicking and screaming, to meet the 50fps that the CPC runs at:

• General optimizations which seem to benefit 360: Lookup tables seem to win over a handful of computational instructions. A general mistrust of the optimizer/JIT works well too. Cache variables yourself when doing multiple lookups from other classes, for example.
• Changed the routine which writes screen memory out to the XNA texture, to use unsafe code.
• Refactored my audio code to have the tone, noise and envelope generators as structs instead of classes (no vcalls). Ripped out my nice methods and just let my audio code access public members instead.
• The biggest win by far was hand-unrolling a simple for loop. It was an inner loop inside my graphics rendering code. It was walking over eight pixels for each byte of CPC memory. Instead of looping, I copy and pasted the line over eight times. My frame rate jumped from ~40fps to ~50fps.

Anyway. This was a bit of an eye-opener. I’m used to writing native code on 360, and I’m sure the thing wouldn’t break a sweat with a C++ version of my emulator. It’s odd to think that when I first worked on my emulator back in 1998, in C++; it was on a Pentium 120. That P120 ran the emulation fine, taxing the CPU at around 50% if I recall. Compare that to the ~95% I’m shipping XNACPC on the Xbox with.

So, the Compact Framework on 360 isn’t too hot. To be honest though, I’d have no qualms with developing something like this in C# if I was targeting PC. The full .NET Framework seems to be a good performer. Of course, straight-game code is going to be a whole different kettle of fish; compared to something as ridiculous as I’ve coded here. I don’t mean to slag off the Compact Framework; I’d imagine other XNA devs don’t see the huge disparity that I did, when they’re coding their games.

The Source

In an ideal world I’d be able to release it on the XBLIG channel. But given both copyright (and moral) issues with distributing games that other people have worked on, it’s not a possibility. This is a shame for people interested in playing with it though, since it means your only option requires a ‘Creators Club’ subscription. This costs $99 a year!

That said, I’d likely expect the few of you that actually read this blog (and the fewer that read this far down!) might be XNA coders. I’ve a zip file setup which contains the solution and project files, with the emulator ready to deploy to your Xbox. You can download it here:
xnacpc_1_0_source.zip

If you just want to browse the code online, I’ve put it up here at Google Code too:

• Google Code – XNACPC

If you’re interested in taking XNACPC and releasing something (legal and authorized) on XBL Indie Games, or Windows Phone 7. Please contact me about it, I’d love to work on the project!

PC Version

The PC version is playable without any sort of coding experience, nor requiring paying any money to Microsoft. You can download it here:
xnacpc_1_0_pc_binaries.zip

Just unzip it somewhere, and run ‘XNACPC.exe’. That’s it. There’s a number of games in the package, all setup ready to play. You may also need to download the XNA Runtime, if the app complains about missing something when you run it.

What’s Next?

Well, I really don’t plan to do any more work on XNACPC. There’s plenty of other CPC emulators which are more complete. They emulate more features, and run pretty much any game you can throw at them. The intention wasn’t to compete with those emulators, it was just to prove it’s possible to do the same in C# with XNA. I think I’ve done that, so there’s no real motivation to continue with the project.

It’s been fun; but I’ve been tinkering with CPC emulators in various forms since 1998. Right now I’m happy to close the door on this, and keep working on ‘new’ stuff instead of having one eye on the past.

Hope you enjoy poking around the source code!

So yeah, this is another post detailing a change made in the latest version of XNA.

This one was inspired by some comments on a previous blog post of mine: “StringBuilder to String with no garbage”. A developer named Matt, who was targeting Windows 7 Phones, pointed out that this particular trick with reflection was not working. He’d get a ‘FieldAccessException’ when attempting to access the internal private System.String object.

I’d just got round to installing the Windows Phone stuff to check this out, and indeed this is the case. I tried various different flags in the GetField() call, but had no luck in getting it to work. I tried setting up a trivial case with my own class containing a private ‘System.String’ and had the exact same problem.

So for whatever reason Windows Phone’s Compact Framework doesn’t allow access to private members via the GetValue() reflection call. In my aforementioned test with my own custom class, public members worked fine. In both cases the GetField() method was all good, it was just the GetValue() that throws ‘FieldAccessException’ in the case of private members.

Well… That’s a bit of a fly in the ointment right there.

Windows PC: A totally new version of StringBuilder?

Upon further inspection with the new XNA, I saw that the Windows setup had changed too. The StringBuilder object contents had changed completely.

For reference, here’s what I’ll call ‘version one’ of the StringBuilder. The one we’re used to from good ‘ol XNA 3.1:

StringBuilder version one

Here’s ‘version two’:

StringBuilder version two

Very, very different.

This new version maintains a series of chunks. As chunks are added it actually ends up linking together multiple new StringBuilder objects. The member ‘m_ChunkPrevious’ is this link.

From checking out the XNA 4.0 platforms, only the PC Windows build target uses this new StringBuilder. It could be argued that given that the GC performs well on PC that you need not use any tricks to grab internal strings anyway.

If you’re desperate though, I did come up with a crude method of grabbing the internal string without generating garbage. Be warned though, it’s far uglier than the previous ’3.1′ method I had.

Here goes:

const int MAX_STRING_SIZE = 64;
 
StringBuilder my_string_builder;
char[] my_char_array;
string my_dest_string = new string(' ', MAX_STRING_SIZE);
 
public static unsafe void CopyIntoString( string dest_string, char[] char_buffer, int length )
{
    System.Diagnostics.Debug.Assert( dest_string.Length >= length );
 
    unsafe
    {
        fixed ( char* dest_fixed = dest_string )
        {
                // Copy in the string data
                for ( int i = 0; i < length; i++ )
                {
                    dest_fixed[i] = char_buffer[i];
                }
 
                // NULL terminate the dest string
                if ( length < dest_string.Length )
                {
                    dest_fixed[length] = (char)0;
                }
        }
    }
}
 
public void PrepareSB()
{            
    my_string_builder = new StringBuilder(MAX_STRING_SIZE, MAX_STRING_SIZE);
 
    // Ensure this StringBuilder only has one chunk
    StringBuilder sanity_check = (StringBuilder)my_string_builder.GetType().GetField(
        "m_ChunkPrevious", BindingFlags.NonPublic | BindingFlags.Instance )
        .GetValue(my_string_builder);
    System.Diagnostics.Debug.Assert( sanity_check == null );
 
    // Grab the char array from the StringBuilder
    my_char_array = (char[])my_string_builder.GetType().GetField(
        "m_ChunkChars", BindingFlags.NonPublic | BindingFlags.Instance )
        .GetValue(my_string_builder);
}
 
//! This function can be called iteratively and generates no garbage
public void TestSB()
{
    // Put something in there
    my_string_builder.Length = 0;
    my_string_builder.Append("Hello World!");
 
    // Copy into our dest string
    CopyIntoString(my_dest_string, my_char_array, my_string_builder.Length);
 
    // Note this dest string is a little odd, the NULL terminator shows in the 
    // debugger with all the spaces after it.
    // On use of the string though in code, I'm seeing the correct amount of 
    // characters used. It stops at the NULL.
}

My eyes!

It works… But really; I wouldn’t touch this monstrosity.
 

Summary by Version and Platform

 

So what follows here is a summary of the version of StringBuilder used on each platform, under both XNA 3.1 and 4.0. I also note the version of ‘mscorlib’ as listed in the project references section; this is the assembly which contains the System.Text.StringBuilder class.

Visual Studio 2008, and XNA v3.1

Windows

mscorlib v2.0.0.0, Runtime Version v2.0.50727
Uses StringBuilder version one. The technique detailed here works fine.

Xbox 360

mscorlib v3.5.0.0, Runtime Version v2.0.50727
Uses StringBuilder version one. The technique detailed here works fine.

Visual Studio 2010, and XNA v4.0

Windows Phone 7

mscorlib v2.0.5.0, Runtime Version v2.0.50727
Uses StringBuilder version one. Unfortunately reflection access to the internal System.String is disallowed. You’re stuck with using ToString() and incurring garbage.

Windows

mscorlib v4.0.0.0, Runtime Version v4.0.30319
Uses StringBuilder version two. This new implementation of StringBuilder requires a convoluted way of converting the StringBuilder to a System.String, without generating garbage. I’d say incurring the garbage hit on PC is preferable to using the hacky stuff I’ve published in this post.

Xbox 360

mscorlib v2.0.5.0, Runtime Version v2.0.50727
Uses StringBuilder version one. The technique detailed here works fine.

Oddly enough the main version number dropped to v2.0.5.0, from v3.5.0.0. A little confusing. The versions though match the Windows Phone 7 assemblies exactly.

Conclusions

So, under XNA 4.0 you’re out of luck on Windows Phone 7 unfortunately. Please let me know though if this isn’t the case, if you find some other way of getting round it please drop a comment on this post.

For Xbox 360 we’re fortunately still good to use the same methods which worked under XNA 3.1.

It’s pretty much inevitable though that in future both Phone 7 and Xbox 360 are bumped up to the new .NET StringBuilder class, which Windows currently uses. Possibly even Xbox 360 may get the same reflection shackles that Phone 7 has now too.

Can only hope that when we get a new Compact Framework, it comes with a shiny new generational garbage collector implementation.

References

• String and StringBuilder in .NET 4
• How the StringBuilder class is implemented? Does it internally create new string objects each time we append?
• Does StringBuilder become immutable after a call to ToString?
• XNA/C# – StringBuilder to String with no garbage

I initially begun writing this particular article back in April. Back then with XNA 3.1 to play with, there was actually a method of ‘thread-local storage’ for Xbox. With the release of XNA 4.0, this last remaining native method was removed. The [ThreadLocal] attribute though was added to the Compact Framework, but it seems to be a stubbed non-functional attribute on Xbox 360.

So, where does that leave us? There is various ways you can manually code up a thread-local storage solution. The whole crux of it is data-retrieval and storage on a per-thread basis. The most immediately obvious way to go is just some sort of associative container, a Dictionary<> of some sort of thread ‘id’ mapped to the data you wish to store.

Just something like:

Dictionary< System.Threading.Thread, MyClass > my_tls_data;

There’s a lot of room for freedom in implementation though. Is Dictionary<> really the most suitable container? Should items be auto-created on the first access, or explicitly created by the user? Most of all I want to keep things performing well. Given some functionality performs extremely poorly on the Xbox 360, I want to be careful what I throw into my implementation.

The profiling approach

So, here’s how I set things up to profile changes I made throughout development:

• My test case sets up ten threads.
• Each thread has TLS data which consists of one simple integer.
• I kick off all ten threads at once, and each runs a loop 100,000 times incrementing their integer by one each time. (I verified the loop is not optimized out for the release-JIT’d builds).
• Once I see all ten threads have finished their loops I conclude the test and take the timing.
• I run the tests over and over and calculate a running average time. I display the results on screen, as opposed to debug output. So I can see the results on a release build which isn’t connected to the debugger. Pretty simple stuff, it just looks like this:
  
• Xbox times have a steady average very quickly after just a dozen or so tests. Windows times were more erratic and I generally left them for a couple of minutes to settle down.

Implementation choices

So, given the myriad of different ways this thing could be done, I broke down the choices I’d need to make. Here’s a breakdown piece-by-piece of the decisions I made along the way. Forgive the language, they’re just lifted verbatim from notes I made:

• Array over Dictionary<>
• For both Windows and Xbox with ten test threads, using an array instead of a Dictionary<> was a little over twice as fast. 74ms versus 151ms on Xbox.
• From additional testing on Xbox, array became a comparable speed to Dictionary<> at around 32 threads. I threw in a couple of different access patterns to test with too. Only if you’re going crazy with threads and data access, will Dictionary<> be a win.
• See the source code for the array implementation. It’s just essentially a simple associative container of ‘Thread’->’Data’. Potentially the whole array needs to be searched on each access. But keeping the array size small makes this a win over Dictionary<>.
• For vs foreach on array access
• A for loop incrementing an integer was faster.
• Doing the search with foreach() instead roughly doubled the times. 74ms versus 141ms.
• Thread object vs integer thread ID (ManagedThreadId)
• Each of these approaches were within a millisecond of one other. Something like 73.5ms versus 74ms. The integer version was the slight winner.
• I kind of like using the object reference, it makes debugging easier. So I went with that instead of using the integer ID.
• Call to Thread.CurrentThread on data access.
• Cost is prohibitive on Xbox, see a blog post I wrote a while back:
  http://www.gavpugh.com/2010/04/30/xnac-thread-currentthread-is-slow-on-xbox-360/
• This is still the case under XNA 4.0, figures haven’t changed. For the testing I was doing for these classes, calling Thread.CurrentThread on Xbox each access increases the time taken in one example from 74ms up to 7248ms. The equivalent test on Windows went from 26ms up to 32ms.
• My class has to provide a data accessor which takes a thread object param.
• Explicit cleanup, versus WeakReference to determine threads are done with.
• WeakReference is slow on Xbox unfortunately too. Even worse than Thread.CurrentThread in my tests. The example case I used shot up from 74ms to over 40,000ms. Windows jumped from 26ms to 76ms.
• I chose to use explicit cleanup.
• Side note: To make cleanup easier on thread destruction, consider a TLS manager class. The TLS objects can register with the manager upon creation, and the manager can walk them all destroy any data associated to a specific thread.
• Explicit construction, versus ‘auto’ construction.
• Auto construction isn’t too much of a performance drop. It just adds an extra branch to the code if the data access fails to find its data. Which you probably would have in there anyway to throw an Exception, or fire an assert.
• In my tests removing auto construction from my code, dropped the reference 74ms case down to 73ms. Good tradeoff in my opinion, so I kept auto-construction.
• Avoid thread locks for data access
• Locks are only required for adding new array entries, or removing them. The data access function should be able to execute in the general case without a lock.
• With auto-construction though, a new entry could be added within the accessing function. There’s a risk of a race condition if two concurrent threads try to auto-construct the data for one specific thread.
• As long as we can be sure that threads only access their own data, everything is fine. So the GetData(Thread) version should verify that the thread matches Thread.CurrentThread.
• The check only needs to be made after the search fails, just as it’s about to do the auto-construction. I ended up just putting this code within #if DEBUG, so I didn’t have to worry about any performance hit.

Explicit cleanup

I wasn’t too happy with requiring explicit cleanup. It means the cleanest solution would be some kind of global static function which ensured all various TLS variables are freed. Something like:

public static void CleanupTLS()
{
    Profiler.GetCurrentNodeStack().FreeData();
    Debug.Output.GetStringBuilder().FreeData();
    Renderer.DebugLines.FreeData();
 
    // etc...
}

Consider too that some of these variables may be initially at private scope, so they would need to be specifically exposed somehow so the freeing can occur. At best you’d need to add explicit public freeing functions to various affected modules.

As hinted in my notes, a global manager class which registers all TLS variables could make this a lot cleaner. As TLS data is instantiated, I will register with the manager. Where this occurs is not performance-critical. The freeing isn’t performance-critical either. The freeing though is pretty simple, the manager just walks all the TLS references it’s been given, and attempts to purge any with data for a specific thread.

So instead of calling the above mess, you can just call:

Core.ThreadLocalManager.FreeData();

Bit happier with it now.

Profiling figures

I explained my profiling setup earlier in this article. Here are the figures with my final implementation, compared against the existing methods of TLS. The ‘No param’ version of my code makes a call to ‘Thread.CurrentThread’ each time to determine what data to pass back. The ‘Thread param’ version uses a passed in thread reference to retrieve the data instead.

The figures are for ten concurrent threads making 100,000 accesses each:

 
* Using ‘Thread.CurrentThread’ on Xbox 360 is very slow.
** The GetData/SetData() (LocalDataStoreSlot) method doesn’t work under XNA 4.0 on Xbox 360. These figures are from when I ran the same tests months ago under XNA 3.1 on 360.

Given these figures I’m happy to use my new implementation for both Windows and Xbox 360. There’s no alternatives currently for Xbox 360, so given I’ve explored many optimization possibilities it’s pretty much as good as it gets. For Windows it actually is slightly faster than even [ThreadStatic], so using the same code across both totally makes sense.

Show me the code

Here’s the code for download:

ThreadLocal.cs

It also includes the class for ‘ThreadLocalManager’, which as detailed earlier assists with easier cleanup of data from destroyed threads.

Here’s a quick contrived bit of code to show how these classes should be used:

private static Core.ThreadLocal<StringBuilder> ms_tls_stringbuilder = 
    new Core.ThreadLocal<StringBuilder>();
 
//! Entry function for new worker threads
public static void ThreadRun()
{
    // Grab the TLS stringbuilder
    StringBuilder sb = ms_tls_stringbuilder.Data;
 
    // Do bunch of work
    ...
 
    // Free all TLS data associated with this thread
    Core.ThreadLocalManager.FreeData();
}

The TLS data access has a function which takes a thread parameter. This should be used in performance-critical code, given my findings detailed in this article. Just note the ‘Thread.CurrentThread’ once in your new thread, and pass it around to any performance-critical functions that require working with TLS.

Value Types

My implementation is currently tied to just using reference types, value types will not work with it. An alternative is to just simply wrap value types in a class, which is what I’ve been happy to do with my engine.

If you absolutely need a thread-local implementation which does work natively with value types, it’s not too hard to do. You’d want to set up an alternative class, with pretty much the same code in it. Change the ‘where’ constraint to simply: ‘struct’. There’s a couple of different ways I could see the implementation going:

• Implement separate Get and Set data methods. Maybe just a single property?
• Have a get method not return a value, but instead pass it back through a reference parameter.

There’s no reason why you couldn’t have both these types of interface for it.

References

• MSDN: Namespaces, Types, and Members in the .NET Compact Framework for Xbox 360
• MSDN: Thread Local Storage: Thread-Relative Static Fields and Data Slots
• XNA Forums: possible to have an array on stack, not in heap?
• XNA Forums: Why no ThreadStaticAttribute on XNA?
• MSDN: Constraints on Type Parameters

Continuing on from my last XNA post, I had a go at using [ThreadStatic] on the Xbox. Specifically this attribute was not available with XNA 3.1, but was introduced in the new 4.0 version.

At first glace it worked fine, I threw in the same code I’d used on Windows. Unlike under 3.1 it compiles without issue. However, the attribute appears to actually do nothing it all. It behaves just like the attribute wasn’t there, just like a regular plain static variable.

I found this issue from attempting to use [ThreadStatic] within some code I had written for a future article here. The code was to profile various methods of implementing Thread-local storage on the Xbox 360. Switching the code to add a test case for [ThreadStatic] worked fine at first, but I was seeing very odd profile numbers coming back from it. On closer inspection in the debugger I could see that the TLS values weren’t thread-specific, they were getting written to at runtime by other executing threads.

Show me the code

So, I spliced out some code and came up with a contrived test to check how [ThreadStatic] is working. Here’s the code:

public class ThreadTest
{
    [ThreadStatic] private static int m_int_counter = 0;
 
    private Thread m_thread;
    private int m_affinity;
    private int m_thread_num;
 
    public ThreadTest( int thread_num, int affinity )
    {
        m_affinity = affinity;
        m_thread_num = thread_num;
        m_thread = new Thread( Run );
    }
 
    public void Start()
    {
        m_thread.Start( (object)this );
    }
 
    public static void Run( object passed_obj )
    {
        ThreadTest this_obj = (ThreadTest)passed_obj;
 
        Debug.WriteLine( "Started thread #" +
            this_obj.m_thread_num + " Affinity=" + this_obj.m_affinity );
 
#if XBOX
        Thread.CurrentThread.SetProcessorAffinity( this_obj.m_affinity );
#endif //XBOX
 
        Debug.WriteLine( 
            "Thread #" + this_obj.m_thread_num + 
            ": Before m_int_counter " + m_int_counter );
 
        m_int_counter++;
 
        Debug.WriteLine( 
            "Thread #" + this_obj.m_thread_num + 
            ": After m_int_counter " + m_int_counter );
    }
}
 
// The four affinities that are okay to use. See:
// http://msdn.microsoft.com/en-us/library/microsoft.xna.net_cf.system.threading.thread.setprocessoraffinity.aspx
private static readonly int[] m_affinities = new int[4] { 1, 3, 4, 5 };
 
private static bool m_started = false;
 
// Call this from anywhere, I just threw it in Update() in a new XNA game project
public void Test()
{
    if ( m_started )
    {
        // Just do it once...
        return;
    }
    m_started = true;
 
    const int NUM_THREADS = 10;
 
    ThreadTest[] threads = new ThreadTest[NUM_THREADS];
 
    // Create ten threads and kick them off near-enough at the same time.
    for ( int i = 0; i < NUM_THREADS; i++ )
    {
        int affinity = m_affinities[i % 4];
        threads[i] = new ThreadTest( i, affinity );
        threads[i].Start();
    }
}

What’s up

Firstly, here’s the output under Windows. The ‘before’ number is always zero, and the ‘after’ is always one. The [ThreadStatic] variable is indeed unique to each thread instance.

Windows

Started thread #0 Affinity=1
Started thread #6 Affinity=4
Started thread #4 Affinity=1
Started thread #7 Affinity=5
Started thread #8 Affinity=1
Started thread #2 Affinity=4
Started thread #9 Affinity=3
Thread #7: Before m_int_counter 0
Thread #8: Before m_int_counter 0
Thread #0: Before m_int_counter 0
Thread #6: Before m_int_counter 0
Thread #4: Before m_int_counter 0
Thread #2: Before m_int_counter 0
Thread #9: Before m_int_counter 0
Thread #8: After m_int_counter 1
Thread #7: After m_int_counter 1
Thread #0: After m_int_counter 1
Thread #6: After m_int_counter 1
Thread #4: After m_int_counter 1
Thread #9: After m_int_counter 1
Thread #2: After m_int_counter 1
Started thread #5 Affinity=3
Started thread #3 Affinity=5
Started thread #1 Affinity=3
Thread #1: Before m_int_counter 0
Thread #1: After m_int_counter 1
Thread #5: Before m_int_counter 0
Thread #5: After m_int_counter 1
Thread #3: Before m_int_counter 0
Thread #3: After m_int_counter 1

 
Disregard the affinity value for Windows, it’s not used. Anyhow, here’s the Xbox output.

Xbox 360

Started thread #0 Affinity=1
Thread #5: Before m_int_counter 3
Thread #6: Before m_int_counter 3
Thread #3: Before m_int_counter 3
Thread #2: Before m_int_counter 3
Thread #7: Before m_int_counter 3
Thread #9: Before m_int_counter 3
Thread #0: Before m_int_counter 3
Thread #5: After m_int_counter 4
Thread #6: After m_int_counter 5
Thread #3: After m_int_counter 6
Thread #2: After m_int_counter 7
Thread #7: After m_int_counter 8
Thread #9: After m_int_counter 9
Thread #0: After m_int_counter 10

The [ThreadStatic] variable is obviously not unique to each thread. It’s just behaving like a regular static. If I comment out the line which sets the thread affinity (which is Xbox-specific code), I get similar output.

What’s also concerning is that the “Debug.WriteLine()” function seems to be randomly failing. Each time I run it, I get different lines missed out from my expected output.

Perhaps on Xbox it’s implementation is not completely thread-safe? I swear it was on XNA 3.1′s Compact Framework, but maybe my memory is failing me.

Solutions?

I have an alternate way of implementing TLS with C#. It’s very fast as long as you’re not running a ridiculous number of threads (under a dozen is fine). When I last looked at the code under XNA 3.1 it outperformed the ‘GetData/SetData()’ method of TLS considerably. In fact when I tested the code under Windows and compared it to [ThreadStatic], it outperformed that too.

Will be the next article I post up, since I think I’ve encountered all the issues I can on the road to finishing it up.

References

• ThreadStaticAttribute Class
• Thread.SetProcessorAffinity Method

A few months back I was partway through an article about XNA. I was going to cover how to implement efficient “Thread Local Storage” on the Xbox 360. Back in Game Studio v3.1 I found that the [ThreadStatic] attribute was not supported on the Xbox, and the only workable methods out of the box were the Thread.GetData(), Thread.SetData() methods. Those methods aren’t good performance-wise, so I proceeded to look at more efficient alternatives.

That article was going to detail the solution I came up with, and currently used in my engine. However upon revisiting the work recently and upgrading to the new v4.0 XNA, I found that I had some compile errors. Specifically ‘System.Threading.LocalDataStoreSlot’ was now missing, it’s that slow method of TLS I was using to benchmark against. So I commented that code out. I then figured why not for the hell of it try to enable the [ThreadStatic] code, that I had #ifdef’d to the WINDOWS build. Lo and behold, it now compiled on Xbox 360!

No idea if it’s any better performing than the old ‘LocalDataStoreSlot’ though, or better than the alternate method I came up with. That’s an exercise for another day.

My Googling Escapades

The only article I could find back when I was working on 3.1 about [ThreadStatic] on Xbox was this one. Doing a search now, I couldn’t find anything else new. I also tried searching for information about “LocalDataStoreSlot”, the class which was removed in the 4.0 upgrade. Again, I found nothing about the removal.

I also had noticed in some other code I have that the ‘System.Diagnostics.Trace’ class, and static functions therein were also removed. Now I start to scratch my head a little and wonder what else has disappeared, and what other cool things may have been added. My searches weren’t very fruitful, I just found a handful of forum posts which mentioned briefly some sort of changes to the Compact Framework (I’ve included them in my references at the bottom of this page). Nothing complete and comprehensive which listed all the differences.

The MSDN documentation does denote on the page for each class, type, function… which platforms it is available on. There’s also a dropdown to switch the framework version. I confess I found it a bit unwieldy to check up on. For example ‘ThreadStaticAttribute’ shows a ‘Silverlight’ entry in the dropdown box. On that page it denotes that it works on the Xbox 360. Where ‘LocalDataStoreSlot’ (the one which was removed), does not have Silverlight in it’s list, but does show XNA support for the 360 on the 3.5 Framework. Which tells me that it used to work, but now is deprecated in the Silverlight-compliant Framework.

Anyhow, checking these things one-by-one isn’t exactly viable.

Taking a dump

Knowing that there was a number of changes, but not knowing exactly what those changes were; I was still a little curious. What I did was to use the ‘ildasm’ tool to dump the types which existed in the .NET Framework DLL files.

For those equally curious, they reside here:
C:\Program Files\Microsoft XNA\XNA Game Studio\v3.1\References\Xbox360
and here:
C:\Program Files\Microsoft XNA\XNA Game Studio\v4.0\References\Xbox360
Or wherever your “\Program Files” directory lies.

With a little tinkering I could collate that output and determine the changes which occurred between the two versions of the Framework. I omitted the “Microsoft.Xna.Framework.Input.Touch” library from the output though, since new Xbox 360 projects do not include it as a reference. I’m unsure though as to why there is a DLL sitting in the “Xbox 360″ directory. Possibly early Natal/Kinect support code? Heh, I doubt it. I’m guessing it’s just stub functionality for parity with the Windows 7 phones.

So anyhow, here’s the data I collected. Hopefully others may find this useful… Or possibly just point me to a website that had this information already.

System types removed from the Xbox 360 Compact Framework

These are types which used to exist in the Compact Framework for the Xbox 360, in the “XNA Game Studio” v3.1 release. But these are now missing from the new v4.0 release:

  Microsoft.Xna.Framework.BatteryChargeStatus
  Microsoft.Xna.Framework.Graphics.BasicDirectionalLight
  Microsoft.Xna.Framework.Graphics.ClipPlane
  Microsoft.Xna.Framework.Graphics.ClipPlaneCollection
  Microsoft.Xna.Framework.Graphics.Color
  Microsoft.Xna.Framework.Graphics.CompilerOptions
  Microsoft.Xna.Framework.Graphics.DepthStencilBuffer
  Microsoft.Xna.Framework.Graphics.DeviceNotSupportedException
  Microsoft.Xna.Framework.Graphics.DeviceStillDrawingException
  Microsoft.Xna.Framework.Graphics.DeviceType
  Microsoft.Xna.Framework.Graphics.DriverInternalErrorException
  Microsoft.Xna.Framework.Graphics.EffectFunction
  Microsoft.Xna.Framework.Graphics.EffectFunctionCollection
  Microsoft.Xna.Framework.Graphics.EffectParameterBlock
  Microsoft.Xna.Framework.Graphics.EffectPool
  Microsoft.Xna.Framework.Graphics.GammaRamp
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/AddressCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/BlendCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/CompareCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/CursorCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/DeclarationTypeCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/DeviceCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/DriverCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/FilterCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/LineCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/PixelShaderCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/PrimitiveCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/RasterCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/ShadingCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/StencilCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/TextureCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/VertexFormatCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/VertexProcessingCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCapabilities/VertexShaderCaps
  Microsoft.Xna.Framework.Graphics.GraphicsDeviceCreationParameters
  Microsoft.Xna.Framework.Graphics.MultiSampleType
  Microsoft.Xna.Framework.Graphics.OutOfVideoMemoryException
  Microsoft.Xna.Framework.Graphics.PackedVector.Normalized101010
  Microsoft.Xna.Framework.Graphics.PackedVector.Rgba32
  Microsoft.Xna.Framework.Graphics.PackedVector.UInt101010
  Microsoft.Xna.Framework.Graphics.PixelShader
  Microsoft.Xna.Framework.Graphics.PresentOptions
  Microsoft.Xna.Framework.Graphics.QueryUsages
  Microsoft.Xna.Framework.Graphics.RasterStatus
  Microsoft.Xna.Framework.Graphics.RenderState
  Microsoft.Xna.Framework.Graphics.RenderTarget
  Microsoft.Xna.Framework.Graphics.ResolveTexture2D
  Microsoft.Xna.Framework.Graphics.ResourceType
  Microsoft.Xna.Framework.Graphics.SaveStateMode
  Microsoft.Xna.Framework.Graphics.ShaderConstant
  Microsoft.Xna.Framework.Graphics.ShaderConstantCollection
  Microsoft.Xna.Framework.Graphics.ShaderConstantTable
  Microsoft.Xna.Framework.Graphics.ShaderProfile
  Microsoft.Xna.Framework.Graphics.ShaderRegisterSet
  Microsoft.Xna.Framework.Graphics.SpriteBlendMode
  Microsoft.Xna.Framework.Graphics.StateBlock
  Microsoft.Xna.Framework.Graphics.SwapEffect
  Microsoft.Xna.Framework.Graphics.TextureUsage
  Microsoft.Xna.Framework.Graphics.TextureWrapCoordinates
  Microsoft.Xna.Framework.Graphics.VertexElementMethod
  Microsoft.Xna.Framework.Graphics.VertexShader
  Microsoft.Xna.Framework.Graphics.VertexStream
  Microsoft.Xna.Framework.Graphics.VertexStreamCollection
  Microsoft.Xna.Framework.Net.InviteAcceptedEventArgs
  Microsoft.Xna.Framework.Net.NetworkException
  Microsoft.Xna.Framework.Net.NetworkNotAvailableException
  Microsoft.Xna.Framework.NoSuitableGraphicsDeviceException
  Microsoft.Xna.Framework.PowerLineStatus
  Microsoft.Xna.Framework.PowerStatus
  System.ApplicationException
  System.CharEnumerator
  System.Collections.ArrayList
  System.Collections.CaseInsensitiveComparer
  System.Collections.CaseInsensitiveHashCodeProvider
  System.Collections.CollectionBase
  System.Collections.Comparer
  System.Collections.Generic.SortedList`2
  System.Collections.Hashtable
  System.Collections.IHashCodeProvider
  System.Collections.Queue
  System.Collections.SortedList
  System.Collections.Specialized.BitVector32
  System.Collections.Specialized.BitVector32/Section
  System.Collections.Specialized.HybridDictionary
  System.Collections.Specialized.ListDictionary
  System.Collections.Specialized.NameObjectCollectionBase
  System.Collections.Specialized.NameObjectCollectionBase/KeysCollection
  System.Collections.Specialized.NameValueCollection
  System.Collections.Specialized.StringDictionary
  System.Collections.Stack
  System.ComponentModel.AddingNewEventArgs
  System.ComponentModel.AddingNewEventHandler
  System.ComponentModel.AttributeCollection
  System.ComponentModel.BindingList`1
  System.ComponentModel.CancelEventHandler
  System.ComponentModel.CollectionChangeAction
  System.ComponentModel.CollectionChangeEventArgs
  System.ComponentModel.CollectionChangeEventHandler
  System.ComponentModel.Component
  System.ComponentModel.ComponentResourceManager
  System.ComponentModel.Container
  System.ComponentModel.DataObjectAttribute
  System.ComponentModel.DataObjectMethodAttribute
  System.ComponentModel.DataObjectMethodType
  System.ComponentModel.DesignerCategoryAttribute
  System.ComponentModel.DesignTimeVisibleAttribute
  System.ComponentModel.EventDescriptor
  System.ComponentModel.EventDescriptorCollection
  System.ComponentModel.EventHandlerList
  System.ComponentModel.IBindingList
  System.ComponentModel.IBindingListView
  System.ComponentModel.ICancelAddNew
  System.ComponentModel.ICustomTypeDescriptor
  System.ComponentModel.IDataErrorInfo
  System.ComponentModel.IListSource
  System.ComponentModel.IRaiseItemChangedEvents
  System.ComponentModel.ISupportInitialize
  System.ComponentModel.ISupportInitializeNotification
  System.ComponentModel.ITypedList
  System.ComponentModel.ListChangedEventArgs
  System.ComponentModel.ListChangedEventHandler
  System.ComponentModel.ListChangedType
  System.ComponentModel.ListSortDescription
  System.ComponentModel.ListSortDescriptionCollection
  System.ComponentModel.MarshalByValueComponent
  System.ComponentModel.MemberDescriptor
  System.ComponentModel.PropertyDescriptorCollection
  System.ComponentModel.TypeDescriptor
  System.ComponentModel.Win32Exception
  System.Diagnostics.DefaultTraceListener
  System.Diagnostics.TextWriterTraceListener
  System.Diagnostics.Trace
  System.Diagnostics.TraceListener
  System.Diagnostics.TraceListenerCollection
  System.Globalization.CultureTypes
  System.Globalization.DaylightTime
  System.IO.Compression.CompressionMode
  System.IO.Compression.DeflateStream
  System.IO.Compression.GZipStream
  System.IO.InvalidDataException
  System.MarshalByRefObject
  System.Resources.ResourceReader
  System.Security.Policy.Evidence
  System.SerializableAttribute
  System.Text.ASCIIEncoding
  System.Text.RegularExpressions.RegexRunner
  System.Text.RegularExpressions.RegexRunnerFactory
  System.Text.UTF7Encoding
  System.Threading.EventResetMode
  System.Threading.Mutex
  System.Threading.ThreadPriority
  System.TimeZone
  System.TypedReference
  System.UriHostNameType
  System.UriPartial
  System.Xml.EntityHandling
  System.Xml.Formatting
  System.Xml.IHasXmlNode
  System.Xml.Schema.IXmlSchemaInfo
  System.Xml.Schema.ValidationEventArgs
  System.Xml.Schema.ValidationEventHandler
  System.Xml.Schema.XmlAtomicValue
  System.Xml.Schema.XmlSchemaAll
  System.Xml.Schema.XmlSchemaAnnotated
  System.Xml.Schema.XmlSchemaAnnotation
  System.Xml.Schema.XmlSchemaAny
  System.Xml.Schema.XmlSchemaAnyAttribute
  System.Xml.Schema.XmlSchemaAppInfo
  System.Xml.Schema.XmlSchemaAttribute
  System.Xml.Schema.XmlSchemaAttributeGroup
  System.Xml.Schema.XmlSchemaAttributeGroupRef
  System.Xml.Schema.XmlSchemaChoice
  System.Xml.Schema.XmlSchemaCompilationSettings
  System.Xml.Schema.XmlSchemaComplexContent
  System.Xml.Schema.XmlSchemaComplexContentExtension
  System.Xml.Schema.XmlSchemaComplexContentRestriction
  System.Xml.Schema.XmlSchemaComplexType
  System.Xml.Schema.XmlSchemaContent
  System.Xml.Schema.XmlSchemaContentModel
  System.Xml.Schema.XmlSchemaContentProcessing
  System.Xml.Schema.XmlSchemaContentType
  System.Xml.Schema.XmlSchemaDatatype
  System.Xml.Schema.XmlSchemaDatatypeVariety
  System.Xml.Schema.XmlSchemaDerivationMethod
  System.Xml.Schema.XmlSchemaDocumentation
  System.Xml.Schema.XmlSchemaElement
  System.Xml.Schema.XmlSchemaEnumerationFacet
  System.Xml.Schema.XmlSchemaException
  System.Xml.Schema.XmlSchemaExternal
  System.Xml.Schema.XmlSchemaFacet
  System.Xml.Schema.XmlSchemaFractionDigitsFacet
  System.Xml.Schema.XmlSchemaGroup
  System.Xml.Schema.XmlSchemaGroupBase
  System.Xml.Schema.XmlSchemaGroupRef
  System.Xml.Schema.XmlSchemaIdentityConstraint
  System.Xml.Schema.XmlSchemaImport
  System.Xml.Schema.XmlSchemaInclude
  System.Xml.Schema.XmlSchemaInference
  System.Xml.Schema.XmlSchemaInference/InferenceOption
  System.Xml.Schema.XmlSchemaInferenceException
  System.Xml.Schema.XmlSchemaInfo
  System.Xml.Schema.XmlSchemaKey
  System.Xml.Schema.XmlSchemaKeyref
  System.Xml.Schema.XmlSchemaLengthFacet
  System.Xml.Schema.XmlSchemaMaxExclusiveFacet
  System.Xml.Schema.XmlSchemaMaxInclusiveFacet
  System.Xml.Schema.XmlSchemaMaxLengthFacet
  System.Xml.Schema.XmlSchemaMinExclusiveFacet
  System.Xml.Schema.XmlSchemaMinInclusiveFacet
  System.Xml.Schema.XmlSchemaMinLengthFacet
  System.Xml.Schema.XmlSchemaNotation
  System.Xml.Schema.XmlSchemaNumericFacet
  System.Xml.Schema.XmlSchemaObjectCollection
  System.Xml.Schema.XmlSchemaObjectEnumerator
  System.Xml.Schema.XmlSchemaObjectTable
  System.Xml.Schema.XmlSchemaParticle
  System.Xml.Schema.XmlSchemaPatternFacet
  System.Xml.Schema.XmlSchemaRedefine
  System.Xml.Schema.XmlSchemaSequence
  System.Xml.Schema.XmlSchemaSimpleContent
  System.Xml.Schema.XmlSchemaSimpleContentExtension
  System.Xml.Schema.XmlSchemaSimpleContentRestriction
  System.Xml.Schema.XmlSchemaSimpleType
  System.Xml.Schema.XmlSchemaSimpleTypeContent
  System.Xml.Schema.XmlSchemaSimpleTypeList
  System.Xml.Schema.XmlSchemaSimpleTypeRestriction
  System.Xml.Schema.XmlSchemaSimpleTypeUnion
  System.Xml.Schema.XmlSchemaTotalDigitsFacet
  System.Xml.Schema.XmlSchemaType
  System.Xml.Schema.XmlSchemaUnique
  System.Xml.Schema.XmlSchemaUse
  System.Xml.Schema.XmlSchemaValidationException
  System.Xml.Schema.XmlSchemaValidationFlags
  System.Xml.Schema.XmlSchemaValidator
  System.Xml.Schema.XmlSchemaValidity
  System.Xml.Schema.XmlSchemaWhiteSpaceFacet
  System.Xml.Schema.XmlSchemaXPath
  System.Xml.Schema.XmlValueGetter
  System.Xml.Serialization.IXmlTextParser
  System.Xml.Serialization.SoapAttributeAttribute
  System.Xml.Serialization.SoapAttributeOverrides
  System.Xml.Serialization.SoapAttributes
  System.Xml.Serialization.SoapElementAttribute
  System.Xml.Serialization.SoapEnumAttribute
  System.Xml.Serialization.SoapIgnoreAttribute
  System.Xml.Serialization.SoapIncludeAttribute
  System.Xml.Serialization.SoapReflectionImporter
  System.Xml.Serialization.SoapTypeAttribute
  System.Xml.Serialization.UnreferencedObjectEventArgs
  System.Xml.Serialization.UnreferencedObjectEventHandler
  System.Xml.Serialization.XmlAnyAttributeAttribute
  System.Xml.Serialization.XmlAttributeEventArgs
  System.Xml.Serialization.XmlAttributeEventHandler
  System.Xml.Serialization.XmlElementEventArgs
  System.Xml.Serialization.XmlElementEventHandler
  System.Xml.Serialization.XmlNodeEventArgs
  System.Xml.Serialization.XmlNodeEventHandler
  System.Xml.ValidationType
  System.Xml.WhitespaceHandling
  System.Xml.XmlAttribute
  System.Xml.XmlAttributeCollection
  System.Xml.XmlCDataSection
  System.Xml.XmlCharacterData
  System.Xml.XmlComment
  System.Xml.XmlDeclaration
  System.Xml.XmlDocument
  System.Xml.XmlDocumentFragment
  System.Xml.XmlElement
  System.Xml.XmlEntityReference
  System.Xml.XmlImplementation
  System.Xml.XmlLinkedNode
  System.Xml.XmlNamedNodeMap
  System.Xml.XmlNode
  System.Xml.XmlNodeChangedAction
  System.Xml.XmlNodeChangedEventArgs
  System.Xml.XmlNodeChangedEventHandler
  System.Xml.XmlNodeList
  System.Xml.XmlNodeOrder
  System.Xml.XmlNodeReader
  System.Xml.XmlOutputMethod
  System.Xml.XmlProcessingInstruction
  System.Xml.XmlSignificantWhitespace
  System.Xml.XmlText
  System.Xml.XmlTextReader
  System.Xml.XmlTextWriter
  System.Xml.XmlUrlResolver
  System.Xml.XmlWhitespace
  System.Xml.XPath.XPathException
  System.Xml.XPath.XPathItem
  System.Xml.Xsl.XsltException

System types added to the Xbox 360 Compact Framework

These are types which did not exist in the Compact Framework for the Xbox 360, in the “XNA Game Studio” v3.1 release. But these are now present in the new v4.0 release:

  Microsoft.Win32.SafeHandles.SafeHandleMinusOneIsInvalid
  Microsoft.Win32.SafeHandles.SafeHandleZeroOrMinusOneIsInvalid
  Microsoft.Win32.SafeHandles.SafeWaitHandle
  Microsoft.Xna.Framework.Audio.AudioChannels
  Microsoft.Xna.Framework.Audio.DynamicSoundEffectInstance
  Microsoft.Xna.Framework.Audio.Microphone
  Microsoft.Xna.Framework.Audio.MicrophoneState
  Microsoft.Xna.Framework.Audio.NoMicrophoneConnectedException
  Microsoft.Xna.Framework.Color
  Microsoft.Xna.Framework.DisplayOrientation
  Microsoft.Xna.Framework.GamerServices.Achievement
  Microsoft.Xna.Framework.GamerServices.AchievementCollection
  Microsoft.Xna.Framework.GamerServices.AvatarRendererState
  Microsoft.Xna.Framework.GamerServices.GameUpdateRequiredException
  Microsoft.Xna.Framework.GamerServices.IAvatarAnimation
  Microsoft.Xna.Framework.GamerServices.InviteAcceptedEventArgs
  Microsoft.Xna.Framework.GamerServices.LeaderboardEntry
  Microsoft.Xna.Framework.GamerServices.LeaderboardIdentity
  Microsoft.Xna.Framework.GamerServices.LeaderboardKey
  Microsoft.Xna.Framework.GamerServices.LeaderboardOutcome
  Microsoft.Xna.Framework.GamerServices.LeaderboardReader
  Microsoft.Xna.Framework.GamerServices.LeaderboardWriter
  Microsoft.Xna.Framework.GamerServices.NetworkException
  Microsoft.Xna.Framework.GamerServices.NetworkNotAvailableException
  Microsoft.Xna.Framework.GamerServices.PropertyDictionary
  Microsoft.Xna.Framework.Graphics.AlphaTestEffect
  Microsoft.Xna.Framework.Graphics.BlendState
  Microsoft.Xna.Framework.Graphics.DepthStencilState
  Microsoft.Xna.Framework.Graphics.DirectionalLight
  Microsoft.Xna.Framework.Graphics.DualTextureEffect
  Microsoft.Xna.Framework.Graphics.EffectMaterial
  Microsoft.Xna.Framework.Graphics.EnvironmentMapEffect
  Microsoft.Xna.Framework.Graphics.GraphicsProfile
  Microsoft.Xna.Framework.Graphics.IEffectFog
  Microsoft.Xna.Framework.Graphics.IEffectLights
  Microsoft.Xna.Framework.Graphics.IEffectMatrices
  Microsoft.Xna.Framework.Graphics.IVertexType
  Microsoft.Xna.Framework.Graphics.NoSuitableGraphicsDeviceException
  Microsoft.Xna.Framework.Graphics.PackedVector.Bgra4444
  Microsoft.Xna.Framework.Graphics.RasterizerState
  Microsoft.Xna.Framework.Graphics.RenderTargetBinding
  Microsoft.Xna.Framework.Graphics.SkinnedEffect
  Microsoft.Xna.Framework.Graphics.VertexBufferBinding
  Microsoft.Xna.Framework.LaunchParameters
  Microsoft.Xna.Framework.Net.WriteLeaderboardsEventArgs
  Microsoft.Xna.Framework.TitleContainer
  System.AccessViolationException
  System.AppDomainManager
  System.AppDomainSetup
  System.ComponentModel.AsyncOperation
  System.ComponentModel.AsyncOperationManager
  System.ComponentModel.BackgroundWorker
  System.ComponentModel.CategoryAttribute
  System.ComponentModel.ComponentCollection
  System.ComponentModel.DescriptionAttribute
  System.ComponentModel.DoWorkEventArgs
  System.ComponentModel.DoWorkEventHandler
  System.ComponentModel.ITypeDescriptorContext
  System.ComponentModel.ProgressChangedEventArgs
  System.ComponentModel.ProgressChangedEventHandler
  System.ComponentModel.ReadOnlyAttribute
  System.ComponentModel.RunWorkerCompletedEventArgs
  System.ComponentModel.RunWorkerCompletedEventHandler
  System.ComponentModel.TypeConverterAttribute
  System.ContextStaticAttribute
  System.DataMisalignedException
  System.DateTimeOffset
  System.Diagnostics.DebuggerBrowsableAttribute
  System.Diagnostics.DebuggerBrowsableState
  System.Diagnostics.DebuggerDisplayAttribute
  System.Diagnostics.DebuggerTypeProxyAttribute
  System.Diagnostics.StackFrame
  System.Diagnostics.StackTrace
  System.DllNotFoundException
  System.Environment/SpecialFolder
  System.ExecutionEngineException
  System.FieldAccessException
  System.FileStyleUriParser
  System.FtpStyleUriParser
  System.GenericUriParser
  System.GenericUriParserOptions
  System.Globalization.HebrewCalendar
  System.Globalization.HijriCalendar
  System.Globalization.UmAlQuraCalendar
  System.HttpStyleUriParser
  System.InvalidTimeZoneException
  System.IO.FileLoadException
  System.IO.IsolatedStorage.IsolatedStorageException
  System.IO.IsolatedStorage.IsolatedStorageFile
  System.IO.IsolatedStorage.IsolatedStorageFileStream
  System.IO.UnmanagedMemoryStream
  System.LoaderOptimization
  System.MissingFieldException
  System.NotFiniteNumberException
  System.Reflection.AssemblyFileVersionAttribute
  System.Reflection.GenericParameterAttributes
  System.Reflection.InterfaceMapping
  System.Reflection.IReflect
  System.Reflection.LocalVariableInfo
  System.Reflection.MemberFilter
  System.Reflection.ReflectionTypeLoadException
  System.Reflection.ResourceAttributes
  System.Reflection.TargetException
  System.Reflection.TypeDelegator
  System.ResolveEventArgs
  System.ResolveEventHandler
  System.Resources.UltimateResourceFallbackLocation
  System.Runtime.CompilerServices.CompilationRelaxations
  System.Runtime.CompilerServices.CompilationRelaxationsAttribute
  System.Runtime.CompilerServices.RuntimeCompatibilityAttribute
  System.Runtime.InteropServices.AllowReversePInvokeCallsAttribute
  System.Runtime.InteropServices.ClassInterfaceAttribute
  System.Runtime.InteropServices.ClassInterfaceType
  System.Runtime.InteropServices.CoClassAttribute
  System.Runtime.InteropServices.ComDefaultInterfaceAttribute
  System.Runtime.InteropServices.COMException
  System.Runtime.InteropServices.ComImportAttribute
  System.Runtime.InteropServices.ComInterfaceType
  System.Runtime.InteropServices.DispIdAttribute
  System.Runtime.InteropServices.InterfaceTypeAttribute
  System.Runtime.InteropServices.SafeHandle
  System.Runtime.Serialization.OnDeserializedAttribute
  System.Runtime.Serialization.OnDeserializingAttribute
  System.Runtime.Serialization.OnSerializedAttribute
  System.Runtime.Serialization.OnSerializingAttribute
  System.Runtime.Serialization.StreamingContext
  System.Runtime.Serialization.StreamingContextStates
  System.Runtime.Versioning.TargetFrameworkAttribute
  System.RuntimeArgumentHandle
  System.Security.Permissions.CodeAccessSecurityAttribute
  System.Security.Permissions.SecurityAttribute
  System.Security.Permissions.SecurityPermissionAttribute
  System.Security.Permissions.SecurityPermissionFlag
  System.Security.Principal.IIdentity
  System.Security.Principal.IPrincipal
  System.Security.SecurityCriticalAttribute
  System.Security.SecuritySafeCriticalAttribute
  System.Security.SecurityState
  System.Security.SecurityTransparentAttribute
  System.Security.UnverifiableCodeAttribute
  System.ServiceModel.XmlSerializerFormatAttribute
  System.StringSplitOptions
  System.Text.DecoderFallbackException
  System.Text.EncoderFallbackException
  System.Threading.IOCompletionCallback
  System.Threading.NativeOverlapped
  System.Threading.Overlapped
  System.Threading.ParameterizedThreadStart
  System.Threading.RegisteredWaitHandle
  System.Threading.SendOrPostCallback
  System.Threading.SynchronizationContext
  System.Threading.SynchronizationLockException
  System.Threading.ThreadStartException
  System.Threading.ThreadState
  System.Threading.WaitOrTimerCallback
  System.ThreadStaticAttribute
  System.TimeZoneInfo
  System.TypeInitializationException
  System.UriBuilder
  System.UriIdnScope
  System.UriParser
  System.UriTypeConverter
  System.Xml.DtdProcessing
  System.Xml.Linq.ReaderOptions
  System.Xml.NamespaceHandling
  System.Xml.Serialization.XmlMappingAccess

Notables?

A number of deprecated collections are no longer available, the classic “ArrayList” from C# 1.0 among several others. Most of these would cause big performance problems with the Xbox garbage collector, so makes total sense that they have been trimmed out.

Additions which piqued my interest included “DebuggerDisplayAttribute”, and “StackTrace”/ “StackFrame”. The former I have a vague recollection trying to use before, it helps nicely format how a type is viewed in the Debugger. You can achieve the same functionality with ToString(), but if you need to use ToString() for runtime purposes and want something different shown in the debugger, it’s useful. “StackTrace” I was interested in because I believe the crash handler I’d written had a slightly different pathway between 360 and Windows. For 360 I had to throw an exception, and handle it. In the exception handling code I could pull out the callstack. With the StackTrace class you can just grab the callstack right off in the crash handler.

“System.Threading.ThreadState” too, I think I’d had to do a different workaround for the Xbox in the past. Nice to see that it’s now available.

Strangely I noticed “System.LocalDataStoreSlot” is not included in my removal list. Not sure why this is the case. Maybe I missed some key parameter in ‘ildasm’?

The Zune, or Windows 7 Phone?

Sorry, but I haven’t been developing for those platforms. Given some comments about the v4.0 release wanting to ‘standardize’ the Compact Framework to some kind of “Silverlight” API-set, I’d imagine the ones I’ve mentioned were added will probably exist for these platforms too. No idea though whether all the removed types I list apply to the Zune, many may not have even existed in the first place.

Er… So yeah, this is just covering the Xbox. Your mileage may vary with the other platforms.

Edit: Ah, Zune isn’t even supported by XNA 4.0!

References

• MSDN: Differences Between the .NET Compact Framework and the .NET Framework
• MSDN: Namespaces, Types, and Members in the .NET Compact Framework for Xbox 360
• Forums: XNA 4.0 RTM – Xbox Project – Serializable doesnt work
• Forums: XNA 4.0 .Net reference version for XBox
• Forums: Thread.Priority property deprecated on 360/XNA 4.0?
• Shawn’s Blog: Breaking changes in XNA Game Studio 4.0

A few weeks ago I mentioned on twitter that I was working on an Amstrad CPC emulator, written in XNA. There are plenty of the things for the PC and various other consoles, but not one for the Xbox 360 yet. So it seemed a cool little exercise to undertake.

A long time ago, I wrote one of my own for the PC. The website I setup for it is still live, here. I developed it initially around 1997. Back then I’d pretty much just gotten it to be able to boot, and be able to type things on the keyboard. I revisited it a few years later when I needed something flashy for my portfolio, around the time I was trying to break into the games industry. With that version I managed to get a handful of games running nicely.

Little bit of history

I used to be really into the emulation scene back in the day. The first one I stumbled upon was on a BBS, some random BBS I found in the pages of Computer Shopper (wow, that mag is still going!). My father used to go to his work to wash his car on the odd weekend here and there. I used to use his Apple Mac computer when he was doing that, was one of the old Mac Quadras. This would have been around 1993 I think, so I’d have been a spritely twelve or thirteen years old at the time!

Anyhow, I’d use some terminal software on the Mac, downloading various interesting programming bits and bobs via the trusty ZMODEM protocol. One weekend I was stunned to see something called CPCEMU. This was the first Amstrad emulator ever to see the light of day. I didn’t even know such a thing was possible at the time; I’d pretty much figured that it could well be a joke download. So after copying my weekend’s haul to a floppy as per-usual, I was excited to give it a try.

This software and much of the rest of the stuff I downloaded was PC-only. I didn’t have a PC at home at the time; I’d just use the ones at my school during lunchtimes. It was really cool to see the emulator fire up on that PC at school. Unfortunately though the Amstrad ROM wasn’t included in the package, so all that worked out of the box was a single sample game written to interface directly with the hardware. That year I remember my ‘big’ Christmas present was a 3.5” disc drive for the Amstrad, primarily so I could dump the ROMs from the machine so I could get the emulator working! What a nerd.

Around the time I’d also written in to the only remaining Amstrad CPC magazine in production: Amstrad Action. They had some feature where they asked readers to write in with any sort of Amstrad-related article, and they’d print them up in some sort of ‘readers articles’ feature. This never actually happened though unfortunately; they never did run any reader articles. I’d written one in about CPCEMU, whilst it never appeared I did get a mention in the magazine. After a little googling, I managed to find it:

Amstrad Action – #104 – May 1994 (click for larger image)

Brought a smile to my face seeing it after all these years!

Other emulators

There were a number of other emulators I ‘followed’ back in the day too. GenEm; the first SEGA Genesis / Megadrive emulator out there, was one in particular. Was really something to see it improve over time. From humble beginnings where only a handful of early-era games are only playable. Through to audio emulation working (the Genesis/MD has a second processor; a Z80 funnily enough, which is primarily used for audio in games). Around this time was an explosion in emulators in general, for all sorts of other videogame systems of similar eras. There was a bit of a race between coders to get their emulator to be the most fully featured, with the highest game-compatibility rate. Competition drives technology, I guess?

Some other ones I remember too were KGEN and DGEN. But the real leap at the time I recall was Genecyst. It was really leaps and bounds above the other ones out at the time. The same guy (or group) that coded it also wrote the impressive Callus, and NESticle. Both landmarks at the time, particularly Callus which I think was the first Capcom arcade emulator that ran at a playable speed.

The UI for Genecyst, all emulators for the era were in DOS. Unlike most, this one had a GUI too

I also remember Executor well too, an Apple Mac emulator. This one took an interesting approach of not making use of any System ROMs at all. They essentially reverse-engineered the Mac. The emulation effectively emulated the services/OS calls that the system ROM would have provided. This I think was more of a legal choice than a practical one, but it must have been an interesting technical challenge. They updated it pretty often, it seemed like every week there was a new one to try that had a new slate of improvements. Unfortunately it was a paid-for emulator. I think it had a time restriction on it, it worked for ten minutes and then quit out. That was a rarity back then in the emulator scene.

Screenshot of Executor in action

As I was looking for stuff for this article, I was surprised to see that it’s now open-source. I think now there’s probably several other Mac emulators which take the more traditional approach, and have a near 100% compatibility with a real 68k-era Mac. I wonder how well it sold throughout its lifetime?

An XNA CPC Emulator

Christ; I do go on like an old woman, don’t I?

The point of this article was meant to be about the Xbox 360 version of the emulator I’m working on. I did most of the work for it over a weekend, about a month ago. The missus was away for work, and I had a nice block of time to tackle it. I essentially just used my previous emulator I wrote a few years prior, in plain C. I rewrote it in C#, in a much more OO-way.

It was as a pretty straightforward process. As I’d done with my older emulator, I took the Z80 CPU emulation from an existing source. Someone has already coded a ZX Spectrum emulator in C#, so I took the CPU code from there. The Zx360 project. I had to make a few modifications though. One was based on how memory is accessed on the CPC, to handle the ROM and RAM banking. The other was for the way interrupts are handled. I know very little about the Spectrum, but it seems like they do behave pretty differently in that regard.

So, dusting off the cobwebby corners of my mind, I got to implementing all the various bits of hardware of the machine. Using both my old source, and the Unofficial Amstrad WWW Resource for reference. The code quality was like night and day compared to my old plain-C implementation. That’s I guess what thirteen years experience will help you out a bit with! It a joy to debug too; all the little components of the machine browsable in the Visual Studio debugger, in a nice OO-d tree!

I worked on the actual XNA-specific parts last. Getting the screen drawn, and getting input working that is. It’s just as cool as I remember when you get that startup screen rendering the very first time. This old thing:

XNACPC bootup, the Amstrad CPC 464 startup screen

I then went on to get snapshot (.SNA) support working so I could load up memory snapshots of games. That was awesome to see as well. It had the exact same level of compatibility as my older emulator. I was a little worried the new Z80 core code could have some bugs or issues, but it seems solid now. So anyway, the same games that ran fine worked fine on this too. But of course the same ones with issues, also had issues on my new emulator too. Once I’d played a few games on the Xbox itself, I took a break from the project for a while.

The classic ‘Roland in Time’ running on XNACPC, on an Xbox 360

A bit later on

What I really wanted to add was proper audio support. I dabbled for a while using XACT; playing a sound and messing with the pitch and volume of it. But it had pretty hideous results. It was encouraging to hear the tunes in there somewhere, but it really didn’t work well at all. What led me to stop bothering with this method was news that XNA 4.0 has nicer audio support. Specifically the class DynamicSoundEffectInstance. This class allows playback of raw audio data, not just samples. Exactly what an emulator needs.

The other avenue I wanted to make improvements on was to how I emulate the video hardware. My older emulator took a very naïve approach. It didn’t make any effort to emulate vsync, hsync or tie in the CPU interrupts with any of it. Over the past few weeks I’ve had some time here and there to mess with this stuff, and attempt to get something better working. I’m pretty pleased with the results. I managed to get split-screen working. Which means ‘Sorcery’, one of the classic CPC titles is now fully playable and looks just like the original.

Sorcery on XNACPC – A CRTC-splitscreen game

I’ve still a way to go though. My CRTC and video emulation isn’t quite up to par with some of the more accomplished emulators already out on PC. Well, that’s an understatement; it’s truly awful compared to most of those emulators! But it’s something I can improve at my leisure.

I plan to release the source code for the emulator, specifically once I’ve got my video code a little more stable. Whether that’s a matter of weeks or months, I don’t know. I’m pretty busy at the moment with work, so it may take a fair while. I’d probably expect it to be after XNA 4.0 is released too, since I’d probably get some crude level of audio support in once it’s out. I’d dabble with the CTP version that’s out now, but I’m really targeting Xbox which is not supported just yet. Yes, I could write the code on PC. But I really like firing up the emulator on the Xbox, and seeing the cool stuff running on there first. I can be patient…

I’ve still a few more XNA articles I’ve been planning to write. The next one was to involve some threading code, and in the process of creating the article I hit upon something that I found concerning.

The title of this article pretty much gives it away before I can casually introduce it; the property method Thread.CurrentThread is slow on the Xbox. Specifically it’s slow compared to running the same code on a Windows PC. I’d imagine the same applies to the other Compact Framework platforms too; the Zune and Windows 7 Phones. But I can’t say for sure.

Bone-headed code

I stumbled upon this whilst trying to profile some of my code for a future threading article. I had two different techniques I was comparing, and I couldn’t for the life of me understand why one was an order of magnitude slower than the other. It just didn’t make any sense.

What I’d done in one of them was to assume that Thread.CurrentThread is cheap, and simply returns some kind of easy to grab variable. This isn’t the case. I can illustrate by showing you the exact piece of code that was slow:

for ( int i = 0; i < MAX_THREADS; i++ )
{
    if ( m_data[i].m_thread_id == Thread.CurrentThread )
    {
        return m_data[i].m_data;
    }
}

Then I changed my slower technique to ‘match’ the faster one, by prefetching the current thread:

Thread thread_id = Thread.CurrentThread;
for ( int i = 0; i < MAX_THREADS; i++ )
{
    if ( m_data[i].m_thread_id == thread_id )
    {
        return m_data[i].m_data;
    }
}

Yes, seems a no-brainer doesn’t it? In most cases it does make sense to prefetch variables like that, but I’d been a little silly and assumed there would be negligible difference from not doing so. I’d had some harebrained ideal that the optimizing compiler and the JIT-er would effectively make these two bits of code the same. On my Windows PC build they actually do execute in almost the same amount of time, certainly not different to the same degree as on Xbox.

It makes total sense that it doesn’t get optimized on either platform though. If you look at Thread.CurrentThread in the .NET Reflector, it calls an external DLL function. The compiler (or JIT-er) can’t be expected to think that the return value of that function will be the same for each iteration of the loop.

So, how slow is it?

My first port of call after I realized the big timesink, was to directly compare the performance between the Windows PC build and the Xbox 360 build. My test code was as follows, a loop accessing Thread.CurrentThread a million times:

Thread thread = null;
for ( int i = 0; i < 1000000; i++ )
{
    thread = Thread.CurrentThread;
}

Here’s how long it took on each platform:

Calling Thread.CurrentThread on the Xbox 360 is over five hundred (500!) times slower than on PC. That’s not good! The PC I’m using is nothing special, it’s a three year old Core Duo ‘1’ laptop. So I’m not running some ridiculous PC rig to see these large differences in speeds.

For the code I was working on, I modified it to call Thread.CurrentThread once at the start of my worker thread. I then pass this Thread object through to the other methods that I used, which are called often within that worker thread. So where these methods used to call CurrentThread multiple times themselves before, they no longer needed to. The Thread object for this worker thread was simply passed around instead. The code doesn’t look quite as nice of course, but it’s hardly a disaster.

The particular test I was doing with that worker thread code ran over one hundred times faster with that change made. This was still a bit of a micro-benchmark though, calling some small pieces of code a ridiculous number of times… Regardless, I was just trying to battle-test something that I’d want to use in practice. Using Thread.CurrentThread was an integral part of that.

What I ended up doing was having the facility to optionally pass in a Thread object if the user has one. If they didn’t, it would end up resorting to the slow Thread.CurrentThread instead. This seemed like an ideal solution.

CurrentThreadLite

When looking at the CurrentThread property accessor in .NET Reflector, I traced through to the DLL function which is ultimately called:

public static Thread CurrentThread
{
    get
    {
        return PAL.Threading_Thread_CurrentThread();
    }
}
 
[DllImport("mscoree", EntryPoint="#210")]
public static extern Thread Threading_Thread_CurrentThread();

Listed alongside this particular function was this other similarly-named one; CurrentThreadLite:

[DllImport("mscoree", EntryPoint="#211")]
public static extern IntPtr Threading_Thread_CurrentThreadLite();

That’s interesting. It returns a different type, an integer pointer a opposed to a Thread object. But for my purposes I just wanted to uniquely identify a thread. If it’s faster, then it’s ideal for what I need. The suffix ‘lite’ sounds promising!

I tried to see what .NET code actually uses it, it’s these methods:

At least within the .NET executable that I was inspecting. There are probably other .NET library methods that make use of it. I’m not too experienced with the reflector, so I’m totally unsure of a good way of finding them.

Lite execution

So I was curious about whether this ‘lite’ version was faster than the ‘full’ version on Xbox 360. A google search yielded an extremely small number of results for CurrentThreadLite, and variations of it. I figured as part of this small article I may as well have a little go at seeing if it does perform better. It may help someone else out in future who stumbles upon this page.

The main problem though is that there’s no direct accessor to it. Nothing at all. The StringBuilder object makes use of it to maintain thread-safety on its mutable strings, which I’ve touched on in previous articles. Using the same method I described in this article, I can grab the private member that stores the ‘IntPtr’ thread.

This does mean that I’ll be adding the overhead of both reflection, and likely some allocations within StringBuilder too. Given the limited set of methods I have to play with, I doubt I’ll end up with anything workable within a game. This really is purely a bit of an educational investigation now, unfortunately there’s not going to be anything that I’d consider usable.

A crude performance test

I picked out one StringBuilder method which calls CurrentThreadLite: Append(String). You can see the source to this method here:

http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Text/StringBuilder/

The .NET library code though calls a method with a different name than the reflector tells us. The prototype of which is:

[MethodImplAttribute(MethodImplOptions.InternalCall)]
static internal extern IntPtr InternalGetCurrentThread();

I think I can safely assume this just calls through to CurrentThreadLite.

Anyway, if I pass ‘String.Empty’ as a parameter to Append() it’ll end up doing very little work. But CurrentThreadLite will be ran though, so it’d be a good indicator as to whether it’s faster to execute than the ‘full’ one.

Here’s the code I’m testing with, same one million-times loop as before:

StringBuilder string_builder = new StringBuilder();
for ( int i = 0; i < 1000000; i++ )
{
    string_builder.Append( String.Empty );
}

Here’s the results:

So it’s over ten times faster than the ‘full’ CurrentThread property accessor, the one I tested further up this article. That’s pretty cool! It makes sense that StringBuilder would use this over CurrentThread, if it were available. If they didn’t, any mutable change to a string would be ten times slower than it is now. That said, it still lags a lot behind PC; being around fifty times slower than that platform.

To reiterate though; unfortunately there’s no exposed direct access to CurrentThreadLite. As far as I can tell there’s no workable way of making use of it. I’d love someone to tell me otherwise though, it’d be awesome if I could use it.

StringBuilder though is still pretty slow on Xbox 360

In a previous article, I profiled some string manipulation code I’d written. Even though I was implementing alternate methods to what StringBuilder provides, in the end I still called their Append(). So I’d be incurring the hit from calling CurrentThreadLite too. It probably explains why the Xbox was running over ten times slower than PC.

I wonder if I can use reflection to grab the raw char[] data, and the string length. Then as long as I keep my code thread-safe by other means, I could work directly on the char[] buffer and concatenate strings myself. This would effectively do away with the overhead of checking what the current thread is, which is within all the existing StringBuilder mutable methods. Even though CurrentThreadLite is seemingly no slouch, it’s still not exactly cheap.

Something to think about… If it brings performance of StringBuilder in line with PC, then it certainly seems worth it. Whether it’s worth it for an XNA game though is arguable. Still, I found it interesting looking into this corner of C#.

References

• http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Threading/Thread/
• http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Text/StringBuilder/
• http://msdn.microsoft.com/en-us/library/system.threading.thread.currentthread.aspx

So, another entry in this StringBuilder and garbage series… This time I’m exploring the Format() method, and implementing a new alternative that does not generate any garbage. The existing AppendFormat() method on StringBuilder generates a significant amount of garbage.

So in what way does the .NET one generate garbage? Well, the parameter type is ‘object’, so you’ll get boxing and unboxing of value types. Since integers and floats are pretty oft-used with Format(), that’s not good news. With CLRProfiler I also see temporary allocations made in ‘String::ToCharArray()’, and ‘String::CtorCharArrayStartLength()’. There’s also more garbage if you use more than three arguments; for that it requires a temporary array to be created.

All in all, it’s not a pretty picture if you want to avoid garbage collections in your game.

Variable arguments

The AppendFormat() method takes a string parameter, then a series of parameter arguments. The amount of these can vary, and they can be of a different types too. So how best pass these in? Well, there are a number of different methods. Take a look at the ones StringBuilder provides as standard:

• StringBuilder AppendFormat( string format, params object[] args );
• StringBuilder AppendFormat( IFormatProvider provider, string format, params object[] args );
• StringBuilder AppendFormat( string format, object arg0 );
• StringBuilder AppendFormat( string format, object arg0, object arg1 );
• StringBuilder AppendFormat( string format, object arg0, object arg1, object arg2 );

Each of these uses object params. Object params are subject to boxing and unboxing with value types. Since I’d want to pass integers and floats through, this isn’t good. The other thing I noticed was that array parameters using the ‘params’ keyword cause a temporary allocation too. Even without using the object type, take this simplified example:

public void TestMethod( params int[] args );

Any call to this method generates garbage. The ‘params’ keyword essentially converts any params you might specify into an array. The array of integers in this case is allocated as a temporary and then destroyed. The same thing happens when using class types too, not just value types. A different tact is required here.

There were two approaches I explored to support a variable set of arguments, without generating garbage. One of these I went with and will explain now, the other one I explain later on this article in the ‘Things to try’ section. The approach I chose uses generics, and unfortunately a method is required to be implemented for each number of parameters I’d want to support. Other than that though, it’s a really good fit for this problem.

The implementation

So, there are two main problems to solve here:

• Support a variable number of arguments of arbitrary types
• Be able to use these types, perform any conversion required and concatenate them onto a StringBuilder

For the former, I’m just using generics. For each number of parameters I need to support, I’ll need to write a new method. This multiple versions of the same method, but with a different number of parameters isn’t too pretty. It reminds me of C++ template abuse, stuff like the sig_slot library.

But here it gets the job done, and it’s kind of your classic C# stuff in a way. There’s no support for default parameters in C#. So for different arguments you generally have to have wrapper methods to support different sets of parameters.

Casting generics is not like C++. My first thought was something like:

static public void FormatArgument( StringBuilder string_builder, T arg )
{
    if ( arg.GetType() == typeof(int) )
    {
        int int_arg = (int)arg;
        string_builder.Concat( int_arg );
    }
}

But the straight casting like this is not allowed. There does seem to be a couple of methods to convert types though. At least these were the two I found, both these examples are with integers:

• Convert.ToInt32( arg )
• Arg.ToInt32( System.Globalization.NumberFormatInfo.CurrentInfo )

Both have their downfalls. Convert.ToInt32() generates garbage, which makes it unusable for my purpose. The latter one though doesn’t generate garbage, but it is only available on types that implement IConvertible. Fortunately all the types I wanted to use (string, int, float) all implement IConvertible. However some other types that would be nice to support, such as Math.Vector don’t. I went with this method, and in turn had to limit the arguments to IConvertibles using the ‘where’ keyword.

That’s about it for the nitty-gritty on some of my decisions. The rest of the code is just a classic char-by-char over the formatted string. It’ll look for the ‘{‘ open curly bracket character and then use the Concat() methods from my previous article to push in the parameters. So, here’s the code:

StringBuilderExtFormat.zip

Performance

I was definitely curious as to how my code performs. There’s certainly more scope for optimization, but I’m not keen on spending time on it unless it’s something to worry about. Using the Stopwatch class I measured the runtime of this piece of code:

string_builder.ConcatFormat(
    "Test {0:0.0000} Test {1:X} Test {2} {3}",
    3.45111111f, 0xBEEF, 12345678, "Hello World" );

A nice taxing formatted string with varied parameters. Here’s a table of the performance figures, they are measured from a loop calling this method 1,000,000 times.

 
For both times and garbage, smaller is better!

The notable thing is that the native AppendFormat() performs the same when optimized or not. I’m not entirely familiar with the in’s and out’s of .NET assemblies just yet. But I do wonder if I could put these routines in a separate library. Then whether I can set things up so that they are jit-ed, regardless of whether my main code module is ran in the debugger or not. Not something I’m too interested in right now, but just throwing it out there. I’m sure google is my friend on this one!

Anyhow, I’m happy that on the final build of the game I’ll have better performance than the stock .NET method. Also with significantly less garbage of course. There’s plenty of scope for optimization on my methods too, they’re pretty much a naïve first-go in all cases. With a little time and effort I think a good chunk could come off these times. Knowing it performs well though is good enough for me right now, I’ll give it more attention down the road if I need to.

Things to try

A Format() that does everything?

Obviously the version I’ve written doesn’t offer anywhere near the same fully-featured functionality as the stock .NET Format(). I don’t envision myself needing any more features for a game though to be honest. If I did come across something I wanted it wouldn’t be too much of a pain to implement I’m sure. But, take a look at the .NET docs, and the AppendFormat() source code:

http://labs.developerfusion.co.uk/SourceViewer/view/SSCLI/System.Text/StringBuilder/

The AppendFormat() in StringBuilder is the one that is also used by System.String and I’d assume the rest of the .NET code. Using this source and any documentation for the formatting specifiers, it’d be possible to implement the same level of functionality but using my techniques to avoid garbage. Quite a task though I’d think!
 

Supporting arbitrary parameter types

Another thing to give a go, is a second method of variable arguments I played around with. A method that doesn’t use generics, but instead uses a base class. For an example, here’s a method prototype with two arguments:

public static StringBuilder ConcatFormat( this StringBuilder string_builder,
    String format_string, FormatArgument arg1, FormatArgument arg2 )

The ‘FormatArgument’ class is an abstract base class. What you’d do is implement subclasses for each supported type, i.e.:

public class FormatArgumentInt : FormatArgument

Then have a virtual method for appending the type into the StringBuilder. The crux of this whole technique is in the use of implicit constructors. So that depending on the argument you specify to ConcatFormat(), you’ll get it converted into a new FormatArgument type. Here’s an example:

public static implicit operator FormatArgument( int value )
{
    FormatArgumentInt arg = new FormatArgumentInt( value );
    return arg;
}

Hey, this example allocates a temporary class therefore generates garbage when used? Indeed it does, but you can use a pool container to deal with this. Pre-allocating all of these and dealing out pool items when they’re created solves the garbage issue. You’ll also need to manually dispose of them and add them back to the pool.

It’s a lot of work. The big upside is that you can support any types, such as Math.Matrix and Vector. It’d be cool to be able to use those if you’re using Format() for debugging. In my experiments though, performance wasn’t too hot, it was in the region of 1.5-2 times slower than the generics method I detailed earlier. The code also becomes a lot more unwieldy; the generics method looked like a work of art by comparison!

Maybe there’s a way of using the generics method on arbitrary non-IConvertible types? Without incurring garbage on the conversions too of course.
 

Printf

I like the positional arguments of C#’s Format. C/C++’s printf() stipulates that the argument list has to be used in the same order that the params are specified in the formatting string. This makes the .NET way useful for localizations particularly, where something like:

Player {0} got {1} points!

Could become:

Allez {1} punts spiele {0}!  << Just a made-up foreign language

Essentially the translation requires those parameters to appear in a different order. With printf() it’s painful to do this correctly.

That said though if you’ve used printf() for over a decade like I have, switching to Format() might not be quite as fun. So why not implement printf() in C#? It’s really only a minor modification over the code I provide above. I was a little tempted myself, but I really want to stick with doing things the C# way for now.

References

• http://msdn.microsoft.com/en-us/library/system.iconvertible.aspx
• http://msdn.microsoft.com/en-us/library/system.convert%28VS.71%29.aspx
• http://blog.stevex.net/string-formatting-in-csharp/
• http://www.codeproject.com/KB/cs/Csharp_implicit_operator.aspx

In my previous coding post, I spoke about some issues with converting a mutable StringBuilder string back to a regular ‘string’ object without generating garbage. Well, specifically without requiring an unnecessary heap allocation. One thing I hinted at was that StringBuilder has a number of other methods which generate garbage too. In fact, there are a lot of important fundamental methods which do, which are difficult to live without.

As I’ve mentioned before, worrying about this sort of thing may not be necessary for the game you’re working on. It’s much more of a concern on Xbox 360 than PC, due to the poorly performing garbage collector on 360. If your game isn’t something that’s going to remotely push the hardware, or be impacted by dropped frames, then you really don’t need to worry. This article is just for those who may see this as an issue, and want to explore ways to eliminate this particular method of generating garbage.

Problem StringBuilder methods

So, here’s a table of all the methods StringBuilder has. My test case used a StringBuilder constructed with an initial capacity of 1024 characters. This is plenty for anything I threw at it, so any garbage I found with CLRProfiler was not something associated with reallocating the StringBuilder internal string. In the cases where there’s garbage generated I’ve commented with the most interesting or appropriate function in the callstack. In many cases it’s just exactly the same method, but with the function signature reported by CLRProfiler.

* Technically you could describe these as not generating garbage, simply allocating a new string for the client to use. Certainly for the latter of these it makes sense, the term garbage is a little incorrect. But for the former, hence my previous article, it’s unnecessary and can be avoided with a little work.

The common theme for garbage here is type-conversion. Anything that isn’t a string or char type is pretty much guaranteed to generate it.  ‘bool‘ is an oddball I think probably because it inserts string literals: ‘false’ and ‘true’, so no conversion is needed. The other peculiar one is the Insert( int, char ) one, it generates garbage when logically it doesn’t really need to. Oddly the .NET library source code says it calls Char.ToString() on the char parameter. Possibly just an oversight in the library?

The reasoning for the type conversions generating garbage, is that they return a temporary string converting that type to a string. This string is then fed into the StringBuilder, and then discarded. Whilst it could have been done in-place, I think the reason why it isn’t is to support CultureInfo modifiers on the conversion. Where that conversion could take place in a different way based on the passed in CultureInfo. StringBuilder internally uses CultureInfo.CurrentCulture.

I think the implementation chosen was for simplicity and clarity of the type conversions. Writing a system to perform these type conversions in-place and have the flexibility of what CultureInfo offers, would have likely made the code significantly more complex. I can understand their reasoning completely.

Appending numeric types without generating garbage

For this article I specifically wanted to detail a replacement for those type conversion methods. These are ones you’d definitely need for a game, for at least your HUD readouts. Since these could be updated every frame, using the garbage-churning .NET library methods isn’t going to be pretty.

The replacement methodology I used was pretty simple; a number of methods don’t generate garbage, so use those to build up the string. This effectively means implementing an itoa() in C#, a conversion of an integer into string form. Floating point numbers too being handled in much the same way. My implementation is via C#’s extension methods. So the new garbage-free versions of Append() can be called directly on a StringBuilder object, as if they came with the original framework.

Here’s the code for download:

StringBuilderExtNumeric.cs

Since Append() is already taken, I chose Concat() as my alternative. There’s additional functionality over what’s offered by default in StringBuilder, to aid formatting of text. For floats you’re able to specify the amount of decimal places. For all numeric types you can specify the amount of padding, and the padding character used (most likely zero or space). Lastly, integers can be output with a specific base value, so your code could output hex, binary and octal if so desired.

Here’s a short made-up example of it’s usage:

StringBuilder m_hud_health_string = new StringBuilder( 64, 64 );
StringBuilder m_hud_ammo_string = new StringBuilder( 64, 64 );
 
private void UpdateHUDStrings()
{
    // Note: It's sensible to create a wrapper for Concat( string ), which just calls
    // Append() to avoid mixing these method names. When JIT-ing, it would be inlined.
 
    m_hud_health_string.Length = 0;                    //< Clear the string
    m_hud_health_string.Concat( GetCurrentHealth());   //< This method returns an int
    m_hud_health_string.Append( " / " );
    m_hud_health_string.Concat( GetMaximumHealth());   //< This method returns an int
 
    m_hud_ammo_string.Length = 0;                      //< Clear the string
    m_hud_ammo_string.Concat( GetBulletsInAmmoClip()); //< This method returns an int
    m_hud_ammo_string.Append( " ( " );
    m_hud_ammo_string.Concat( GetNumAmmoClips());      //< This method returns an int
    m_hud_ammo_string.Append( " )" );
}

But, what about Format(), I hear you cry? It can sometimes be easier to format more complex strings, and can result in much cleaner code than multiple appends/concats. Well, I have a garbage-free one of those too. I’ll cover its implementation next time I write about C# here.

Some other things to try

The code I’ve written probably (definitely) could be optimized further. In case you need to do this, or if you’re just curious and want to play around, I’ve got a few ideas of things to try:

• Different code for the oft-used base ten. You’re now modulo-ing and dividing by a constant, and passing one less parameter around. You can also just add characters by using ( ‘0’ + value ), instead of using the static char array. The static char array is just used since the hex ‘A-F’ don’t follow ‘9’ in the ascii table.
• Try using a static char[] array to generate the string you’re about to append, and just call Append() once on the StringBuilder. StringBuilder keeps itself thread-safe and has other overhead on most of its members. So I think this would result in a speedup, by just making one mutable interaction with the StringBuilder.
  Keep in mind that you’ll want to make this array a [ThreadStatic] (thread-local store), so that you can use the code on multiple threads without issue.
• Take a look at these two websites for some more ideas:
  Coverage of some common C implementations, along with some performance comparisons.
  A bit of a different approach using C++, potentially may throw up something applicable to C#.

Another thing worth considering is to wrap up the StringBuilder into a new type. Maybe a struct is a good idea, to save making another heap allocation when creating them. The reasoning behind this is to hide away the garbage-generating methods. So all you’re exposing are the safe, garbage-free methods. It also saves you having to awkwardly come up with a different method name, such as ‘Concat()’, like I did. Another win for this methodology is that you could write operator overloads to support ‘+=’, to perform concatenations too.

References

• http://forums.xna.com/forums/p/16395/87923.aspx
• http://www.jb.man.ac.uk/~slowe/cpp/itoa.html

In my day job I’m a bit of a stickler with memory. I’m at times approaching borderline OCD I think with budgets and fragmentation. Having a good handle on memory usage on a game is very important; once you start pushing a console’s limits you can cause a lot of headaches down the road if you’re not mindful of things like memory budgets. Forgetting about fragmentation until it’s a big problem is also a bad idea. Once you’ve started bad practices like this on a game, they tend to snowball and you’re in for a hard uphill battle once they become a problem that needs fixing.

With working in C# and XNA now, the big enemy on the memory front isn’t really fragmentation or running out of available memory. The Xbox 360 has plenty of memory for any project I’d try and tackle myself; coder art for the win! The problem is one of performance, more specifically the lack of performance of the garbage collection system. Garbage collection on the 360 isn’t as full featured as on the full .NET Framework on Windows. It lacks the ‘generational’ model that the full Framework offers, meaning a full collection is performed whenever the system deems it necessary to do one.

Having random CPU spikes in your game is a nightmare. More so that in the case of garbage collection on 360 there’s little control other than being able to invoke a collection yourself manually. If you’re generating garbage at runtime during gameplay, you are going to see spikes in your frame times. With just a little garbage generated, and if your game isn’t CPU-bound, you may be able to get away with not giving this any attention. However given my nature with this sort of thing, I want to run a tight ship with this being a potential future headache if I don’t do so.

That said, I think for any sort of menu system I’d have, I’d probably be happy to let it generate garbage and then just call GC.Collect() when we go back to gameplay. Giving it a different treatment entirely to how I’d handle the regular runtime gameplay of the game. It’s all about where it’s important to concentrate efforts to avoid garbage.

Profiling

For profiling any garbage my game might generate I use CLRProfiler for Windows. It gives a nice in-depth analysis of memory usage, it’s pretty much invaluable for dealing with garbage collection problems. It’s almost worth keeping your game always running on a Windows target just so that you can make use of it!

On 360 I use the ‘Remote Performance Monitor’ that comes with the Game Studio SDK. It’s nowhere near as detailed, but it does give a good indication of the severity of any garbage collection issues with your game. Discussing how I use these tools is beyond the scope of this blog post, Google is your friend.

The String and StringBuilder problem

The StringBuilder class in C# is the preferred way of working with string manipulation if performance is important. You can avoid it entirely, but you’ll be very likely to end up generating garbage at runtime if you’re exclusively using the string type.

For example, avoid using the ‘+’ operator to concatenate strings. Strings in C# are immutable, meaning they cannot be modified. If you perform this kind of operation, your resultant string will be allocated on the heap. It’s very easy to generate lots of garbage with this sort of code. Something like this monstrosity, which could be run every frame:

string show_world_details = “[ FPS :” + GetFPS() + “ P1 Health:” + GetHealth() + “  ]”;

StringBuilder allows you to work with a mutable string. It provides functionality to concatenate other strings, and other types onto your mutable string. Many of the functions of StringBuilder are completely garbage-free. Many however are not. I’ve a future post in the works which will cover that particular problem in more detail. For now, concatenating other strings onto the StringBulder is garbage-free. So that’s the method I’ll stick to for the sake of this post.

What I wanted to discuss was the conversion of your built up StringBuilder to a string type. There are many functions within the .NET library which only take strings as parameters. Thankfully on the XNA side, the DrawString() rendering routines do take a StringBuilder argument natively. However other functions such as those that write debugging output to Visual Studio or the console, only take string parameters. So in walks StringBuilder.ToString()…

ToString() code

So does calling ToString() generate garbage? My first expectation was that of course it would, it’d just copy what the string is into a new immutable string object created on the heap. This however is not the case, or at least sometimes it isn’t the case. To avoid beating around the bush here I’ll show you the actual source code of the ToString() method:

public override String ToString() {
 
    String currentString =  m_StringValue;
    IntPtr currentThread = m_currentThread;
 
    if (currentThread != Thread.InternalGetCurrentThread()) {
 
        return String.InternalCopy(currentString);
 
    }
 
    if ((2 *  currentString.Length) < currentString.ArrayLength) {
 
        return String.InternalCopy(currentString);
 
    }
 
    currentString.ClearPostNullChar();
    m_currentThread = IntPtr.Zero;
 
    return  currentString;
}

Bit hairy, no? InternalCopy() is the function which will allocate a copy of the string on the heap and return it. The function can actually return the internal string without making any copies. Specifically the first time it’s called, and if the string makes use of at least 50% of the StringBuilder capacity. The ‘m_currentThread’ member being set to zero will effectively mean that the next time any sort of mutable operation is performed on the StringBuilder; be it clearing the string, or appending to it. The StringBuilder will allocate a new string on the heap. Each of the mutable methods of StringBuilder check the ‘m_currentThread’ and ensure that the StringBuilder owns the particular string. The way ToString() works, it’s effectively giving away ownership of that string and will start with a fresh one on the next mutable operation.

The reasoning behind this thread noting, as well as keeping the String returned by ToString() completely immutable, is to keep StringBuilder thread-safe. There’s comments within the code that detail the potential race condition that could occur, which I have omitted above. You can see them in full here.

The other reason for making the copy is in the case that the user is making inefficient use of memory. If we’re only using a tiny portion of the StringBuilder capacity, the .NET authors deemed that it’s more efficient to return a copy instead of making reference to the full big string.

If I want to re-use a StringBuilder object, say for some kind of readout I might want Visual Studio to display in the debugging output window. I’m out of luck garbage-wise. I may avoid generating a copy of the string the first time I call it, but if I’m reusing the StringBuilder, it’s going allocate a new string on the heap for me when I call the next mutable method on it.

The solution

What I wanted was direct access to the string that the StringBuilder works with. Doing this on Windows with ‘unsafe’ code is most likely straightforward, but I want to target 360 so that’s a non-starter. On the 360 you’re bound by the shackles of the Compact Framework, if it’s not in there, you can’t use it.

Thanks to this article though, I was able to track down a method to be able to access that internal string object which the StringBuilder works with. It’s effectively doing something the .NET library authors don’t want you to do, grabbing that private member (oo-er). Thankfully this also works on 360!

Here’s the code:

string my_string = (string)my_stringbuilder.GetType().GetField(
    "m_StringValue",
    System.Reflection.BindingFlags.NonPublic |
    System.Reflection.BindingFlags.Instance ).GetValue( my_stringbuilder );

Reflection isn’t too pretty, eh? But here it’s a nice devious means to an end. Reflection isn’t too hot performance-wise, so I’d recommend grabbing the internal string just the once for the StringBuilder you’ll be working with. Stash it away as a member of a class or something, and you’ll then have the string to pass along to whatever function you wish. Now we’re no longer worrying about the ToString() generating garbage for us; success!

Here’s a bit of sample code:

StringBuilder my_stringbuilder = new StringBuilder( 32, 32 );
string my_string = (string)my_stringbuilder.GetType().GetField(
	"m_StringValue", BindingFlags.NonPublic | BindingFlags.Instance )
	.GetValue( my_stringbuilder );
 
my_stringbuilder.Append( "This " );
my_stringbuilder.Append( "Is " );
my_stringbuilder.Append( "A " );
my_stringbuilder.Append( "Test!" );
 
// my string will be "This Is A Test!"
Console.Write( my_string );
 
// This second append would have resulted in a new heap allocation
// if I'd used ToString() above.
my_stringbuilder.Append( " Yay!" );
Console.Write( my_string );

I’d advise creating your StringBuilder objects with the two integer parameters contructor. As well as preallocating the string, you’ll also be putting a cap on the capacity:

// Creates an empty StringBuilder with a minimum capacity of capacity
// and a maximum capacity of maxCapacity.
public StringBuilder(int capacity, int maxCapacity)

Meaning it’ll never grow in size, or make any more heap allocations after it’s initially constructed. If that were to happen, the string object you grabbed is no longer linked to the StringBuilder. You’d need to redo the reflection call to grab the new string that the StringBuilder owns.

So by using that constructor, this means if you grab the internal string you’re guaranteed to keep the reference to the StringBuilder’s mutable string forever. The one key exception here though is if you work with the StringBuilder on another thread. In that case, you’ll be subject to the same issues as before.

I’ll revisit StringBuilder here again in future, to cover some of it’s other shortcomings with regard to generating garbage.

References

• http://www.codeproject.com/KB/dotnet/strings.aspx
• http://blogs.msdn.com/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx
• http://blogs.msdn.com/netcfteam/archive/2006/12/22/managed-code-performance-on-xbox-360-for-xna-part-2-gc-and-tools.aspx
• http://blogs.msdn.com/stevenpr/archive/2004/07/26/197254.aspx

See this blog post for more information about the state of play under XNA 4.0.