Is using Burst as simple as checking a box?

Sorry for all the questions but im looking for the "for dummies" answer, because its been on my radar for a few years and I just read the blog post about Burst but I don't really understand it.

Do I just install a Burst package and then click somewhere to compile with Burst instead of unity's built in compiler?

Or it looks like it doesnt support Classes? So most of my code which uses mono behaviour or when I make new classes, non of that would compile?

So it requires a new type of coding using only a subset of C#? And as long as you follow that you will have more optimized code that runs faster? And is this subset well known and popularly used by many coders?

Finally, if it doesn't support classes, aren't classes a fundamental part of most coding languages so isn't that a big deal id it doesn't support them?

 

Burst works on jobs https://docs.unity3d.com/Manual/JobSystem.html (or more advanced burst compiled function pointers)

And it does not work on managed objects (classes). This is usually the hardest thing for people to wrap their head around as it requires a different mindset to the more traditional OOP that people have been working with.

 

Here you can read through what is supported and why:
https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual/index.html

In a nutshell, no, classes aren't supported and classes aren't real from the standpoint of code execution on the CPU. Burst compiler is making your code more streamlined to SIMD (single instruction multiple data), which tightly connected how the CPU works and how the CPU fed with the code to run and the data run the code on.
Classes and reference types in general have nothing to do with SIMD since they involve random memory access.
You can read more on the link above. Some method calls are okay.

The subset you can use is widely used and used all the time. By everyone. And it is not new by any means. The trick is to form your code to use them as much as possible without using other things in the middle.
You can use classes (you have to, really) to fire up the Jobs you can vectorize though.

 

Thank you. I have to admit I'm shocked about the no classes. For the average designer who is not a hard coder this is a big deal, and I'm surprised it's not mentioned often and always In the more mainstream marketing posts. It's probably one of the first things I would mention and I think i understand the resistance to dots more now, because I think the vast majority of non hard coders is use to using classes to structure their work.

 

I can't find the name of this c# subset. Does anyone know what it's called?

 

it’s a very understandable reaction. But there are a few hard truths that most users here have internalized:

- OOP implies random memory access. By its nature, it’s unoptimized for CPUs and the way they cache data. Data-Oriented, ECS code involves mostly linear access of small blocks of memory, which means it can be highly optimized around CPU caching. For that reason, Data Oriented Design will always have a performance advantage over OOP at medium/high object counts. Often a massive one.

- Single core CPU speed increases y-o-y have plateaued. But y-o-y advancements in multi-core CPUs is steady. So for the foreseeable future, the future of performance gains means multithreaded code. And the more multithreaded code, the better - gameplay code included.

- Writing multithreaded, DOD code allows for some pretty amazing compiler optimizations, which is what lead to Burst. The speed increases can be so massive, that ultimately it’s been worth it to make the (occasionally confusing) transition to writing code this way.

Most people in these forums are on the other side of that transition, and believe me, it’s worth it. The only real downside the jumping in now is that it’s not ready for production use (missing features, api still evolving). Though that can also be a great time to learn about it, depending on your circumstances.

However, I should say that Burst *is* ready for production use. It’s mostly the ECS code that’s still in flux.

 

https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual/index.html

 

https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/

 

Burst is such a limited product it benefits nobody. except a small set of kids that make test projects for fun.
Meanwhile if you make an actual game with Monobehaviours, use the mathf and Vector3 stuff it doesn't inline in mono, nor il2cpp it doesen't use vector math and is basically the way most games are build. hilarious.
Oh.. and in mono all floats are treated as doubles and casted to and from doubles to floats all the time incurring heavy costs for no reason..

 

Can we not turn this into a DOTS hate thread?

The purpose of Burst is to target a specific subset of the codebase and with additional knowledge of aggressive assumptions it can make, compile the code way more optimally than any general-purpose compile can. It also provides tooling and resources to customize and tune this behavior and report when things don't go quite right.

 

