Parrallel processing in games & applications

Post all other topics which do not belong to any other category.
Rseding91
Factorio Staff
Factorio Staff
Posts: 11882
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Parrallel processing in games & applications

Post by Rseding91 »

elfstone wrote:
Mon Feb 08, 2021 6:03 pm
... 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.
If you want to get ahold of me I'm almost always on Discord.

Guenni7
Fast Inserter
Fast Inserter
Posts: 143
Joined: Thu May 18, 2017 5:53 am
Contact:

Re: Parrallel processing in games & applications

Post by 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
Global Moderator
Global Moderator
Posts: 6477
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Parrallel processing in games & applications

Post by Koub »

Guenni7 wrote:
Tue Feb 09, 2021 3:40 am
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.
Koub - Please consider English is not my native language.

User avatar
Challenger007
Inserter
Inserter
Posts: 26
Joined: Wed Feb 03, 2021 2:01 pm
Contact:

Re: Parrallel processing in games & applications

Post by Challenger007 »

Guenni7 wrote:
Tue Feb 09, 2021 3:40 am
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
Factorio Staff
Factorio Staff
Posts: 5033
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Parrallel processing in games & applications

Post by posila »

Guenni7 wrote:
Tue Feb 09, 2021 3:40 am
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
Fast Inserter
Fast Inserter
Posts: 143
Joined: Thu May 18, 2017 5:53 am
Contact:

Re: Parrallel processing in games & applications

Post by Guenni7 »

posila wrote:
Tue Feb 09, 2021 2:17 pm
Guenni7 wrote:
Tue Feb 09, 2021 3:40 am
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 :lol:

Rseding91
Factorio Staff
Factorio Staff
Posts: 11882
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Parrallel processing in games & applications

Post by Rseding91 »

Guenni7 wrote:
Tue Feb 09, 2021 7:37 pm
posila wrote:
Tue Feb 09, 2021 2:17 pm
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 :lol:
That's a great way to over-work and stress yourself out. Not a good idea.
If you want to get ahold of me I'm almost always on Discord.

Trific
Fast Inserter
Fast Inserter
Posts: 122
Joined: Thu Dec 31, 2020 7:57 pm
Contact:

Re: Parrallel processing in games & applications

Post by Trific »

Challenger007 wrote:
Tue Feb 09, 2021 2:02 pm
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.

Post Reply

Return to “General discussion”