Will Udon 2 be Multi-threaded?

General Discussion
1

Will Udon 2 have the capability to do multi-threading?

I’m just thinking about Unity Jobs and how nice it’d probably be to have certain work be done on another thread so it doesn’t annihilate the render thread.

I can think of a lot of instances in the past where we had to do crazy Udon tricks to make stuff work, and not even necessarily because Udon was slow, but that the “correct” way to do something had to be deferred across multiple frames so it doesn’t freeze the game temporarily, or cause huge hitching.

We already have people somewhat doing this by making pseudo-compute shaders with ASyncReadback or shaders that take on the heavy lifting (like VRSL).

2

I think Udon2 is almost impossible to implement multithreading with the current known exposure design, and there may be serious security or stability issues with such a design.

Unless side-effects and state can be completely removed, it would be almost impossible to solve the problem just by considering the copying and releasing of memory content, which is similar to cross-programming language ‘ABI’, or it would require a serious performance cost to implement, which is not worth it.

I personally think that we should solve the basic performance problems first, and then when there is really no way to improve it and there is a need to start solving it, the official percentage of improvement and my own evaluation will be about 10 to 100 times slower than the original C# native performance that allows compilation, and there is still a lot of room for improvement.

This idea is similar to C++ with lua. Whether lua causes C++ to become multi-threaded, or lua itself is multi-threaded, it’s crazy.

Only if the C++ function called by lua itself is multi-threaded, it is normal to make it work a lot.

For example, the Unity animation controller itself is designed to be multi-threaded on the execution side, so that it can share the workload.

Rather than implementing logic in the animation controller’s state machine at runtime to make it multithreaded, or in the animation controller’s editing tools or state machine, the design of the animation controller is such that the actual work driven by the state machine is multithreaded.

It should be designed so that the logic behind the animation controller to update the driver bones, etc. is multi-threaded.

(Of course, in fact, most animation controllers do not interfere with each other, so of course they can be parallelized, except for changes that may affect each other, such as bone and object states, which are time-consuming enough to gradually become single-threaded.)

3

I’m primarily thinking of the use case of people throwing a ton of Udon game assets in their world. Even with Udon 2, surely enough games will lag out a world. So allowing those asset developers to dedicate that game logic to another thread would probably help rendering performance.

4

Coroutine can be considered in the early stage. As for multi-threading and true asynchronousness, they require a lot of time to build, which is difficult to handle at least for now.

1 Like
5

I see. I didn’t have a lot of familiarity with coroutines.

Would a coroutine allow Udon to basically context switch between normal game execution and running code?

I.E: The Udon code may execute a little slower, but it allows the renderer to run faster?

Sorry if I am getting this wrong. The basic definition of coroutines makes me think the Udon performance would be sacrificed.

6

Coroutine can easily separate the logic to make the business logic relatively clear, only the logic that needs to be executed into the Coroutine will generate the corresponding expenses.

This makes it easier to eliminate some of the overhead of checking execution.

But due to incomplete asynchrony, can not really do similar to separate frame asynchrony as a big boost, such as dynamic bone I can postpone to the next frame to do, if a frame time of 12ms that I will have 12ms to deal with the calculation of the bone, so that the performance impact is relatively small. (Because it’s not really multi-threaded).

You can choose to suspend your own logic without executing it and deliver resources to other parts first.

This looks like sacrificing Udon for some other performance features.

If the bottleneck does not involve waiting APIs such as IO, but frequent calculations, it may be ineffective.

If your purpose is to use Udon to implement complex calculations, you may end up opening an additional thread.

However, assuming that your calculations do not require real-time and sufficiently precise results, you can reduce the number of times and use the coroutine scheduling to avoid overly time-consuming results and to reduce the number of frames.

It is not clear what the performance of the various functions and implementations will be after Udon2, the performance differences between different combinations of programming, and the complexity and size of the calculations due to the actual requirements and how they are designed.

Initially, Udon2 may consider that the interpreter is able to run correctly and fast enough, while waiting for the design to be perfected and using AOT for wasm binary and JIT acceleration may bring more benefits.

1 Like