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.
Whilst wandering round the Cambridge University bookshop
the other weekend, I noticed a book called Memory as a Programming Concept in C and C++. It was just too tempting, so I bought a copy.
Nobody has ever
taught me about memory management in C, I've worked this stuff out from experience and probably by reading
other peoples code. So it's nice to read a tutorial - even if I've already been doing this stuff for years.
If nothing else, it's made me think more carefully before I dynamically allocate some memory. And I thought
that I was pretty careful in the first place.
So I decided to write some debug code to test for memory leaks in my H2D2 virtual machine. I was pretty
confident I would not find any problems. But, I did actually find a calloc() where I had meant to put a realloc().
A silly mistake where I wasn't being careful enough. This was leaking memory, because I had a malloc() which
was being followed by a calloc() instead of realloc() - so the memory allocated in the first place was not
getting freed up (only the memory from the calloc() was getting freed up).
Here is an example of the debug code that I've written: view C code (as a text file).
You just need to replace your calls to malloc, calloc, realloc, and free with rmalloc, rcalloc, rrealloc, and rfree. As you can
see from the code, it simply maintains an array of pointers to dynamically allocated memory, so when your
code exits you can see if there are any 'dangling' pointers left over. Simple, but effective. If there are
no pointers left when your code finishes then you're probably not leaking memory. Nice.
Anyway, I'd be happy to recommend the book 'Memory as a Programming Concept in C and C++', I've found it a useful recap on many things and a good reminder
to be extra careful with dynamic memory. It's also been fun to write some memory debugging code, which is a tangent that I may not have gone down if I had not bought the book. Although this book was published 9 years ago, it's
nice to see a good book on C programming that's less than a decade old. Thanks Frantisek!