Parrallel processing in games & applications

[nafira]

[Koub] Merged into the older discussion about how the devs should multithread the game.
I suggest you read the whole thread, especially the devs' answers.

Oh, I read a bunch of answer, and I didn't know war existed :/

As I see it, there's no intention of bringing Factorio to multi-threading since it can only benefit to those with big rigs and would make it worse for lower end hardware.
In addition to that, the release is quite stable and optimized (nobody can deny it), and breaking all those optimization into smaller pieces doesn't seem to be worth it.

I know that things like pipes are multi-threaded, thank to a better algorithm and the end of fluid mixing. Same for belts.
Still, I wonder how much percentage of simple entities like inserters or bots can be parallelized...without breaking the current state.

[Koub]

Well the thing is that many people believe the devs haven't given enough thought to multithreading. The least I can do is ensure those people know the devs have tried to paralellize as much as possible, and that multithreading is not some kind of magic that works "just like that". The devs have also been able, after improving some aspects of the engine, to parallelize a few more things, typically the 0.18 update comes with :

Electric networks, fluids, and heat pipes are updated in parallel if you have enough cores.

Source
Which is just another proof that they haven't given up and will parallelize every time they find the opportunity to do so.

I'm not saying nobody can have an idea the devs haven't had, just that it's as unlikely as teaching a neurochirurgist how to operate a brain in a better way than he usually does : unlikely.

[BlueTemplar]

As I see it, there's no intention of bringing Factorio to multi-threading since it can only benefit to those with big rigs and would make it worse for lower end hardware.

As someone that is on a 8-core FX-8320E (or is that considered "4 cores" now ?) that is slowly slipping into the low-end, I disagree !
But yeah, multithreading is hard - so progress was slow since Supreme Commander 1 in 2007 has shown that having more than 1 core could indeed help with game performance !

Within a max 16~ millisecond time window (1 tick) there is very little room for threading to work. Something has to be incredibly slow for it to start taking up the majority of that time window and by the time that happens the time window is filled with "the entire game" so even if you do some how manage to take something that's consuming 1/4th of the time and make it take 1/4th again by running it on 4 threads (most systems don't have 4 spare threads and most tasks don't become 4 times faster by running on 4 threads) you still don't see a global 4x speedup in time-spent-per-tick.

What you do see a lot of the time is fragile and un-maintainable code with lots of bugs, race conditions, and maybe even worse performance in the typical case when you didn't hit that magical "used 4 milliseconds before adding threads" case.

Threads have their uses but injecting them into the middle of a tight game logic loop has not been one that seems to make sense to me in the 4+ years I've been working on Factorio. Looking around and asking/talking with other game developers I've yet to meet one who has done that. They all use threads - we do as well - but they don't stick them in the middle of their tight game logic update loop.

If someone has manged to do it - and benefited largely from it. I would LOVE to talk to them and see how they did it and what kinds of gains they've gotten from it. I think I could learn so much from them (if they exist).

(Note that SupCom1 uses : )

There are two major threads in FA:
sim - all simulation and AI
ren - all rendering and UI
those two eat the most performance, each on different core. The rest of the threads for sounds and what not wont take more than 5%

