Discussion Mono multithreading and burst which is faster? The tests didn't feel much different

I am working on a broken plugin and would like to know the performance difference between the two.burst has a lot of syntax limitations, and if the difference is not significant there is no need to migrate the codebase.

 

Burst + Job system is going to be much faster probably, depends on how you implement it

 

You can easily see gains for Burst compiled code that is hundreds of times faster than regular C# code.

 

Do you have the test data? mono +IL2CPP+ Multithreaded Parallel.For is also fast. Maybe DOP is the future, and "Burst" is worth a try.

 

Burst is separate from multithreading
you can multithread with Parallel.For and call into burst code from there
That said, I think the job system will work better for most short term jobs than using C# threads/tasks, due to the managed/gc overhead and such there

 

Using Burst is free of GC overhead, but not necessarily fast. If you are dealing with a lot of data add/modify/copy is slower than the reference type. That's my personal guess.

 

Can we stop guessing and use profiler for once? You can pass structs by reference to avoid copies

 

I'm not familiar with Burst programming. Tutorial resources are relatively few, I will test it when I have time.

 

Burst compiles the code directly into machine code with SIMD instructions using LLVM, while IL2CPP generates a C++ representation of the dotnet IL that is then compiled to machine code. The differences in performance between the two depends heavily on what kind of code you're feeding into them and how compatible it is with vectorization. If the code cannot be vectorized at all then the difference should be small.

Vectorization means operating in multiple data elements with a single instruction. For example, let's say you have a loop that iterates through two int arrays (A and B) with 1024 items each, and writes the sum of each item into a 3rd array C. With normal scalar code, the CPU needs to operate 1024 times while with 128-bit vectorization it can do the same work using only 256 operations by reading, adding, and writing four elements at once.

Vectorization also allows operating on all components of a Vector4, Vector3 and Vector2 at once.

 

That was a very professional answer. Thank you. Here's a test post.
https://forum.unity.com/threads/ben...fibonacci-mandelbrot-nbody-and-others.715133/

 

Use SIMD-accelerated numeric types
https://learn.microsoft.com/en-us/dotnet/standard/simd

 

I'm not sure if Unity supports those yet.

 

Today I did another 10,000 particle motion tests:

mono +IL2CPP+ Parallel.For 74FPS-80FPS

IL2PP+Burst 75FPS-80FPS

ComputeShader 72FPS-95FPS

The fact proves that the performance gap is not very big, the key is algorithm optimization. ComputeShader is about 3 times faster than Burst in pure computing.

 

The Burst CPU usage rate is not high, so I don’t know where the settings are not accurate?

 

In fact, there is no point in discussing this issue. The ultimate goal is concurrent programming. Burst provides a more secure method. Either way, the code is the same.

 

... is that a benchmark taking FPS numbers from the in-editor statistics menu?

That's a wildly inaccurate metric

 

The built project is the same, and the FPS of another statistical method is 50 frames. Of course, this statistics is unfair to ComputeShader, All the stress is on the GPU.
.

 

Obviously, there is no high-performance and flexible method, no dictionary, no List, no HashSet how to write your code. That's the point.I don't know about the performance of Collections. Concurrent. It is difficult to write code with only arrays

 

If you'd like to stop kidding yourself and do an actual benchmark: https://docs.unity3d.com/Packages/com.unity.test-framework.performance@1.2/manual/index.html

 

The test is meaningless. I need to modify the way of thinking about writing code. Use array instead of dictionary, list. This way the code can run anywhere.

 

Rendering will affect the test results. If your rendering pressure is high, the FPS will be reduced. Therefore, the game CPU and GPU need to be balanced to have high performance. Burst is three times faster. ComputeShader is six times faster. Burst really improves performance.
Of course, the test results are related to your computer configuration.

 

Array: NativeArray<T>
List: NativeList<T>
Dictionary: NativeParallelHashMap<T, U>

If you want to understand how fast burst is you need to benchmark burst code itself (Stopwatch class around the job would do it), or just use the profiler. The frame-rate is never an appropriate way to measure the performance of a small slice of code. Spoiler: Burst is much faster than you seem to think it is. I encourage you to explore it more, you'll be pleasantly surprised.

 

This essentially boils down to two things, I'd say.

1) What's the better compiler? Clang/LLVM or some Mono-JIT? Answer: Mono-JITs are a joke in comparison.
2) What's better for performance - compile time validation or runtime validation? Answer: It's obvious.

Overall answer: It's obvious.

 

Burst is indeed faster than Mono, but it is not fast enough when there are a large number of ray calculations, and SIMD code is not easy to write. ComputeShader has no way to use List and HashMap, so you can only use Array. ComputeShader is much more difficult to write code. I think burst and It is better to use ComputeShader in combination. It would be great if burst can take advantage of GPU acceleration.

 

It is indeed easy to write SIMD code with Unity.Mathematics. With C#

unsafe

you can even load

int4

SIMD vectors from a

NativeArray<int>

.
There are many things that oppose the suggestion that Burst should... somehow make use of GPGPU: Some devices simply don't have a GPU... GPU compilation being completely different from CPU compilation... The GPU actually being the bottleneck in the vast majority of games while the CPU code sometimes doesn't even use multithreading, not even talking about taking 100% advantage of the CPU... You still being able to write compute shaders if you wish etc. etc. etc.

 

I don't think the SIMD code is easy to implement, my code is not a simple array loop, the logic is very complex and has a lot of intersecting ray lines. To implement the SIMD splitting logic, one would need to create more arrays to store the data, which would make the computation slower and take up more memory. I'm not against Burst, I'm already using it, it's just not performing as expected. Currently the code takes between 4ms-70ms to process the mesh in one run, so I would like to use ComputeShader to speed up some of the code, if the device supports it.

I've written this plugin to be less suitable for low end devices, where dynamically generating meshes requires a lot of performance, or to run the game after pre-processing, my goal is to be able to run it on PC devices.

Burst performance is still good,so I'll finish my task in burst first.