Great article. I stand corrected - not all ECS code is faster than all OOP code. I would be curious to see an updated comparison with newer DOTS code, Jobs, and Burst, vs optimized OOD code + Jobs and Burst (being serious here - no sarcasm).

What I said is true: Linear access across a single cache line will always be faster than random access that requires fetching. It's the same as saying time-to-fetch > time-to-not-fetch.

In general, though, ECS really does have many performance, maintainability, and organizational advantages to DOD code. Come drink a little Kool-aid and find out.

 

Be careful. The article is misleading. What the guy is actually doing is building what I typically refer to as an Object-System architecture. I provide a little bit of insight about it and other architectectures here: https://forum.unity.com/threads/esc-api-vs-other-dod-api.895334/

The original topic of this post is Burst, which is architecture-agnostic. @protopop Is there a particular piece of code that is performing slow that you would like to optimize? Perhaps a particular piece of code that uses the keywords "while, for , or foreach"?

 

Hard disagree. It has helped our game in early access tremendously. Some devs in this forum are using it in their games in development.

 

I'm interested in a link to the project/steam store?
Where did you use Burst in your project and it proven to be needed for your projects requirements? and this was not obtainable in another way?

I think my frustration stems from the fact that most Unity API by itself is not performant, or accessible from Jobs/Burst.
And the current API available is bogus and performs bad because nobody in Unity seems to care about performance of their CS code or math library.

Performance by Default? lies.

As example take the simple case of you want to run a raycast. We all know that mono does not inline.. and that mono is slow with method calls cause it looses context and cache. and that calls to native are heavy. SO lets see what it does.

Will you come on this journey with me?

Code (CSharp):

1.     public static int RaycastNonAlloc(Vector3 origin, Vector3 direction, RaycastHit[] results, [DefaultValue("Mathf.Infinity")] float maxDistance, [DefaultValue("DefaultRaycastLayers")] int layerMask, [DefaultValue("QueryTriggerInteraction.UseGlobal")] QueryTriggerInteraction queryTriggerInteraction)
2.     {
3.       return Physics.defaultPhysicsScene.Raycast(origin, direction, results, maxDistance, layerMask, queryTriggerInteraction);
4.     }

1. So Physics.defaultPhysicScene is a Method call, and it does a call to native of getting the current/default physics scene.
2. Raycast is a call.

Lets look on!

Code (CSharp):

1.  
2.       return (double) direction.magnitude > 1.40129846432482E-45 ? PhysicsScene.Internal_RaycastNonAlloc(this, new Ray(origin, direction.normalized), raycastHits, maxDistance, layerMask, queryTriggerInteraction) : 0;

3. direction.magnitude is a method call. it does:

Code (CSharp):

1. return Mathf.Sqrt((float) ((double) this.x * (double) this.x + (double) this.y * (double) this.y + (double) this.z * (double) this.z));

4. mathf.Sqrt is simply a return float casted double Math.Sqrt
5. Math.Sqrt in itself is a method call > to native instrinct
6. Then we do Create new Ray Struct. we pass it a direction.normalized. that is a method call!
lets look at it!

Code (CSharp):

1. get { return Vector3.Normalize(this); }

7. yeah that is another one..

Code (CSharp):

1. float num = Vector3.Magnitude(value);
2.       return (double) num > 9.99999974737875E-06 ? value / num : Vector3.zero;

