Random inspiration from Accelerated Massive Parallelism

For some reason I've started looking at the sample code for Microsoft's C++ AMP: Accelerated Massive Parallelism. The temptation to offload work onto the GPU has finally proved too much. Actually, I've looked at various ways to do that in the past, but then slowly walked away...

This time I got as far as calculating the Mandelbrot set by means of C++ AMP, but I won't bore you with that, and besides, Microsoft have provided their own sample code and it's probably better than my version. But when I looked that their code for calling C++ AMP from C# code I was reminded how simple it is to call C++ code from .Net, and I started to wonder why I don't do this more often - even without any Accelerated Massive Parallelism trickery. For example, say you're doing some repetitive calculations, why not do the maths in a small bit of C++ code and get a huge speed improvement? It's not that difficult to do a simple calculation in C++ and you don't need lots more code.

So I spent a lunchbreak writing a sample project to calculate the biggest distance found between an array of points (x,y coordinates). I implemented the same calculation in both C# and C++ and then ran it on an array of 10,000 random points. Using the C++ code, without any help from AMP, it was about ten times faster - even thought I was calling it from within my C# console app:

Wow. That's quite a big difference. Note: I'm computing the distance between every combination of two points in the array and returning the biggest distance found.

Now ... I may not be able to do this type of stuff during my day job, where everything needs to be done in C# only, but I think that I may be tempted to do this type of stuff in my own time when I'm just messing around.

Implementing Function Calls

I've been busy lately adding the concept of function calls to my H2D2 programming language. It hasn't been as hard as I thought, but there has been a reasonable amount of code to write. I have added the notion of scope as well, so that when a function returns, any local variables go out of scope and the H2D2 virtual machine can free the memory allocated to them. Currently, functions can return a value (although it's possible in H2D2 to return nothing from a function too) ... but I can't yet pass parameters to functions, that's on my TODO list, I'll work on that next.

So here is the current test program that I'm using to see if it all works:

test()
loop(s=48)
  print 10
  print 13
  print s
  print 32
  x=test()
repeat (s=s+1 if s<58)
print x
return

function test()
  loop (s=65)
    print s
  repeat (s=s+1 if s<91)
return 42

This program simply outputs some ASCII characters, the result comes out like this:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
0 ABCDEFGHIJKLMNOPQRSTUVWXYZ
1 ABCDEFGHIJKLMNOPQRSTUVWXYZ
2 ABCDEFGHIJKLMNOPQRSTUVWXYZ
3 ABCDEFGHIJKLMNOPQRSTUVWXYZ
4 ABCDEFGHIJKLMNOPQRSTUVWXYZ
5 ABCDEFGHIJKLMNOPQRSTUVWXYZ
6 ABCDEFGHIJKLMNOPQRSTUVWXYZ
7 ABCDEFGHIJKLMNOPQRSTUVWXYZ
8 ABCDEFGHIJKLMNOPQRSTUVWXYZ
9 ABCDEFGHIJKLMNOPQRSTUVWXYZ*

Simple stuff, but it demonstrates calling the "test()" function like a statement (ignoring the return value) and also assigns its return value to a variable too. I have also done some work allowing this type of code to be written out as labelled bracket notation. Essentially I'm treating each function like a seperate program, starting with its own root node, and then each call to that function simply points to the correct root node. This is how the above program looks if I render the labelled bracket notation generated from the bytecode:

Currently, when I parse the source code, I simply scan for function definitions and emit the code for them and then go back to a 'bootstrap' node which is the programs entry point. The starting point of the source code is pointed to from the 'bootstrap' node. It seems to work fine, and it means that programs always execute from node zero (which I'm making sure is always the bootstrap node).

In other news, I compiled H2D2 as a Windows dll, and used Interoperability to call it from C#, this worked a treat and was extremely fast. With the dll version, any output that the H2D2 program creates is returned as a pointer to a string, so after the program has been run the C# code needs to make an additional call the dll and tell it to free the string containing the output. But, my mandelbrot test program runs in about 200ms this way, since it doesn't have to muck about with writing to the screen. Once the C# program has all the output it can write it in one go rather than a character at a time, which is much quicker.

Now that I have installed Visual Studio 2012 I might be able to hide H2D2 behind a websocket interface. This should allow for a 'chatty' interface to H2D2 where you can ask it to run programs and get the results returned. This is also on my TODO list :-)