Plans for Multithreading/Multiprocessing (i.e. using ALL THE CORES)

[phryk]

Is your feature request related to a problem? Please describe.

I have enjoyed the original trilogy, as well as Anomaly in vanilla and GAMMA flavours. openXRay 1.6 is the de-facto way to play the OG trilogy as well as the upstream for xray-monolith on which Anomaly is based, hence I'm asking about this here:

Are there any plans to implement multithreading/multiprocessing?

With the engine being pretty CPU-bound, it was already frustrating at 4 cores that the engine would only utilize 25% of the CPU, but now that after over a decade I finally upgraded to a 16-core CPU I get the engine to utilize a whopping… 6.25% of available CPU resources. And this will only get more ridiculous if things like RISCV enter the desktop market, i.e. machines where you can expect like 128 cores, but each with very low performance.

I fully expect to still play some variation of STALKER 15 years from now, so I don't really care about how long it would take and I don't care either if it won't receive any sort of priority for years to come, but I would like to see at least some acknowledgement, that this is on developers' minds.

Describe the solution you'd like

The engine being able to use all cores, i.e. have all CPU-bound subsystems like A-Life use either multithreading or multiprocessing to achieve maximum parallel resource usage.

Describe alternatives you've considered

The engine being able to use… more cores than now, with dedicated threads or processes for specific subsystems like A-Life, physics, etc. Not ideal, but sounds like it would be an easier approach to get a considerable boost of CPU-bound performance within an intermediate timeframe.

Additional context

Love the project either way. ❤️

[AMS21]

Correct me if I'm wrong here but I believe there already is some multithreading in the engine and I'm pretty sure its already on the roadmap.

The problem with multithreading is that its not that easy, especially when trying to convert an engine which was not written with multiple cores in mind. Multithreading issues are those kind of issues where it works fine for 10 hours straight until it just doesn't and you get some bug or worse a crash.

For me personally I try to first make things right and then try to make them fast and I'm pretty sure there are a lot of bugs, crashes, undefined behavior, etc. still inside the engine which I would like to see fixed first. Same with portability (multiplayer only works on Windows right now for example).

Also I'm not saying we shouldn't do this but I also don't see it as a big pain point right now since I personally can run a debug build with sanitizers enabled (about 2x slow down) and still get my 60 fps most of the time. And I would presume that CPUs 15 years from now will still be able to run this game even if it's single threaded.

On a side note: Not sure about Multiprocessing which I believe is used to sandbox different part of a program from each other like the rendering processes or javascript execution in a browser which would need some kind of IPC-Protocol and is probably not a good fit for a game engine.

[phryk]

I sadly don't know the engine internals. I once attempted reading into the A-Life system, but didn't get very far…

Shared memory is still possible with multiprocessing, but yeah, I'm definitely not saying parallelizing the engine is trivial. I'm no stranger to the frustration of hard to debug (or even reproduce) race conditions and I only utilized message-based IPC, not shared memory – where I'm assuming transaction safety is something you have to implement yourself.

The main reason I didn't commit to multithreading here was because I don't have a good overview of how different OSes handle it.

I vaguely remember that BSD would put all threads of one process on the same core so you had to do multiprocessing to use all cores there, but AFAIK that hasn't been true in quite some time. Nowadays I'm pretty sure BSD and Linux would be able to utilize all cores with "just" multithreading, but I don't have a clue how it stands with Windows which is probably still the main build target.

That said, I'm really not too sure about future CPUs running singlethreaded openXRay projects easily. If things actually do move into a more RISC-y way, single cores will be less powerful. Also, last I checked GAMMA with warfare mode enabled was already essentially unplayable because CPUs aren't routinely clocked at 10+GHz – but thinking about what the community would do with parallelized A-Life just causes me to salivate like a pavlovian dog… 🤤

[AMS21]

Well seems like you do know quite a bit more about multithreading than I do :)

Maybe you should give it a try and see if you can't find something to improve/parallelize in the engine (maybe don't start with the A-Life system :wink:). I'm pretty sure any help would be greatly appreciated.

If you need any help feel free to ask here or on discord

[Xottab-DUTY]

Speaking about multiprocessing, I believe, it would drastically make the engine architecture more complicated, so it's not a good fit for a game engine. I'm sure (or hope at least) that even if BSD does put all threads into one core, there's still some system API available to differ this behaviour.

And, getting closely to multithreading – first, we would like to untangle, unravel the engine components into something more parallelizable by design. For example, we have two tasks on this: #1120 and #1117.

1120 is more practical and concrete – it points to exact part of the code that needs refactoring.

While #1117 is something not yet clear. For example, we want to implement ECS, but

1. We want to keep the compatibility with the vanilla game assets, e.g. scripts which are unaware about the ECS.
2. We also want to provide a facility for game assets to utilize the ECS and its features, so that modders could benefit.
3. There's so much code tied to another code, hacks, workarounds and tangles in the code, so it's a challenging task.

And after unraveling the code or simultaneously with it, we can make the engine more and more multithreaded. 👍

[Xottab-DUTY]

Also, I came with an idea I had for some time already: Move xrServer class to a separate thread instead of processing both client and server data in one thread.

This is something that could improve FPS a much.

[phryk]

Thanks for the answer, it's nice to know that this is something that's being thought about.

I'm already chock-full with projects, but I always wanted to get a proper look at the engineering behind the A-Life subsystem, not least because I want to build something similar. If I'm lucky I might get around to this in 2024 and will see if I can get in deep enough, so I can reason about #1120 – but I never worked with C++ and as of now can't even find the definition of alife(), so I wouldn't advise anybody on holding their breath. ^^;

[Altogolik]

The most advanced Ai now in the modification Prossectors Project. If it was possible to transfer at least 80% of what is there, the game would be much more interesting. There is also Ai additions 2.0 is an incomplete version of what is in Prossectors. https://www.amk-team.ru/forum/topic/4653-ai-additions/ Artificial intelligence of bots and simulation from life is very important, I hope someone will do the transfer