10!. Hey how cool, we do a Magnitude again. so lets add 3
11 or 12. If returning Vector3.zero it is a method call. ({get return zeroVector} else if value/num we get. function call to operator overload of / which is return new Vector3(a.x / d, a.y / d, a.z / d); another method call
13. new Ray == methodcall.
Inside the Ray struct constructor we have... you guessed it..

Code (CSharp):

1.    this.m_Origin = origin;
2.       this.m_Direction = direction.normalized;

Another Normalize!
so lets add another 5.
So final count is 18 method calls, 3 sqrts a bunch of float to double and double to float casts and calculating magnitude 3 times and normalizing twice.

This is a simple RANDOM case.

Why nobody solved this? why nobody seems to care?

Mono does not inline, il2cpp also not, or almost never. Even with aggressive inlining applied (not applied in any unity libs) and even if it would be inlined, in Il2cpp it adds a bunch of static bools to every method in static classes to check if they have been initialized yet.....

Performance by default.
Maybe.. if you don't use any part of unity.

 

You do understand that they're making whole new APIs for DOTS, right?

It's nonsense to bash DOTS and the Burst compiler while pointing at the old stuff that's largely unrelated. The bridges they're making (like the meshData stuff) are meant to ease the transition and fill the holes until native DOTS systems are developed.

The whole point of this motto is that they're making new stuff with performance in mind. I honestly can't understand your rant.

 

Fixing this stuff is easy, just put a single coder a week on manually inlining everything and you have a more performing Unity for everybody, no burst needed. Speedup of that is between 2 to 3x on all math.

That was my point, burst is useless tech used by a select few, and most things are not available or WIP. whilst the thing that is used by many is not fixed. frustration galore.

 

Look, I have no intention of further derailing this thread. I'm just gonna say that what your asking for sounds reasonable but is largely unrelated to the topics where you usually ask it.

Both you and unity have seen the same problem and they've decided to solve it in a particular way. Whether you like it or not, they're already invested in it and they will not halt it or throw it away (as you've asked for in the .NET 5 thread).

At this point, it's better to be constructive and try to help the new tech be as good as it can because like it or not, it is the future of unity. They will not touch the mathf library. They won't risk introducing bugs, because they've moved on. I suggest you focus your (valid btw) criticism into something they're willing to work on.

 

I wish I had kept my mouth shut, and just responded to technical questions. My apologies, protopop.

 

For instance? The exact words that are misleading?

The article is technically accurate, and the gist of it is that it's up to you to approach the programming paradigm where one person approached it in a bad way, and the other one re-structured it to make it fast and efficient. When you call it an Object-System architecture is just one of the possible forms, but not the only one that OO allows you to do, that's the point.

 

No apologies. You sound really reasonable and knowledgeable, and you share it on a friendly non threatening way.

I do think the no classes thing will be too esoteric for casual coders like me raised on JavaScript and c#. For me the important thing is to better understands what dots, Ecs, burst etc are because after several years I don't really get it.

Part of that I think is the messaging because I think if it doesn't support classes I would mention that way up front, I mean I had never heard of that, so when I find it out after digging only it makes burst seem even more inaccessible, not because you can't use classes; but because the marketing around it doesn't make this very clear to new people wondering what it is all about. If we just say "you can't use classes but wow it's performant in x case" then we can digest the good with the bad (bad being learning a new coding paradigm which is a resource sink even if it is helpful). When the pr has only the positives on the surface I began to wonder why am I not using this, so when I find out the challenges are not presented up front I get it but I think it would actually help to be more transparent. It would be good to know we need to learn a new way of coding actual code and that this code is part of c#.

The other issue is No one seems to know the name of this c# subset. Someone posted a link to the burst page before but I didn't see the name. It HAS to have a name doesn't it? How can we communicate burst to people without information like this. We can't just say it usesba c# subset because there are infinite possible subsets right? And this is a particular subset correct? I'm not trying to be facetious but I'm legitimately curious - I mean is it called like "c# simple set" or something, anything. Things like this make it really difficult for people like me to understand what is required and what is going on . I'm still hoping someone can tell me the name of the subset, because I think it was mentioned lots of people are using it so it must have a name.

This thread is very illuminating too about some of the benefits of oop vs dots and the strength of each and why some things are faster or slower so I definitely have some more insight I think after reading all this.

EDIT: if it doesn't already exist I vote to call the subset "CSharp Strict"

 

It sounds like the c# subset is kind of like using the pragma strict in unityscriot, which was a way to let unity know you were using a stricter US subset.

So is there like a cSharp strict (I made that up but like that name for this btw) that can be added to the top of a c# code page to remind the cider and let the compiler know this is c# strict code?

It's a way to label the different code types. But then I am guessing you have to choose to use the unity built in compiler (is that the mononcompiler? Or is it llcpp (I can never spell that from memory), is that a separate compiler) or the burst compiler? Like can you have more than one compiler compiling different parts of project?

 

Just my 2 cents:
The subset of C# has been called HPC# (high-performance C#) in the past but it's not a well-stablished thing. As the Burst compiler itself evolves the subset it can work on will expand.

And I like to think about DOD as a factory with a long, never stopping conveyor belt. Over this belt there are boxes (entities) that have zero or more "things" on them (component). Along the conveyor belt there are a series of machines (systems) that are constantly scanning the boxes as they pass over them, picking the ones with the right things (queries) and doing some work over them.

Now there's some nitpicks about this factory:

As not all the machines depend on each other, the conveyor belt will split and rejoin as much as possible to allow machine working in parallel (jobs).

There are few restrictions about this boxes, as the things inside are expected to be passive and not change except by a machine (stucts).

Also, the machines cannot add new boxes to the belt or resize the existing ones by adding new things, because the boxes are laid out in a very specific way (archetypes), and that would disrupt the layout and force the belt to stop and readjust. (sync points).

To solve this, the machines can make requests to a special machine located at the very end, that changes the boxes on behalf of the rest (entity command buffers).

Finally, the conveyor belt actually loops over itself, so that the boxes will pass by all the machines over and over again in a logical otder (player loop)

I know this metaphor is not very accurate and kinda silly, but it helped me understand the mindset needed to work with ECS and distance myself from the OOP one.

 

Maybe Burst could be more marketed like Mathematica or something, like say it's a specific subset tool if you need high performance of many objects, and that it has specialized use cases. Speaking as a casual game developer I can say there is a mixed message coming out that all parts of dots will replace the old way. But then I find out something like Burst is actually for specific cases. So maybe if it was marketed as a specific adjunct and not mixed in with the overall message that most casual need to use burst or should be using it might make it less scary. I think you managed to position it quite clearly in one paragraph.

 

I think that's a helpful analogy. I can see why some game devs like me are reluctant about dots because it sounds very performance but very rigid, so I guess that's the trade off.

I like High Performance C# the name becausenit gives us an umbrella term to understand what we're dealing with and it's marketable and way to remember. It makes sense Unity is not usingthe term if their subset used in Burst changes. But then that means the Burst subset of c# used is being decided internally by unity? So it isn't using a universal subset and I guess that's why it doesn't have a name? And isn't there a danger of alienating people by creating a proprietary subset of c# that will only work with one unity compiler instead of using some sort of universally agreed upon c# subset like HPC ? I'm not try to know anything here, I'm just trying to get the facts straight. I probably won't use the burst compiler , but it's better for me to know why I'm it using it, and alsonthat it is ok to Use it if you want to and ok not to , because I was feeling this pressure from the forums and online that somehow burst and jobs are the only future. Now I'm guessing that in addition to dots people will be able to take what they learn from it and side port some parts of the best of it to improve non dots paradigms as well.

 

Erh. Javascript does not have classes.

Put it this way:

Jobs
Are helpers for you to write multi-threaded code without the hustle to make sure that you do not introduce race conditions. You are the one who have to decide if turning some code into jobs is worth it or not.
Obviously you will turn into Jobs mainly your code which crunching numbers (path finding, random map generation, etc)

Burst
You, as a game developer should not care about this too much, only if you notice your job isn't compiled by Burst. What it does basically is to turn your code into more efficient one by changing/rearranging it. Sometimes it is intrusive, sometimes it's not. Obviously it is your job to decide if you want it or not. If you want to understand Burst though, you really need to read up on SIMD and how CPU and data on CPU work.

ECS
You can use it or not, it is up to you, but it helps to arrange your data in a way to make easier for the CPU to work efficiently. You can do similar thing in OO environment too, but it will look equally strange. Keeping ECS makes it easier to digest. What ECS means is remove you from the world where you define objects by union of data and logic. It forces you to separate the two in your mind and describe your data first and then write systems which work on some similar entities.

 

Game here.

Some blog posts 1, 2, 3, 4.

Why should I look for another way when DOTS already works? The gains are significant, too, that looking for another faster way seems highly improbable due to memory layout of traditional GameObject and normal classes.

 

This is correct.

 

I treat JavaScript objects like classes, they're just encapsulations of data and functions so they seem similar to me in terms of the way of thinking.

My understanding is that UnityScript - we all just called it JavaScript - uses classes but just hides the declaration from the code page so we didn't see it. That was one of my biggest changes in thinking when I had to learn C# - the extra indent of parentheses took getting used to and felt verbose.

Now I'm not sure I understands what no classes means for burst. Maybe I am thinking of something different?

I am glad to just understand more where Burst could be useful and how it fits in. That was my main challenge.

 

Thank you. This is the kind of insight I was hoping for. It helps me understand the reasoning behind Burst and how and why it is what it is . It seems to be a unity specific tool like il2cpp, not a universal one like C# that can be used across game dev in general. it's just good to understand where to position it. I think perhaps it's the vague positioning that makes it a bit less understandable if you come from outside the dots forums so I appreciate that.

 

I recommend you read these blogs if you haven't already:

https://blogs.unity3d.com/2019/02/26/on-dots-c-c/
https://blogs.unity3d.com/2019/03/08/on-dots-entity-component-system/
https://blogs.unity3d.com/2018/10/22/what-is-a-job-system/

 

Yeah. Just like those heavy-weight industry-ostriches. This is why I left front-end development as a business. Which "OOP" front-end "framework" is fashionable this week?
You know, finally you have a language with a perfectly fine prototype-based hierarchy system and what the industry do with it? Turns into a mediocre, clunky OOP-afterthought.
Okay, I have my own mental problems, because I left it and then went to work for one of those companies which lead this OOP-BS and work in Java (and sometimes in GWT... if someone remembers what it is, now it is the time for laugh).
I laughed out loud when someone started complaining about the verbosity of the ECS. Lol. Just look into a random Java code you will know what verbose means.

Anyway.

UnityScript was not Javascript. Never, ever. It had some similar syntax sometimes, but generally no.

Probably. No classes for Burst means no classes for Jobs. You can't really use reference types inside of them. You can (and should) encapsulate them in classes as normal, but you cannot (sometimes you can, but generally shouldn't) reference things outside of the dataset you explicitly pour into them. Just watch a tutorial how to use the Job System and it will be more clear.

 

If you wish to start a new thread on this topic, I am not afraid to elaborate on this.

I don't disagree with you that Unity's PR can be misleading. I usually ignore them and judge based on what I hear from the developers working on any specific feature. In this particular case, the Burst team is very professional about how they explain their product.

By the way, Unity invented the term HPC# and are defining it themselves. You don't have to use it if you don't need it, but it is a powerful tool that you can adopt incrementally.

One last thing, a lot of people here are talking about ECS and architectures because it is part of the DOTS ecosystem. But the truth is right now MonoBehaviours + Jobs + Burst + Mathematics is the only combo considered "Production Ready". Most people use Jobs and Burst to optimize a particular computation-heavy subsystem in their game. The water simulation in the BoatAttack demo is an excellent example of this.

 

Don't spread misinformation then.

 

I have to say something here, and im reticent to say anything and apologize if it comes across too strongly, but only because I come across this being said a lot, and I think it exemplifies the difference in thinking patterns between perhaps a more engineering mind and a more casual user. And I think it is this divide in thinking patterns that is making it so hard to communicate what DOTS is (a very engineered, strict, performance focused tool) to people who are more casual (making fun games and experiences with performance not being the primary concern) because so many sells focus on how much performance is available with the new technologies without offering much talk about ease of use. I know UnityScript is not Javascript. But I was a Javascript coder and it was like 95% the same. Many web coders have said how easy it was to make the transition to unity because if the similarity. I don't think specifying that the two are totally different is , I don't know the word, but kind of unhelpful to the situation, because it misses the spirit of the claim, the languages are really similar. I mean, I've seen it with my own eyes, so why keep saying its two completely alien to each other species when that ignores how much they have in common. Even unity themselves called it Javascript in their examples, so from purists angle yes they are two different beasts, but I mean I may have a different culture than a human being from another society, but I can see I have more in common with my fellow humans than not. I hope people will acknowledge that the similarities between US and JS are clear in many peoples experiences and not dismiss that.

 

Im going to look into mathematics because I keep hearing it mentioned, and fro what you said it sounds like maybe something we can use today for our legacy projects?

I always thought when it came to mono behaviours that unity should just give us an empty class entity we can use for anything. And offer a minobehavior as a more complex class. I mean its just an empty object with transforms and some method calls added, right. I love building up worlds fro component pieces and if the game object was seen as too heavy in some cases then giving us even more atomic access would be a great way to ease us in. Like let me put an empty entity class with zero components in my Scene hierarchy view and let me attach my custom components to it that don't need transforms etc. Like my BRAIN objects that manage the scene. I think coders do something similar but they create these in the abstract in the project files themselves, but for me I like to see a visual representation of the code in front of me.

 

I really don't understand your way of thinking.

Unity has plenty ease of use already. What Unity doesn't have currently is plenty of performance. So developing a way to have plenty of performance as well is a good move.
You can develop the fun projects no matter DOTS lives or dies. But certain type of (also fun) games aren't feasible currently in Unity. Or they are extremely hard to make. Like simulation games (I guess the Cities Skyline and the Kerbal teams could and did talk about this if I'm not mistaken). Or why do you think there aren't that many RTS or bigger TBS games in Unity?
If you aren't interested in performance, that's fine, no one will force you to use or even look at DOTS if you don't want to take them up. And they aren't primarily developed for those who like to put some fun little game together quickly. For that, the existing workflows are plenty good.

