This post was published 2 years 6 months 26 days ago and as such probably does not reflect my current opinions, knowledge or ability.
I’ve made some progress in the past week with my honours projects, creating small experimental programs to familiarise myself with multi-threading in .NET. Thankfully so far I’ve found the syntax clear and consistent with the terms normally involved in parallel processing. Although this doesn’t simplify the task of designing the program it certainly avoids the implementation overhead which has been inherent in my attempts with multi-threading in C++.
The programs I’ve been working on are in C#, though I’d be interested to try other .NET languages. In each, I processed thousands of entities allowing each to rotate and bounce around a window. Different methods of splitting up and dealing with this work in parallel were experimented with.
Rendering, which was performed separately and was responsible for a fair amount of overhead, could be simplified or rearranged to increase overall frame processing time. However, as the graph below (from my first program created) shows there was a noticeable difference between using one and multiple threads. I’m using a dual core CPU on my laptop, and with the application limited to a single core the gain was far less significant; I hope to see whether using a quad core CPU would offer a further gain in the near future.
Although not shown, using 32, 64 or even 1024 threads caused far less of a performance hit that I had expected. The time spent creating the threads at the beginning of the program was notable, however, as was the increase in memory requirements.
