You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Computers, consoles, and phones all have more than one CPU core these days. But aside from audio/video decoding, all of love's own internal code is singlethreaded. We do have APIs to run Lua code in multiple OS threads, but because each thread needs its own Lua instance it takes work to use efficiently in a lot of situations - independent heavy algorithm processing and asset loading are the two easiest ways to use love's threads right now.
Most modern game engines have an integrated job/task system they use with a thread pool, to parallelize their own work (for example render command generation or physics simulation) and often to parallelize game code, all in a fairly simple manner.
It'd be nice to have something like that in love - maybe just for internal use to start (if good uses can be found) since more infrastructure and profiling work would need to be done to make it really solid in Lua code. In particular it becomes a lot easier to know how to use and misuse a job/task system when there's a way to visualize the different parts of a frame and what job threads are doing in a given section, and there would be details to figure out for keeping jobified Lua functions side effect free in a given job thread.
enkiTS seems like a solid library for the base of this sort of thing.
The text was updated successfully, but these errors were encountered:
It is also very good to transfer network interaction (especially UDP) to a child thread, otherwise lags in the game can lead to the loss of datagrams, both receiving and sending. Perhaps it would also be nice to transfer interaction with ENet to other threads.
For networking, a dedicated thread (which is already possible) might make more sense than a job system (which is also already possible, just not as integrated as I'd like). However I'm not sure even a dedicated thread is super useful most of the time for realtime networking.
Computers, consoles, and phones all have more than one CPU core these days. But aside from audio/video decoding, all of love's own internal code is singlethreaded. We do have APIs to run Lua code in multiple OS threads, but because each thread needs its own Lua instance it takes work to use efficiently in a lot of situations - independent heavy algorithm processing and asset loading are the two easiest ways to use love's threads right now.
Most modern game engines have an integrated job/task system they use with a thread pool, to parallelize their own work (for example render command generation or physics simulation) and often to parallelize game code, all in a fairly simple manner.
It'd be nice to have something like that in love - maybe just for internal use to start (if good uses can be found) since more infrastructure and profiling work would need to be done to make it really solid in Lua code. In particular it becomes a lot easier to know how to use and misuse a job/task system when there's a way to visualize the different parts of a frame and what job threads are doing in a given section, and there would be details to figure out for keeping jobified Lua functions side effect free in a given job thread.
enkiTS seems like a solid library for the base of this sort of thing.
The text was updated successfully, but these errors were encountered: