Two weeks ago we tested the performance of the async and await keywords plus the C# Task system against Unity’s new C# jobs system. This tested the usual combination of async and await with the Task system, but didn’t test the Task system directly against Unity’s C# jobs system. Today we’ll test that and, in so doing, see how to use the Task system without the async and await keywords.
Posts Tagged threading
Last week’s article tested the performance of the async and await keywords plus the C# Task system against Unity’s new C# jobs system. This week we’ll go in depth with async and await to learn how they work, how they relate to the Task system, and how we can customize them for our own uses.
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.
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.