(So AFAIK you don't get much performance improvement over tri-core in it ?)

[TheTom]

> Factorio to multi-threading since it can only benefit to those with big rigs

Actually no. This is 2020. Multithreading CAN benefit anyone with any sort of computer bought in the last years. Make it 3. You will have SERIOUS trouble finding anything on dekstops that has less than 4 cores around that time, more like 8. And if you buy nowish - 8 to 16 cores seems to get the norm now, thanks to our friends of AMD.

Since Threadripper "big rig" would mean 16+ cores. And those start to cost. But seriously, you live like 5-7 years in the past if you assume dual core on a desktop.

[Rseding91]

> Factorio to multi-threading since it can only benefit to those with big rigs

Actually no. This is 2020. Multithreading CAN benefit anyone with any sort of computer bought in the last years. Make it 3. You will have SERIOUS trouble finding anything on dekstops that has less than 4 cores around that time, more like 8. And if you buy nowish - 8 to 16 cores seems to get the norm now, thanks to our friends of AMD.

Since Threadripper "big rig" would mean 16+ cores. And those start to cost. But seriously, you live like 5-7 years in the past if you assume dual core on a desktop.

Servers throw all that out the window and typically have 1 core available for a given server that runs. So, what ever threading logic we write always has to assume it can run on a system with only 1 core.

[bobucles]

Threading clearly implies a well of bottomless CPU potential and infinite UPS gains, at least to the ordinary person. Unfortunately, it isn't free. There is a meta cost of supporting algorithms that is inherent to threading, and one of big advantages of modern CPUs is they are optimized to pay a lower cost for it.

The FFFs do have some good insight into how the devs look for threading boosts. For example, the liquid and heat pipe game mechanics are far removed from other game mechanics. You can't connect pipes to belts or bots or train pathing, as such the pipe system has a high degree of independence from other parts of the game core. That makes it a great choice to split off into its own thread. The meta costs are low because it's one more thread, and the extra core gains a lot more utility because the new thread can process a big work load.

There is also a more sloppy approach of just throwing more threads at the problem. Throw enough monkeys on typewriters and you will eventually get some good poetry, right? In a similar manner, a dogpile of threads will eventually lead to some shortcuts that boost real time performance. The tradeoff is that the meta costs end up being enormous, a cheap cost multiplied by a big mess is still a big mess. Larger, multicore CPUs have no problem performing the extra work load that allows all the threads to be functional, so they can make use of the extra benefit. Peel a few CPUs away however, and all that extra work provides no benefit. An ornate setup which lets an application run across 30 CPUs is pretty pointless if there's only 1 CPU available, after all.

In any event, there's going to be no exact solution to the threading problem.

[BlueTemplar]

Oh, also, the Mantle/Oxide/Vulkan/DX12-based Ashes of the Singularity (2016) boasted being "the first multi-threaded RTS" (or something in that vein), though AFAIK it "only" split graphics on one hand and AI on the other into multiple threads, leaving the simulation still single-threaded ?
(And it seems that it hardly has any gameplay-affecting physics, going so far as to turn off collision for allied units - which is fine for Factorio's biters, but very disappointing for a RTS..?)

[bobucles]

I mean, by that definition Supreme Commander (2007) is also a multi-threaded RTS. The video renderer ran separately from the main sim, and there were a handful of other bits and pieces on the side. I used to comment that it was a 2.5 core game, but the big bottleneck was clearly the main sim. There's definitely even more games before then, if someone looked hard enough.

RTS games have a very high level of difficulty for threading. Every unit in the world interacts with each other in some way, and abilities can create unusual behaviors on top of that. It doesn't really lend itself to concurrent programming, at least not in any easy way.

[BlueTemplar]

See my post just a few posts above for SupCom1. The claim seems to apply to the fact that *this time*, Nitrous' Oxide managed to *also* split AI into multiple threads and graphics into multiple threads (and massively so, for graphics).
I'm not aware of any RTS (or similar, like Factorio) that would have managed to split simulation successfully. (Well, Factorio now kind of did, with parallel fluids. Still a fairly small part of the overall simulation.) (And besides a small Spring project that claimed to do so that I can't even find these days and that ran into licensing troubles.)

[nafira]

I'm not saying nobody can have an idea the devs haven't had, just that it's as unlikely as teaching a neurochirurgist how to operate a brain in a better way than he usually does : unlikely.

Not a neurochirurgist.
But from a dev to another dev using different kind of applications and having different bottlenecks.

They can't do my job, I can't do theirs, but we can give ideas to each other. That's how computing always progress. And I'm pretty sure of that, this isn't just "unlikely".
I posted my topic because I didn't know that one existed, and wanted to create a topic to exchange ideas. I think there's a FFF on that, where they took and thanked someone for an improvement.

Anyway, I was just sharing ideas. I know that multi-threading goes with a shit load of problems. I work with Databases every day.
So parallel query is kind of my too, just the opposite way.
Factorio has to "finish" a frame under 16ms while I have to size properly resources given to a query (when doing fine tuning).

It's unless to give 20 core to process a 20 line table, because you'll lose all your time splitting and merging calculations. On a 20M line table, you can start to consider how much resources you'll give : 4 ? 6 cores ?
If you have subqueries, don't you want to give them more horsepower and less to others ? It could be interesting


Anyway, 1.0 is coming, it's not the right time

[mudcrabempire]

Idk too much but when I hear the term "multithreading" I only really think about tasks that are properly parallelizable and would therefore benefit from an arbitrary number of processors. Point in case, the factor of speed you can gain from multithreading is at most the number of cores you have, in any serious instances it is much less. So multithreading from 1 to 8 cores may not even double your speed. If the computation time of your application is dominated by one or two tasks that are massively parallelizable you can think about GPU computing (this is not the case for factorio as far as I've gathered and I'm not sure how that works on servers, probably it doesn't). Otherwise, regular improvements of algorithms are most likely much more worth the effort (and multithreading is no excuse for bad code so you should do that anyways).

[mrvn]

Oh, also, the Mantle/Oxide/Vulkan/DX12-based Ashes of the Singularity (2016) boasted being "the first multi-threaded RTS" (or something in that vein), though AFAIK it "only" split graphics on one hand and AI on the other into multiple threads, leaving the simulation still single-threaded ?
(And it seems that it hardly has any gameplay-affecting physics, going so far as to turn off collision for allied units - which is fine for Factorio's biters, but very disappointing for a RTS..?)

Hell, any game on linux is multithreaded by that definition. Even better, it's multi-processing. There is the game and then there is X doing the actual graphics rendering.

[BlueTemplar]

Oh, so X can split itself among an arbitrary number of CPU threads ? Nice !

[mrvn]

Oh, so X can split itself among an arbitrary number of CPU threads ? Nice !

No. The context was 2 threads.

[BlueTemplar]

No, it wasn't ?
https://hardforum.com/threads/dx12-gpu- ... k.1872730/

o6LAYRL.png (275.12 KiB) Viewed 5496 times

(Overhyped, but clearly NOT single-thread for rendering !)

[mrvn]

That clearly then not just a split of graphics into one thread and AI into a second thread. Unless you mend one thread per AI and the AIs are what is causing all the load.

Note: Factorio splits rendering (the preparation part the CPU does) into N threads too. You can set N in the settings. It's usually not the bottleneck.

[BlueTemplar]

You misunderstood what I wrote :

[...] AFAIK AotS"only" split graphics on one hand and AI on the other into multiple threads, leaving the simulation still single-threaded ?
[...]

= multiple threads for graphics
+ multiple threads for AI
+ 1 thread for simulation
(+ lots of tiny threads for other stuff like audio (I hear even SupCom1 had 20+ of those ?))

[wanne]

Oh, so X can split itself among an arbitrary number of CPU threads?

Yes. You just need an arbitrary number of displays . You can configure Xorg to use one thread for everyone. Add Xinerama and all is used for one application.
But with only one display: Not an arbitrary number. But with Xorg three. A design goal of X was to be able to run multiple programs (which can run on different cores) by sharing the same graphic primitives. (What was a huge benefit in a time before shared libraries.)
So if you type 4 an in xcalc the application will be using one process (with one thread) to calculate where the number should be drawn. The Xorg will use one thread for how the number looks like and one for processing the input (making them two.)
Problem is: This dos not apply when you are using direct rendering. (Like all modern applications) Then your application will do all the calculation.

[BlueTemplar]

Speaking of which, any way to have multiple Factorio instances share as much "stuff" as possible ?
(I'm especially thinking of atlases in VRAM, anything else ?)

[mrvn]

Speaking of which, any way to have multiple Factorio instances share as much "stuff" as possible ?
(I'm especially thinking of atlases in VRAM, anything else ?)

Linux can merge physical pages with the same content in main memory. I'm not sure if that also works on memory shared with a GPU but I highly doubt it. I doubt you can make that work sanely without help from factorio itself.