We’ve seen how to create powerful, Burst-compatible generic algorithms already, but today we’ll take another approach to generic algorithms and implement them in the style of C#’s LINQ. Along the way, we’ll tackle a new challenge by implementing a generic algorithm that allocates a new collection.
Posts Tagged burst
We looked at some generic algorithm examples in the previous article, but they weren’t very generic in one respect: they all required a NativeArray<T>. What if we wanted to make them more generic so they could work on any type of collection? Today’s article shows two ways to do just that!
Burst 1.2 comes with a new feature: SharedStatic<T>. This allows us to write to static variables from within Burst-compiled code like jobs and function pointers. Today we’ll look at how this is implemented by Burst and IL2CPP. We’ll also put them to a performance test to see how fast they are.
Function pointers aren’t the only way to express a unit of work. Unity’s own job system does just this, albeit in a different way. Today we’ll compare the performance of Burst’s function pointers against jobs themselves!
A couple weeks ago we took a look at the performance of function pointers in Burst. In doing so, we left out an alternative: good old switch statements. Today we’ll put those to the test to see how they stack up next to Burst’s newfangled function pointers!
Now that we’ve seen how function pointers work and perform in Burst, let’s use them to build a higher-level feature: virtual functions!
Last week we took a look at function pointers in Burst 1.2 and Unity 2019.3. Today we’ll continue looking into them by analyzing their performance.
Unity 2019.3 and Burst 1.2 bring us support for function pointers! Behind the scenes, these power everyday C# functionality like virtual and abstract functions, delegates, and interfaces. Today we’ll look at how to use them and what Burst compiles them to.
IDisposable is becoming more and more prevalent in Unity. Previously, it was typically only used for I/O types like FileStream. Now it’s used for in-memory types like NativeArray<T> to avoid the garbage collector. Needing to call Dispose manually means we’re explicitly managing memory, just like we’d do in lower-level languages like C++. That comes with some challenges, especially with shared ownership, which we’ll deal with today.
Unity provides exactly one collection: NativeArray<T>. Compared to managed arrays in C#, these must be one-dimensional. So today we’re building a two-dimensional version of it: NativeArray<T>. We’ll add this to the NativeCollections GitHub repository for easy inclusion into any project. Read on to learn more about the collection!