Coroutines any advantage in my case ?

[Lovingsoul1337]

hi ! hope you doing well !

i have another question:

does my code run faster if i use coroutines in my gameManager class and update each class:

map,
input,
player,
entities,
projectiles

in a separate thread each frame ? or has this just eventually a organisation advantage...

thanks for help in advance !

best regards

Lovingsoul1337

[pgimeno]

Coroutines may be the right tool for certain problems. It's not something I'd force myself to use just because they are cool and could be useful sometimes. It's not in the same camp as "should I use classes for everything?", it's more like in the camp of "should I use stacks for everything?" - well, certain tasks can be solved using a stack, but using a stack for the map, or for input, etc. is making things artificially complicated and clunky. Same goes for coroutines.

[RNavega]

does my code run faster if i use coroutines in my gameManager class

You need to profile these things on your end, like finding one or two reliable ways to measure how much time it takes for some function in your program to run X times (like ten thousand times)

in a separate thread each frame ? or has this just eventually a organisation advantage...

I think the speed improvement of breaking things up into threads would be non-zero, but still imperceptible. It'd be a lot of work to make all of those systems communicate from their own separate threads, without palpable benefits.
Most of the time we don't even fully exhaust the single CPU core that the main thread is running on. Until this happens, i consider threading only as a means to avoid the stuttering when getting data from blocking operations, like from the filesystem or from web requests, or some other punctual thing that would pause the game if kept in the main thread, as you always want the game to be responsive.

Edit: from a different perspective, if everything that you need to do on each game tick can happen in under 16ms, then your game can run at 60 FPS and you don't need to worry about threading.

As for using coroutines, I think they're just a different way of designing your program flow. They're not better or worse, just different (I guess a similar take to pgimeno's).

[marclurr]

I think the speed improvement of breaking things up into threads would be non-zero

At least 3 of those systems are dependent on the same data and at least one feeds new data into the others. With the locking required to avoid race conditions I'd expect the performance would be worse than single threaded, and that's before we get into the determinism of the simulation. Multi threading works best on relatively large workloads that have minimal dependencies on each other, otherwise the creation and communication overhead outweighs any parallelisation benefits.

[RNavega]

At least 3 of those systems are dependent on the same data and at least one feeds new data into the others. With the locking required to avoid race conditions I'd expect the performance would be worse than single threaded, and that's before we get into the determinism of the simulation. Multi threading works best on relatively large workloads that have minimal dependencies on each other, otherwise the creation and communication overhead outweighs any parallelisation benefits.

That's fair, I understand the scenario you're talking about: the tasks you're trying to do are too light and the time taken by the thread/channel overhead and any other "infrastructure" needed for threading ends up being bigger than the time doing useful work. Only profiling will be able to tell which scenario we're in, of course.

overheadBiggerThanTasks.png (64.56 KiB) Viewed 6890 times

[marclurr]

Yes this is a nice illustration of the situation. Not only that, in many cases you'll write code specifically to synchronise individual threads to ensure data flows through them in the correct order, essentially making the work synchronous.

As you say, proper understanding of your program and profiling is the best way to help decide whether multithreading will be useful to you.

[vilonis]

You probably shouldn’t use coroutines to solve architectural problems for your game.

First of all, coroutines in Lua don’t give you parallel execution. You’re still running with one thread, that thread is just bouncing between different stacks as it moves from one coroutine to another. You need to use love.thread to get parallel execution, and that is totally separate from coroutines.

Second, coroutines are difficult to use effectively at the level of program organization. It can absolutely make some code easier to write and reason about, like code that would normally be represented as a state machine with execution split up across many frames, but there are also traps to fall into and things that will feel unintuitive, like reasoning about loops in a coroutine that is resumed once per frame.

Third, you cannot save and reload a coroutine, it’s be like trying to write a closure to a file. So it is easy to create a situation where you have state stored on the coroutines stack that you don’t want to get lost if the game is saved and reloaded, so you either have a bug or have some special handling to serialize and deserialize the coroutine, but then your control flow by is determined by explicit data instead of the implicit state of the coroutine (its stack). At that point, what have you really gained?

That said, coroutines are amazing when their entire lifecycle fits within a single frame. The classic example would be writing an iterator using a coroutine which drastically simplifies the code for more complex iterations (over a tree, over a grid, etc).

[dusoft]

I would call the whole thread a case of premature optimization. First build it, then optimize, if there are speed issues.