Writing multi-threaded code is one of the keys to maximizing performance. Currently, this means creating your own threads and synchronizing them with C# keywords like lock and volatile as well as .NET classes like [ThreadStatic] and Interlocked. Today we’ll take a look at how these are implemented behind the scenes by IL2CPP to get some understanding of what we’re really telling the computer to do when we use them.
Posts Tagged threading
The Unity API can mostly only be used from the main thread. This is used as an excuse by Unity developers to write all their code on the main thread. This makes their code run 2-6x slower. So what can we do about it? Today’s article presents a simple way to use the Unity API from other threads. Read on to learn how to unlock all that extra CPU power!
Last week’s article showed how to effectively use the CPU’s caches to boost performance by an order of magnitude. Today’s article goes even further to show you how to use even more of the CPU’s capabilities!
Coroutines are great for tasks that are easy to break up into little chunks, but we still need threads for long-running blocking calls. Today’s article shows how you can mix some threads into your coroutines to easily combine these two kinds of asynchronous processes.
Today’s article is the final installment in the series before we wrap things up next week. We’ll talk about C#’s built-in support for multi-threading and cover some odds and ends that were missed in the previous articles.
The last article gave a very basic example of the flash.concurrent.Condition class introduced in Flash Player 11.5. That example was (hopefully) a simple and easy way to understand the mechanics of how the Condition class works. Unfortunately, it was not a useful example and actually demonstrated the opposite of what you’d want to use it for. Today’s article shows a somewhat more complicated example that should serve as an example of appropriate usage for Condition.
The Condition class that debuted alongside the Mutex class in Flash Player 11.5 is very useful but much less understood. Unfortunately, Adobe’s documentation doesn’t include a usage example and there seem to be none available elsewhere on the internet. So today’s article provides an example of how to use the flash.concurrent.Condition class.
ActionScript workers allow you to take advantage of today’s multi-core processors by creating multiple threads of execution. These threads will invariably need to share some data between them. By default, all data passed between the workers/threads is copied, which can be really slow. The ByteArray class can be shared without copying. Today’s article discusses this and talks about some quirks that come along with it.
While ActionScript Workers made their debut in Flash Player 11.4, the Mutex class didn’t arrive until the next version: 11.5. This class is specifically designed to solve a subtle problem that cropped up in the last article. As you’ll see in this article, it does the job quite well! The result is even faster message passing between workers/threads, which is often key to efficiently using multiple core CPUs.
We know that sending messages between ActionScript workers is slow, but how can we make it faster? Today’s article discusses an alternative approach to message passing that yields a 2.5x speedup. Read on to learn about the approach and un-block your workers.