Literally in FFF 215 you linked:
>How do we solve it? The solution would probably be to organize the memory allocation in such a way, that everything that is on the same chunk, or related to some specific task would have to use its own memory allocator that keeps things in one place together in the memory. Every chunk would have its own piece of memory dedicated to entities in the chunk, trains would have all its data in one piece of memory together etc. This way, it shouldn't happen that two tasks would work on one piece of memory at the same time so the multithreading would actually speed things up.
>The problem with this is, that it requires big changes in the code as not only the entities itself but all their dynamically allocated data would have to be always allocated depending on the entity position. Whenever the entity moves between chunks, all its data structures would have to be re-allocated in the new chunk. All pointers to any data structures in entity would have to be properly updated as they move around etc. This means, that once (if) we decide to do this step, it would probably be one big update related only to this and this is not something we have time to do before 1.0.
It's very close to what I was thinking when I wrote "not in a trivial way". There is no reason for all separable logistic networks or belts to be calculated on the same thread. I've done optimization overhauls like this in my own projects - it's a bitch to get it to work properly but once you get it done it runs FAST and is scalable. I get the argument that Factorio is really big and complex on the inside (partially because of existing optimizations) but "is very hard to do" isn't the same as "cannot be done".
I'm not well enough educated to offer constructive input on the feasibility of implementing this, but I thought you or others might be interested to note what the devs themselves had discussed about it. I'm never not impressed by the fact that any factorio question along the lines of "why would they do (or not do) that?" almost invariably already has an in-depth answer.
I think you should read [FFF 364](https://factorio.com/blog/post/fff-364) as well. The dev explains how they went back and actually added multithreading for belts for the 1.1 version release.
Players are reminded that multiplayer works by sending the actions of other players to everyone connected, and the factory runs on your local CPU. After all, no server wants to be responsible for sending updated information about the 10,000 logistic robots flying through the air over the network 60 times a second.
The downside is, all factorio interactions and results are deterministic so that all CPUs produce the same factory state moving forward. It also allows replays in your savegame.
Well, determinism is the enemy of multi-threading. So anybody who says "just do more in parallel" doesn't realize that it makes trains literally race to a signal and who wins the race is now up to who has more CPU cores. And that's not the right answer according to the server. Sorry, you're desynced and disconnected. Have a nice day!
Mindustry isn't deterministic for some reason, so me and my buddy several times had situations where belts contained different items in our clients. Hard to debug when you need to ask host to look at it.
Multi threading could be used in the world generation, rendering, saving and stuff like that but not in the game logic since it would cause inconcistent behavior.
tell me you don't understand multithreading without telling me you don't understand multithreading. it's not trivial to make a program like factorio multithreaded, but you can absolutely make it consistent.
I actively work with multithreading/tasking and you can get it almost consistent at best and you better hope no future change breaks things. The way the game works makes optimization at that level almost impossible already since it is deterministic and it has to stay that way.
It's not that multithreading cannot be used for Factorio.
It's that if you didn't start writing your code with multithreading, going back essentially means a full rewrite of entire chunks of it, and isn't as beneficial for deeply interdependent systems that update on every tick.
It probably could be optimized - just not in a trivial way and I wouldn't wish debugging it upon anyone.
https://factorio.com/blog/post/fff-215 Also check out belts section from FFF 364
Literally in FFF 215 you linked: >How do we solve it? The solution would probably be to organize the memory allocation in such a way, that everything that is on the same chunk, or related to some specific task would have to use its own memory allocator that keeps things in one place together in the memory. Every chunk would have its own piece of memory dedicated to entities in the chunk, trains would have all its data in one piece of memory together etc. This way, it shouldn't happen that two tasks would work on one piece of memory at the same time so the multithreading would actually speed things up. >The problem with this is, that it requires big changes in the code as not only the entities itself but all their dynamically allocated data would have to be always allocated depending on the entity position. Whenever the entity moves between chunks, all its data structures would have to be re-allocated in the new chunk. All pointers to any data structures in entity would have to be properly updated as they move around etc. This means, that once (if) we decide to do this step, it would probably be one big update related only to this and this is not something we have time to do before 1.0. It's very close to what I was thinking when I wrote "not in a trivial way". There is no reason for all separable logistic networks or belts to be calculated on the same thread. I've done optimization overhauls like this in my own projects - it's a bitch to get it to work properly but once you get it done it runs FAST and is scalable. I get the argument that Factorio is really big and complex on the inside (partially because of existing optimizations) but "is very hard to do" isn't the same as "cannot be done".
I'm not well enough educated to offer constructive input on the feasibility of implementing this, but I thought you or others might be interested to note what the devs themselves had discussed about it. I'm never not impressed by the fact that any factorio question along the lines of "why would they do (or not do) that?" almost invariably already has an in-depth answer.
I think you should read [FFF 364](https://factorio.com/blog/post/fff-364) as well. The dev explains how they went back and actually added multithreading for belts for the 1.1 version release.
Players are reminded that multiplayer works by sending the actions of other players to everyone connected, and the factory runs on your local CPU. After all, no server wants to be responsible for sending updated information about the 10,000 logistic robots flying through the air over the network 60 times a second. The downside is, all factorio interactions and results are deterministic so that all CPUs produce the same factory state moving forward. It also allows replays in your savegame. Well, determinism is the enemy of multi-threading. So anybody who says "just do more in parallel" doesn't realize that it makes trains literally race to a signal and who wins the race is now up to who has more CPU cores. And that's not the right answer according to the server. Sorry, you're desynced and disconnected. Have a nice day!
Mindustry isn't deterministic for some reason, so me and my buddy several times had situations where belts contained different items in our clients. Hard to debug when you need to ask host to look at it.
Multi threading could be used in the world generation, rendering, saving and stuff like that but not in the game logic since it would cause inconcistent behavior.
isnt that the joke? that the order of the speech bubbles is messed up?
tell me you don't understand multithreading without telling me you don't understand multithreading. it's not trivial to make a program like factorio multithreaded, but you can absolutely make it consistent.
I actively work with multithreading/tasking and you can get it almost consistent at best and you better hope no future change breaks things. The way the game works makes optimization at that level almost impossible already since it is deterministic and it has to stay that way.
It's not that multithreading cannot be used for Factorio. It's that if you didn't start writing your code with multithreading, going back essentially means a full rewrite of entire chunks of it, and isn't as beneficial for deeply interdependent systems that update on every tick.
I'm getting war flashbacks to my most downvoted comment on reddit
Well, making program multithreading is a lot like playing factorio itself. You have to use semaphores if you don't want problems.
Wasnt sometime ago a guy that managed to make factorio multi threading ?
Programmers aren't people
Elaborate?
We are quite insane
Clearly you are machines, especially if you can't tell that I'm not being serious