Parrallel processing in games & applications

[Rseding91]

... it might be possible to run different surfaces on different cores, since events on one surface don't interact with things on other surfaces, which should make multi threading a lot easier.

Events are global; Lua events even more so. So they do interact with everything regardless of surfaces. Surfaces in fact are nothing special except more chunks. Very little is actually seperate per-surface. The entirety of force-related anything is global, events are global, player stuff is global.

Also one of the arguments in the beginning of this thread was, that normal CPUs don't have many cores, and only high end machines would profit. Now that even entry level CPUs like Ryzen 5600 have 6/12 cores/threads that argument won't hold for much longer, and since you're planning with a timescale of about a year, those will have quite some market share.

Factorio is not limited by cores; it's limited by memory access; cache and latency of getting data in and out of the CPU. The threading of belts reinforced this since updating them fully saturates the available cache and caching logic on even the fastest CPUs we have available to test. Running more things in parallel gives no improvements to speed at that point.

[Guenni7]

I'm not a programmer, but given the fact that on most mega-bases the bots are the most time consuming items, why wasn't they multithreaded before engine development was called finished? Multithreaded Belts are nice, but don't help any real mega-base.

[Koub]

I'm not a programmer, but given the fact that on most mega-bases the bots are the most time consuming items, why wasn't they multithreaded before engine development was called finished? Multithreaded Belts are nice, but don't help any real mega-base.

Maybe because multithreading even more would not have any impact ? See the post just above yours.

[Challenger007]

I'm not a programmer, but given the fact that on most mega-bases the bots are the most time consuming items, why wasn't they multithreaded before engine development was called finished? Multithreaded Belts are nice, but don't help any real mega-base.

It seems to me that a different algorithm is needed here, not multithreading. I am not a programmer either, but I understand a little that in the modern world new and new methods of implementing complex tasks regularly appear.

[posila]

I'm not a programmer, but given the fact that on most mega-bases the bots are the most time consuming items, why wasn't they multithreaded before engine development was called finished? Multithreaded Belts are nice, but don't help any real mega-base.

In short, at any point of the development, there are and will be people that can say "Why don't you make <a thing that affects me negativelly in some way> better?"

[Guenni7]

I'm not a programmer, but given the fact that on most mega-bases the bots are the most time consuming items, why wasn't they multithreaded before engine development was called finished? Multithreaded Belts are nice, but don't help any real mega-base.

In short, at any point of the development, there are and will be people that can say "Why don't you make <a thing that affects me negativelly in some way> better?"

As a programmer you should take that as a challenge

[Rseding91]

In short, at any point of the development, there are and will be people that can say "Why don't you make <a thing that affects me negativelly in some way> better?"

As a programmer you should take that as a challenge

That's a great way to over-work and stress yourself out. Not a good idea.

[Trific]

It seems to me that a different algorithm is needed here, not multithreading. I am not a programmer either, but I understand a little that in the modern world new and new methods of implementing complex tasks regularly appear.

Virtually all of the advances in software methods have been enabled by faster hardware, and the software advances dumb down and make it easy for garden variety programmers to orchestrate complex tasks without shooting themselves in the foot (and yet, still somehow they manage). This dumbing down and complex orchestration comes at the expense of performance, because now you have lots of automated checks to make sure you're not shooting yourself in the foot.

Wube have made the decision to not use most of those pillows, restraints, and training wheels in order to squeeze as much performance out of the system as possible. Not shooting yourself in the foot when doing that is a matter of deep knowledge of what you are doing, and the exercise of discipline to avoid tempting shortcuts. The amount of performance they have managed while not shooting themselves in the foot is breathtaking, and my hat is off to them.

Programming for multithreading is a bit like designing a train network in Factorio. In both cases you have to avoid deadlocks. Except in a program, you may have millions or billions of trains each carrying a unique cargo, and you're up against the constraints that you can't have two trains carrying the same cargo, and no amount of throwing extra trains or fancy signaling at the problem is going to get a single cargo somewhere any faster than the max speed of the train.

[NotoriousPyro]

[...]it may appear like multithreading is hard[...]
[...]asynchronous code[...]

