Shulou(Shulou.com)06/01 Report--

Editor to share with you what the characteristics of DOTS in Unity are to achieve, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

The features to be implemented by DOTS are:

Accuracy of performance. What we want is that if the loop cannot be vectorized for some reason (Vectorization, see StackOverflow's problem), it should have a compiler error instead of causing the code to run eight times slower and get the correct result without reporting an error at all.

Cross-platform architecture features. The input code we write should be the same for both iOS systems and Xbox.

We should have a good iterative loop. When you modify the code, you can easily view the machine code generated for all schemas. The machine code "viewer" should well explain or explain the behavior of all machine instructions.

Security. Most game developers do not give security a high priority, but we believe that solving memory corruption in Unity is one of the key features. There should be a special mode when running code that gives us an explicit error message if it is read or written out of memory or dereferenced from Null.

High performance C

When we use the C # language, we still have no control over how the data is distributed in memory, but this is the key to improving our performance.

In addition, the standard library is targeted at "objects on the heap" and "objects with other object pointer references".

This means that when dealing with performance-sensitive code, we can abandon most of the standard libraries, such as Linq, StringFormatter, List, Dictionary. Disable memory allocation, that is, do not use classes, use only structures, mappings, garbage collectors, and virtual calls, and add some new containers that can be used, such as NativeArray and other collection types.

We can get errors and error messages during cross-border access, as well as debugger support and compilation speed when using C++ code. We usually refer to this subset as High performance C # or HPC#.

It can be summarized as follows:

Most primitive types (float, int, uint, short, bool... ), enums,structs and other types of pointers

Collection: replace T with NavtiveArray []

All control flow statements (except try, finally, foreach, using)

To throw new XXXException (...) Give basic support

Burst

Unity builds a code generator and compiler called Burst.

Burst sometimes runs faster than C++ and sometimes slower than C++. The latter situation stems from performance issues, which Unity has begun to address.

When using C#, we have complete control over the whole process, from source code compilation to machine code generation, and if there is a part we don't want, we will find and fix it. We will gradually migrate the performance-sensitive code of the C++ language to HPC# code, which will make it easier to get the performance we want, harder to Bug, and easier to deal with.

If the developer of the Asset Store resource plug-in uses HPC# code in the resource, the resource plug-in will run faster at run time. In addition, advanced users will also benefit from writing custom high-performance code in HPC#.

ECS Track: Deep Dive into the Burst Compiler-Unite LA

Burst's more detailed support for HPC# can be found below:

Burst User Guide

Solve the problem of multithreading

Neither C++ nor C# can provide much help for developers to write thread-safe code. Even today, it has been ten years since the development of consumer hardware with multiple core games, but it is still difficult to effectively deal with programs that use multiple cores.

Data conflicts, uncertainty, and deadlocks are challenges that make multithreaded code difficult to write. The feature that Unity wants is to "ensure that the functions and everything called by the code are not read or written in the global state." Unity wants to let the compiler throw errors to remind you, rather than belong to the "guidelines that programmers should follow." Burst will provide compiler errors.

Unity encourages Unity users to write "Jobified" code that divides all data transformations that need to occur into Job.

Each Job is "functional" because Job has no side effects. Job explicitly specifies the read-only buffer and read-write buffer to be used, and a compiler error occurs when trying to access other data.

The Job scheduler ensures that no program is written to a read-only buffer while Job is running. We will ensure that no program reads the read-write buffer while Job is running.

If the scheduled Job violates these rules, we get run-time errors. This error is not only obtained under race conditions, the error message will indicate that the Job you are trying to schedule wants to read buffer A, but you have already scheduled the Job that will be written to buffer A, so if you want to perform this operation, you need to specify the previous Job as a dependency.

Go deep into the stack

Because we are able to handle all components, we can make them aware of their existence. For example, a common situation in which vectorization (Vectorization) cannot be done is that the compiler cannot ensure that the two pointers do not point to the same memory, that is, Alias.

NativeArray in the two collection libraries is never confused, and we can use this knowledge in Burst so that it doesn't give up optimization (Alias) for fear that two array pointers point to the same memory. The problem of Alias was also mentioned in a speech in Unity GDC: Unity at GDC-C # to Machine Code

Unity also writes the Unity.Mathemetics math library, which provides a lot of data structures like Shader code. Burst can also work well with this math library, and in the future Burst will be able to sacrifice precision optimization for calculations such as math.sin ().

For Burst, math.sin () is not only a C # method to compile, Burst can also understand the trigonometric properties of sin (), know that sin (x) equals x when the value of x is small, and understand that it can be replaced with Taylor series expansion at the expense of specific precision.

Floating-point accuracy across platforms and architectures is the future goal of Burst.

Entity Component System

Unity has always focused on the concept of components. For example, we can add Rigidbody components to game objects so that objects can fall down. We can also add Light components to the game object so that it can emit light. We add the AudioEmitter component to make the game object make a sound.

Our approach to implementing component systems has not evolved well. We used to write component systems with object-oriented thinking. Components and game objects are "C++ code-heavy" objects, and creating or destroying them requires the use of mutexes to modify the global list of id-to-object pointers.

By using a data-oriented way of thinking, we can better deal with this situation. We can retain the excellent features in the eyes of users, that is, we only need to add components to achieve functions, while achieving excellent performance and parallel results through the new component system.

This brand-new component system is the entity component system ECS. To put it simply, what we do with game objects today can be used to deal with the entities of the new system, and components are still called components. So what's the difference? The difference lies in the data layout.

Class Orbit: MonoBehaviour {public Transform _ objectToOrbitAround; void Update () {var currentPos = GetComponent (). Position; var targetPos = _ objectToOrbitAround.position; GetComponent (). Velocity + = SomehowSteerTowards (currentPos, targetPos)}}

This pattern is used repeatedly: the component must find one or more components on the same game object and then read or write values to it.

There are many problems with this approach:

The Update () method is called by a separate Orbit component, and the next call to Update () will be a completely different component, which is likely to cause the code to be removed from the cache.

Update () must use GetComponent () to find the Rigidbody component. This component can also be cached, but the Rigidbody component must not be destroyed.

The other components we are dealing with are located in completely different locations in memory.

The data layout used by ECS treats these situations as a very common pattern and optimizes the memory layout to make similar operations faster.

Traditional memory layout

Discrete data leads to very low search efficiency, as well as the problem of Cache Miss, which can be referred to: general discussion of ECS

ECS data layout prototype (Archetype)

ECS combines all entities (Entity) with the same set of components (Component) in memory. ECS calls this set of components Archetype.

The prototype of the following figure is composed of Position components, Velocity components, Rigidbody components, and Renderer components.

If an entity has only three components (different from the prototype mentioned earlier), then those three components form a new prototype.

The picture below is from the handout of a speech given by Unite LA, which was unfortunately not recorded. Handouts can be found here.

ECS allocates memory in 16k blocks (Chunk), each containing only component data for all entities in a single prototype.

Someone in one post provided a more vivid memory layout diagram. For example, the prototype in the upper part is composed of Position components and Rock components, in which the whole prototype occupies a Chunk, and the data of the two components are stored in two arrays with information about the corresponding entities of the component data.

Each prototype has a list of Chunks blocks that are used to hold the entities of the prototype. We loop through all blocks and linearly loop the compact memory in each block to read or write component data. This linear loop runs the same code for each entity, while creating opportunities for Vectorization processing for Burst.

Each block is positioned in memory so that you can quickly get the desired data from memory, as detailed in the following article.

Unity2018 ECS Framework Entities Source Code Analysis (2) components and Chunk memory layout-Dapeng's column-CSDN blog

Entity (Entity)

What is the entity? The entity is just a 32-bit integer key (and some additional data such as index and version entity versions, but not important here), so you don't have to save or allocate too much memory for the entity except for the entity's component data. Entities can achieve all the functions of game objects, and even more, because entities are very lightweight.

The performance consumption of entities is very low, so we can use entities in situations that are not suitable for game objects, such as using one entity for each individual particle in the particle system.

The entity itself is neither an object nor a container, its function is to correlate the data of its components together.

System (System)

Instead of using the user's Update method to search for the component and then operate on each instance at run time, we just need to statically declare when using ECS: I want to operate on all entities that come with both Velocity and Rigidbody components. To find all the entities, we just need to find all the prototypes that match the specific "component search query", which is done by the system (System).

In many cases, this process is divided into multiple Job, resulting in almost 100% core utilization of the code that processes ECS components. ECS does all the work, and we just need to provide the code that runs against each entity. We can also handle the block iteration process (IJobChunk) manually.

ECS switches prototypes when we add or remove components from the entity. We will move it from the current block to the new prototype block, and then swap the last entity of the previous block to "fill the gap".

In ECS, we also statically declare what to do with the component data, whether it is ReadOnly read-only or ReadWrite read-write. By determining that only the Position component is read, ECS can schedule the Job more efficiently, and other Job that need to read the Position component do not have to wait.

This data layout also addresses Unity's long-standing obsession with load time and serialization performance. When loading or streaming ECS data for a large scene, the main operation is to load and use the original bytes from the hard disk.

API availability and boilerplate code

The common view of ECS is that ECS requires a lot of code. Therefore, you need to deal with a lot of boilerplate code to achieve the desired functionality. A number of improvements to the need to remove most boilerplate code are coming soon, which will make it easier for developers to express their goals.

We haven't implemented many of these improvements for the time being, because we're focusing on basic performance right now, but we know that too much boilerplate code is not good for ECS game code, and we can't make writing ECS code more troublesome than writing MonoBehaviour.

Project Tiny has implemented some improvements, such as iterative API based on lambda functions.

These are all the contents of the article "what are the characteristics of DOTS in Unity?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.