When it comes to the performance things, ease of use is secondary. It is important, but not the most important thing. And that's a good thing, actually. Of course it can be, and will be mitigated with things like the DOTS Visual Scripting, but I think, you will still need to learn how to think when you put together a Data-Oriented architecture. It is just the nature of this beast.

About the US vs JS. Well, if you are judging something only by the interface, then two automatic black cars are the same. Same interface, same overall shape. But in the internals they have plenty of differences which may or may not becomes important when you use them. For example in case of a dangerous situation you handle a small hatchback differently than a landship-sized limo. You know. The same applies to programming languages as well. You may perceive US and JS the same, and yes, the syntax has plenty of similarities, but the internals and the work underneath were different. It may or may not important for you when you write a simple game with simple logic without any complicated things or without touching Unity's more internal behavior. But when it came to problems or when you started to actually use Unity's services, US behaved plenty differently from an average JS application.

I don't understand how human similarities and differences have anything to do with this topic. At all. yes, we all humans, we have a lot in common. We also have a lot of differences no matter if we're from the same culture or not. Hope I didn't imply anywhere that I would be superior or something, because I do not think that and it wasn't my intention at all.

 

It is a low-level math library using hlsl naming conventions. So instead of Vector3, you have float3, and instead of Mathf, you have math. There's a few other differences as well. Burst has a tightly integrated understanding of the library and can make aggressive optimizations on code using it.

ScriptableObject, or just a class that doesn't subclass anything?

The reason it is heavy is because it uses class types for components and each class type is backed by a C++ object.