I stopped reading when you mentioned the two in the same paragraph. Asynchronicity is not the same as multithreading. It is important to distinguish between the two...

Your misunderstanding is extremely common. Many people are taught that multithreading and asynchrony are the same thing, but they are not.

An analogy usually helps. You are cooking in a restaurant. An order comes in for eggs and toast.

Synchronous: you cook the eggs, then you cook the toast.
Asynchronous, single threaded: you start the eggs cooking and set a timer. You start the toast cooking, and set a timer. While they are both cooking, you clean the kitchen. When the timers go off you take the eggs off the heat and the toast out of the toaster and serve them.
Asynchronous, multithreaded: you hire two more cooks, one to cook eggs and one to cook toast. Now you have the problem of coordinating the cooks so that they do not conflict with each other in the kitchen when sharing resources. And you have to pay them.

https://stackoverflow.com/a/34681101/3812928

If you can do it so easily then why don't you apply for a job and do it? If you want it so bad you would do it for free if it's so easy.

[ssilk]

The threading of belts reinforced this since updating them fully saturates the available cache and caching logic on even the fastest CPUs we have available to test.

I have a stupid question: when updating the items on the belts, are you updating every single item or do you have “sections” (many items on a section) where you know the time when an entity entered and then update just the offset to that time?

(When I look into the debug mode and think about some FFF some years ago I think the later, but how can I be sure? )

[Rseding91]

The threading of belts reinforced this since updating them fully saturates the available cache and caching logic on even the fastest CPUs we have available to test.

I have a stupid question: when updating the items on the belts, are you updating every single item or do you have “sections” (many items on a section) where you know the time when an entity entered and then update just the offset to that time?

(When I look into the debug mode and think about some FFF some years ago I think the later, but how can I be sure? )

https://www.factorio.com/blog/post/fff-176 just the last item on the belt that can move.

[ssilk]

Thank you. This gives me some thought:

Which technically this means incrementing/decrementing two integers instead of incrementing the position of all 200 items on those belts.

To avoid this incrementation (and the need to even read/write storage, which is the true bottleneck — as you said) you just need to know these two things: a position and the time it is or will be at this position. Because the belts have a constant speed you can calculate the actual position of the items at any time in this segment without any further memory access. You just need to put the items from one segment to the other, when their time in the segment “is over”. But you know for this next segment already, when that time for moving it to the further next segment will come.

For displaying the items and calculate them for the inserters, you have the same effort as before (let’s say you store the time this item will leave this segment): take leave-time (in future) minus current time, then you know exactly the position of the item on the segment, without reading the position of any item.

[ssilk]

I read this again and must say, that this is only true, if you have fixed segments, the segments themselves don’t move.

But the general idea will work also with them: you can move the segments by having a fixed point on the belt in the future and measure the time it takes for the item/segment/whatever to reach that point.

Until then no further memory access is needed; only to check if the time is reached, but that can be done with a (sorted) stack, where you need only to check the top element, because all others a farther into the future.

[BenSeidel]

Your misunderstanding is extremely common. Many people are taught that multithreading and asynchrony are the same thing, but they are not.

I disagree. Asynchronous means non-sequential programming, of which multithreading is one type. Or to be more specific, multithreading is a sub-set, or implementation, of Asynchronous programming.

The misunderstanding is that multithreading is the same as Parallel execution. The stackoverflow answer you sited makes this mistake. In their example they give for multithreading they employ another chef. This means they are using more physical resources. You can have a multithreaded application running on a single CPU (or Core to be more specific) system as there is no link between the number of threads and the resources (cores) available. Again, because multithreading is a particular set of implementations that are "Asynchronous".

Please remember, Threads are a virtual CPU. They don't relate what-so-ever to physical resources. All asynchronous libraries do the same thing - they supply you with something that will execute your code, exactly like a thread does.

Personally, I don't like the term "Asynchronous programming" as it's too broad a term. I think it was invented because "non-sequential" didn't sit well with the marketing department.

Also,
Welcome to the forums.

[ssilk]

