.NET 4.0 and the Task Parallel Library (TPL)

I’ve been tasked with presenting a training session at work on the new concurrent programming features in the .NET Framework 4.0, so I’ve been playing around with a Mandelbrot set visualiser for which I have written three routines: a sequential routine, a (potentially) each line can be calculated in parallel, and a third where (potentially) each pixel can be calculated in parallel. I say “potentially” because the resource manager underneath the TPL actually manages the threading for you. In essence, when using a technique like Parallel.For you create a lambda function for the loop body, any single iteration of which could be executed in parallel to any other iteration of the loop body, and the TPL takes care of scheduling these iterations across some magically optimized number of threads.

My sequential code is a nested for loop where the out loop iterates y and the inner loop iterates x. In the Parallel.For version of the visualiser I replace the outer loop with a Parallel.For like so:

Parallel.For(0, parameters.imageHeight, y =>
{
    double c_im = parameters.maxIm - y * parameters.imFactor;
    for (uint x = 0; x < parameters.imageWidth; ++x)
    {
        mandelbrotPixel(bmd, (uint)y, c_im, x);
    }
});

What this means is that the TPL will try to run as many iterations of the body of the lambda function in parallel as is sensible.

So, onto the results. I ran the same program on my work machine (Core2 Duo, 4GB RAM, Vista 32) and my home machine (Core2 Quad, 2GB RAM, Windows 7 64), and got the following results:

Test        |     Time (work)        | Time (home)
-------------------------------------------
Sequential  | 9.480s                 | 9.373s
Parallel.For| 4.540s                 | 2.451s
Nested P.F  | 4.300s                 | 2.403s

As you can see, by simply running the code on a machine with two more cores, the runtime was halved.

In order to get the run-times large enough for changes in performance to be meaningful I made the application generate a 4096 by 4096 image.

Take a look at the source code here: ParallelProgramming.zip, it’s a Visual Studio 2010 solution, but the code is fairly straightforward.

.NET Class Wrapper coming along

I’ve been embedding mono into my game engine, and decided that what I needed was a code generator to generate C++ classes which wrap .NET classes that exist inside the sandboxed runtime.

I’ve decided on StringTemplate for the templating side of it, and after trying to write a template without first knowing what the class should actually look like, I set about writing an initial prototype of what I would like my generator to eventually produce. This went quite smoothly (if rather slowly), and eventually I found that my application, whilst calling all the .NET code I wanted it to, was crashing when trying to free some memory.

I eventually found that my problem was that I shouldn’t be calling free for a pointer that was allocated using g_malloc, because that’s just asking for trouble. However, g_free, just won’t compile (well, link actually), not in a million years, not in my code (but for some reason it does in libmono). However, the lovely people over at the mono-devel mailing list said I should use mono-free (which wasn’t in my library definition, causing me much angst). Eventually I edited mono.def, recompiled mono, and my code, and what do you know? It works.

Next stop, a code generator.

Progress with Mono!

So today I spent some time building embedded Mono into my game engine (if you can call it that, it’s pretty skeletal so far). It’s pretty poorly done at the moment (design-wise), but I can execute code from a .NET dll within my application. What I didn’t realise until just now, was that the mono runtime will happily load dll’s built with Microsoft’s compiler, which means I don’t even have to worry about needing a separate build environment for the C# code (although it’s pretty easy, just run xbuild on your project/solution from cygwin).

The next steps here will probably be along the lines of turning the runtime stuff into some sort of script host, and coming up with patterns for writing/generating bindings between the two environments. I think I’ll investigate SWIG for this. Binding C# code to C++ types will be fairly easy – the C++ type just needs to register all of its member functions with the runtime, and then a wrapper around these can be written in C# in much the same way as you would wrap any other C dll, using the extern keyword and the MethodImplAttribute. On the other hand, accessing C# types from within C++ requires a fair amount of code (somewhat like using reflection in C#), and so it will be necessary to use some sort of code generator to generate efficient wrappers.

Very Interesting.

Using XPath with a default namespace in .NET 2.0

I have recently been writing an assembly which facilitates automatic deployment of K2.Net 2003 workflows. The assembly reads in a configuration file and deploys the workflows as specified in the configuration file. Also, rather than writing any custom code to validate the XML, I decided to use an XML Schema Definition, mainly because it saves me time and typing, but also because it’s good practice.

Anyhow, in order to use the XSD, I had to give my schema a namespace, and because I didn’t want to have to add a whole bunch of prefixes to my configuration file, I decided to use the default namespace:

<configuration xmlns="http://temuri.org/configuration.xsd"></configuration>

This broke all my xpath queries because the .NET XPath query code does not seem to handle the default namespace. What I ended up doing to fix it was using an XmlNamespaceManager to create a fake namespace with the same URI as the default namespace, and then change all of my XPath queries to use the prefix for that fake namespace. Something like:

XmlDocument doc = new XmlDocument();
doc.Load("configuration.xml");
// To get the URI for the default namespace
string xmlns = doc.DocumentElement.GetAttribute("xmlns");
XmlNamespaceManager namespaceManager = new XmlNamespaceManager();
namespaceManager.AddNamespace( "a", xmlns );

// Now query with XPath
XmlNodeList nodes = doc.SelectNodes("/a:configuration/a:solution");

With a configuration file which looks something like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns="http://temupri.org/configuration.xsd" ... >
	<solution path="">
		<projects>
			<project name="Job Setup">
				<references>
					<reference name="" gac="false" fullname="" />
				</references>
				<processes>
					<process name="RequestLeave" />
					<process name="RequestSomethingElse" />
				</processes>
			</project>
		</projects>
	</solution>
</configuration>

The way I see it, it involves less typing than actually using a prefix. That said, given that it feels like a lazy way out, it probably isn’t the best practice because there is now a difference between my queries and my xml.

C# Developers: Comment your code!

I was just thinking how easy it is to tag all of your code with the essential metadata it needs:

  • What does it do?
  • What are the inputs?
  • What are the outputs?

Now we can, of course, put in plenty more metadata, such as general remarks, what exceptions are thrown, examples of how to use your code etc. What astonishes me is how much code I see which doesn’t even have the essentials listed above. If you’re using Visual Studio you really have no excuse all it takes is literally three /’s and visual studio will put in the skeleton for you.

You will all comment your code religiously from now on, and then you will use Sandcastle to generate a compiled help file from it.