What if....? (Async programming >thread<)

News & General Discussion
1

So you just shaved off 2ms off your game logic by spending few days optimizing your game’s logic?

So you wanted to have of your super smart ai updating every frame using monoBehaviours, but frames tanked after you spawned 20 ais?

So you finally managed to run 30% of your procedural content generation multithreaded?

So is this a shameless ad for upcoming solution?

So you have your super low-level optimized logic using frameworks and lot of systems, but you feel like you’ve written your own engine?

So you’re using ECS and miss Monobehaviours simplicity and object-oriented code design?

Those are the problems. Those are the questions we need to ask.

All those problems can be solved with changing the way you thinking of writing code.
Unity accustomed/forced us so much to writing single threaded code, that for many people
theading is like some kind of dark magic, so it’s better not to touch it or that
it should be used only for heavy math like mesh manipulation etc(that’s baloney)

So the idea is simple - to reverse this way of thinking - so I could write my code on my own thread
by “default” and only when NECESSARY delegate Unity api calls to it’s thread.
Decouple logic from rendering, but not in coding context, but in threads context.
Your logic frequency shouldn’t be dependent on game framerate.
This way you have full control over frequency of events, and you ‘pay’ nothing on main thread
because you use it only for stricte Unity stuff like GetComponent and stuff(which you shouldn’t do
a lot anyway).

But hey, it looks like someone from first world have serious problem with such approach, let’s listen

What do you think? :wink:
TBC…

2

Or you can just learn how to use ECS, which solves all these problems aside from the desperate clinging on to OOP.

3 Likes
3

I see. However ECS is not answer for everything. I for instance, and I guess hundreds of ppl in middle of project won’t just scrape hundreds of thousands lines of code to write them in completely new way. It’s also far from mature for serious use and will be for at least next few months.

4

Anything tied to input will need to run on the main render thread otherwise it will introduce input lag

5

You don’t need to rewrite all of your code though. You just need to rewrite the heaviest portions. ECS is not intended to be a complete replacement for MonoBehaviour. It’s intended to be used alongside it.

4 Likes
6

So your plan instead is for Unity to introduce what is essentially a THIRD coding paradigm?

There is no universal solution, but ECS is the best one.

1 Like
7

What if I told you that I’m too tired today for the riddles?

BTW, WTF are you talking about?
Are you talking about rolling your own multi-threaded code based on C# threads? Congratulations, you just reinvented the wheel and started to race for the available threads with the Unity core engine. Good luck.
It is not impossible to roll a robust multi-threaded solution but you will never have the same ease to schedule tasks inside Unity and also, the simplicity to burst (pun intended) your execution and have the simplicity of the Job system. Not to mention the extensive checks they perform.

So what’s your point exactly?

2 Likes
8

Isn’t that exactly what you proposed in the OP?

Extreme multi threading and ECS both require writing code in a completely new way.

3 Likes
9

I just looked at first image (then second), before even reading, and I knew, the OP post will be silly to begin with.

Then don’t. Problem solved.

Depends how code was written in first place, conversion may involve anything from simple adaption, some update, restructuring, to rewriting whole parts of scripts.

But anyway, most of us when been learning (and beyond), were rewriting things twice over at least at some point, when realizing, there are more suitable ways, to do same things.

Smart person will justify and weight benefits and cost, of learning and implementing new paradigm.

10

[first post continuation]

Ryiah made a great point.

Because in real project you almost never just divide your code into two groups: one that needs to be super fast, and one that you don’t really care for performance, right? It’s not black or white. 90% of your code can still benefit from reducing time it takes on main thread, whether you use DOTS or not.
And that’s why I belive that despite ECS/DOTS greatness, there is still very much place and point to using async programming model today and in the future with Unity.

Now, let’s see what’s this whole async programming idea and why it’s so awesome:

https://www.youtube.com/watch?v=M5VPoc4IrVM


[^Timelines; rectangles are your methods/code execution blocks/‘frames’, however you call it]

So what’s happening there?
Im simply moving target position for white box, and interpolate white box’s position to it every frame;
At first, I update target position @60hz, so basically every frame(not really because its done on other thread, but that’s not the point here).
Second(after first scene reset) I update target position @20hz. You see any difference? Me neither.
Then finally after second scene reset, I update target position @5hz. Only at such low rate you can clearly see when target positions for interpolation changes.
You see my point? It’s that even with stuff related to rendering you don’t need such high frequency for your logic.
Almost every time you create MonoBehaviour with logic in it’s update loop it’s very wastefull usage of cpu time, even if you write super optimized code there.
You always think how to make your code execute faster, and that’s perfectly fine.
But what’s often forgotten is how many times per second you’ll execute it? Because perf shouldn’t be measured just by time your method takes to call. But you should take this time and multiply it by how many times it’ll be called every second.
Now sure, you can do simple timer in update loop and exit it early, but your update method will still be called every frame, and on main thread.
Other great benefit of async programming is that your logic won’t affect your framerate, and framerate is afterall main reason we optimize code. Even if you overload your logic thread, it still won’t affect framerate(well of course as long as you won’t saturate your all cpu resources with other threads lol).

Sorry for huge post, but it’s complex issue and cant be explained in two sencences, that’s also reason for breaking it in a few posts.

In the next post I’ll be explaining a second meme(because it’s not just for fun) and discuss with a little more details problems and solutions for async related issues. Cheers.

11

InvokeRepeating? That’s what I use for most logic that doesn’t need to run at 60fps. If I spawn an army of AI, I just randomize the repeat rate to avoid spikes.

12

Yeah, this is… a really obvious solution. It’s how I handle AI in high traffic racing situations.

13

You are aware that ECS can run code on separate threads right? And besides what guys said already, you can define parts of ECS systems, to execute at desired frequency.

2 Likes