I see a small difference here. In my mind an asynchronous programmming language like JavaScript/nodesj (which uses only one core per “worker”) provides functionality to handle cpu efficient asynchronous execution of code with strong focus to fast response. While threading is done to scale that.

Java is threading (and you can say you can use it asynchronously), NodeJs is asynchronous.
Or take PHP : definitely not asynchronous nor multithreaded per se, but there are parts which can be used asynchronous and other parts which can used multithreaded.

I don’t think it’s a synonym, more like two techniques. One optimizes the cpu-usage for fast response, the other optimizes the handling of many CPUs.

[Jap2.0]

I read this again and must say, that this is only true, if you have fixed segments, the segments themselves don’t move.

But the general idea will work also with them: you can move the segments by having a fixed point on the belt in the future and measure the time it takes for the item/segment/whatever to reach that point.

Until then no further memory access is needed; only to check if the time is reached, but that can be done with a (sorted) stack, where you need only to check the top element, because all others a farther into the future.

If I'm reading this correctly, you're suggesting that instead of recording two offsets and updating one (or both) each tick, they should just record the offsets at one point in time and when that time is/when items will reach the end of the segment?

I have no idea how any of this works internally, but the potential issue I see with that is that something would still need to change so they can render the items moving. That said, I have no idea how they render it without having the position of each individual item as is (particularly around corners). Does render preparation include finding the position of each individual item visible on a belt?

[BenSeidel]

I don’t think it’s a synonym

Yes, that's correct. I misspoke. I have corrected my previous post to reflect that.

[ssilk]

I have no idea how any of this works internally, but the potential issue I see with that is that something would still need to change so they can render the items moving.

Yes and no. You need to do that calculation of item-positions only for the belts currently visible.

https://www.factorio.com/blog/post/fff-176 shows how the items are already not individualized, but they are part of a segment and to render them you need to look inside of the segment and individualize them.

The same is it with this idea: you have a segment of belts with items on it, you know when each item in the segment will leave that segment and you know the current time. With that information you can calculate the positions of each item on that segment, to individualize it for rendering.

[Jap2.0]

Yes and no. You need to do that calculation of item-positions only for the belts currently visible.

...

The same is it with this idea: you have a segment of belts with items on it, you know when each item in the segment will leave that segment and you know the current time. With that information you can calculate the positions of each item on that segment, to individualize it for rendering.

Hmm, I had considered that briefly but I guess I never wrote it in my post. That explains why grouping items into segments is still beneficial despite having to render items individually - you're only rendering a small portion of all the items on belts, especially in larger factories (where it matters most).

I think that your idea could be a theoretical improvement, but I'm not sure how much it would be practically beneficial due to:

• More code complexity (probably the big one).
• More complicated to compute the position of one item, due to the additional factor of time. (That said, that's probably what, a multiplication and an addition? So potentially minimal.)
• How many belt segments go a significant amount of time moving, but without having items either added or removed? My understanding is that belt segments already sleep (probably not the proper technical term) if they aren't moving, and if items are added or removed you would need to either calculate or update (depending on the situation) the initial offset (and potentially other positions in the segments) anyway. Maybe that situation's more common than I think. (That said, even changing a few times a second is a significant reduction in the number of updates.)

[BlueTemplar]

The rendering isn't going to be a performance bottleneck anyway... (unless maybe on very low power integrated graphic chips ?)
And of course, as already mentioned, it's already fully multithreaded.

----

So this claim seems to be now dubious to me :

I'm not a programmer, but given the fact that on most mega-bases the bots are the most time consuming items, why wasn't they multithreaded before engine development was called finished? Multithreaded Belts are nice, but don't help any real mega-base.

I would assume that (fully compressed !!) belts are much better these days - not only logibots seem to be more complex ("path"finding, recharging, picking chests...), but :

An uninterrupted blue belt is two entities, each with up to
200 tiles * 4 items / tile * 3 pixels / tick * 60 ticks / s / 32 pixels * tile
= 200 tiles * 22.5 items / s * m / tile
= 4500 items * m / s

Even before multithreading, what kind of insane Worker Robot Speed tech level would you even need to approach this ?!