If referring to the PS4/Xbox One then the CPU was quite bad to begin with as it was based on their Bulldozer architecture and so practically anything from Intel at the time was a huge amount faster. If referring to the PS5/Xbox Series then the CPU is based on Zen2, which was already surpassed in the PC space by Zen3 at the time of release with Zen2 CPUs having been out for over a year. I doubt there is anything Sony could do to make the cores faster than Zen3.
I am unsure what this has to do with your statement. The actual background garbage collection threads are lightweight as they are not moving/copying anything, only marking and sweeping. For logical reasons when they are copying objects they need to be run at the highest priority since a large part of the JVM may be stalled until they are done.
Some recently added GCs do try to do even more in parallel without pausing the VM, but these come with their own additional overhead.
As far as I am aware these is no situation where separate applications will perform better than a single application that is correctly using threading. Yes it is harder to debug, but as you pointed out there are significant savings due to how complicated applications are compared with threads. If you know of a game that does this I would like to look it up, but so far the only time I know that games spawn (fork) separate processes is for either interoperability with other applications or for anti-cheat monitoring.MSterling wrote: ↑Wed, 27. Jan 21, 03:55The POINT of this long winded blowhardiness is that there may be a requirement to reconfigure how things are done if you have a high-core-count CPU, because forking is trivially scalable, and threading lighter, but complexity grows as you increase thread counts. So it might have to run one program that is threaded if it detects 8 cores or less, and a different program that is forked for 10 cores or more.
This makes the assumption that Egosoft has not already minimised the memory usage as much as they can and have not already optimized their script engine as much as possible. Although there is likely room for improvement, the returns are almost certainly not cost effective, especially for a small developer working on a niche game.MSterling wrote: ↑Wed, 27. Jan 21, 03:55It could be worth Egosoft's time getting someone who has worked on embedded systems to help out in design, not for the embedded work, but on the knowledge of what can be done to minimise memory use, and then use a more efficient interpreter design to massively multifork and let the OS unhome from a CPU any interpreter that is dealing with an object whose script is paused and has nothing to do now, but will potentially come into life at an indeterminate point in the future.
The main issue limiting multi-threading are data dependencies. Everything in game has to happen in a reasonably reliable order. Due to the nature of the game, interactions have a very large scope so it is not really possible to split the updating across multiple threads while also maintaining a reliable order. Even different sectors still depend on each other due to logic being run in those sectors looking at objects in nearby sectors. Some tasks are multi-threaded, but the scope of these tasks is quite limited and hence the performance gains from high core count CPUs is quite limited.