This week, we will finally tackle the heart of the job system: the implementation of the lock-free work-stealing queue. Read on for a foray into low-level programming.
As promised in the last post, today we will be looking at how to get rid of new and delete when allocating jobs in our job system. Allocations can be dealt with in a much more efficient way, as long as we are willing to sacrifice some memory for that. The resulting performance improvement is huge, and certainly worth it..
Back in 2012, I wrote about the task scheduler implementation in Molecule. Three years have passed since then, and now it’s time to give the old system a long deserved lifting.
In order to gauge which topics you may find interesting, I’ve decided to do a quick poll to let you choose which topic you would like to hear more about.
Every now and then, I get asked about the current status of the Molecule Engine, whether there is an evaluation version to download, or if an Indie license can be acquired somehow. There are a few things that need to be said, because this is something that is very close to my heart.
I’m proud and excited to announce that both my proposals for Game Engine Gems 3 have been accepted! The book is due GDC 2016, so make sure to pick it up once it’s released.
Hopefully this will get me back into the habit of writing a bit more. I have plenty of new (and also old!) topics to write about, but I’m really lacking the time at the moment.
The last post of this series basically concluded with the following questions: how do we efficiently allocate memory for individual command packets in the case of multiple threads adding commands to the same bucket? How can we ensure good cache utilization throughout the whole process of storing and submitting command packets?
This is what we are going to tackle today. I want to show how bad allocation behavior for command packets can affect the performance of the whole multi-threaded rendering process, and what our alternatives are.