Friday Facts #209 - Optimisation is a way of life

[ske]

Where's my spiderbot?

It ded.

[NACH0CHEE5E]

Add some more paths like gravel or something that will be cool

[york2dx48]

Great Work! Who cares about new features? I want so many optimisations so that I can run Factorio on my old Thinkpad at 60/60

[hoho]

While we are at it - are you now testing and optimizing also against AMD Zen? They sell like crazy and we would not mind having Factorio properly optimized for them.

Every optimization I've seen talked about applies just as well for AMD as well.

[ske]

Every optimization I've seen talked about applies just as well for AMD as well.

Do you really know your stuff about micro-optimization and have looked at the optimizations they used?

As far as I know, in general, optimization of code helps on all architectures. Until you get down to data structures, caches and branch predictions. This is the level they are at now. What works well on one architecture could hit an edge case on another. You really have to run the tests for all target CPU architectures in order to detect those pesky edge cases. Another essential topic is multithreading. Compared to Intel, the recent AMD CPUs have slower single core speed but make up for that in the number of cores. Depending on how parallelized your program is, it will perform vastly different when comparing CPUs.

[Neemys]

Every optimization I've seen talked about applies just as well for AMD as well.

Do you really know your stuff about micro-optimization and have looked at the optimizations they used?

As far as I know, in general, optimization of code helps on all architectures. Until you get down to data structures, caches and branch predictions. This is the level they are at now. What works well on one architecture could hit an edge case on another. You really have to run the tests for all target CPU architectures in order to detect those pesky edge cases. Another essential topic is multithreading. Compared to Intel, the recent AMD CPUs have slower single core speed but make up for that in the number of cores. Depending on how parallelized your program is, it will perform vastly different when comparing CPUs.

If you read the forum and FFF you should know that they can't implement multi threading and the big problem they have is RAM related not CPU related.

[Sander_Bouwhuis]

I've been following Factorio for about two and a half years now. While I love to see the art improvements and I like to learn of how you've improved the engineering of the game I am still rather saddened that the game itself has barely changed. In terms of gameplay very few things have changed. Maybe my memory is failing me here, but I think the only real differences since I first played the game is that the rocket is actually implemented, there's modular armor, some new combat robots or special grenades or something were added (which I never even used), the size of the turrets changed, signal towers, and maybe a couple other things here and there. There was a lot of work done to have combinators and logic networks in the game, but by the time those become necessary, which I am still not convinced they ever do, you've already long passed what you needed to do to beat the game.

Basically, I've not seen anything interesting in terms of development of the gameplay itself. It saddens me a bit. I know you guys have done some amazing work on the engineering and art, but I am used to following games like Minecraft before Microsoft bought it. If I stopped following for a couple months I would come back and there would be a host of new features added to the game and the very way you played the game had changed. Maybe this is simply that Factorio is nearing the end of its development and that its game design has solidified, but that thought makes me sad. I feel like there are still many more things Factorio could do. More processes that could be explored.
I don't know. I really enjoyed playing Factorio as it exposed me to mining and manufacturing processes I had never considered before. I learned a great deal researching the real world processes that had been presented in a simplified state in Factorio. I guess I was hoping every once in a while I could come back and find something new to learn and play with.

You guys are doing some great work. Truly. There is some good engineering and art being done. I just don't see evidence of anyone working on the game design.

I agree with this message. I LOVE building stuff, but I HATE the researching for the sake of doing more research... to get things that you can use... to do yet more research.

[Patashu]

I've been following Factorio for about two and a half years now. While I love to see the art improvements and I like to learn of how you've improved the engineering of the game I am still rather saddened that the game itself has barely changed. In terms of gameplay very few things have changed. Maybe my memory is failing me here, but I think the only real differences since I first played the game is that the rocket is actually implemented, there's modular armor, some new combat robots or special grenades or something were added (which I never even used), the size of the turrets changed, signal towers, and maybe a couple other things here and there. There was a lot of work done to have combinators and logic networks in the game, but by the time those become necessary, which I am still not convinced they ever do, you've already long passed what you needed to do to beat the game.

...

I believe that the Factorio devs aren't intending to make vanilla Factorio any more complex because
1) the level of difficulty is considered to be about right for first time players, and
2) if you want more difficulty, many mods exist that add it (both old standbys like Bobs/Angels and Space Extension, and new challenges are being made every month, like Py Coal Processing and Xander's Mod)

If you have not yet tried any mods, I recommend you try them out and see how much it changes the game.

[ske]

If you read the forum and FFF you should know that they can't implement multi threading and the big problem they have is RAM related not CPU related.

Is it really that they can't implement multithreading at all or is it that it's complicated due to structural design decisions made in the past?

Do you mean the memory prefetching? That is very much RAM related, yes. But it is even more CPU, cache and branch prediction related. Here, the type of RAM and the interface between CPU and ram and the caching strategy, cache size and the speculative prefetching of the CPU and the interplay between multiple threads all are very important factors. And it's these details where the CPUs may show big differences in performance.

[hoho]

Every optimization I've seen talked about applies just as well for AMD as well.

Do you really know your stuff about micro-optimization and have looked at the optimizations they used?

Considering I am specifically hired to optimize code for the company I work for, yeah, I do dare to say I know my stuff relatively well

As far as I know, in general, optimization of code helps on all architectures. Until you get down to data structures, caches and branch predictions.

Optimizing data structures and cache access helps both CPU families pretty much equally. What factorio devs do, (making data structures smaller, closer in memory and sequental to access) does make things a whole lot better for both CPUs and I can't really see how stuff like that could hit any kind of edge cases. Cache line lengths are the same for both and anything that allows to pull data you'll need in future to caches before you need it helps both.

Another essential topic is multithreading.

Sure but multithreading is a whole new level of optimization and considering Factorio needs to sync up stuff 60x per second and have everything be deterministic, multithreading isn't something that would make that much sense. They do parallelize some parts of the game loop but just chopping the map into pieces to calculate each separately isn't something that would help much considering how much extra work has to be done to make it be deterministic. Amdahl's law is a bitch

Also, as was said, Factorio isn't really limited by computational power but memory bandwidth and latency.

Compared to Intel, the recent AMD CPUs have slower single core speed but make up for that in the number of cores. Depending on how parallelized your program is, it will perform vastly different when comparing CPUs.

I'm well aware of that. Though looking at Steam hardware stats, more than 4 out of 5 PCs are using Intel CPUs and just one out of 20 CPUs has more than 4 cores. It wouldn't make much sense to optimize for *that* small part of the target systems. Especially when there are still optimizations that can be done to make stuff running faster on a single core.

[bobingabout]

I know what you mean with the code.

when I was working on coding for my own project, I used to have similar experiences.

[Neemys]

If you read the forum and FFF you should know that they can't implement multi threading and the big problem they have is RAM related not CPU related.

Is it really that they can't implement multithreading at all or is it that it's complicated due to structural design decisions made in the past?

Do you mean the memory prefetching? That is very much RAM related, yes. But it is even more CPU, cache and branch prediction related. Here, the type of RAM and the interface between CPU and ram and the caching strategy, cache size and the speculative prefetching of the CPU and the interplay between multiple threads all are very important factors. And it's these details where the CPUs may show big differences in performance.

They have implemented a bit of multithreading for 0.16, for some entity that can be done, but it doesn't bring that much performance, over 30% for two CPU. But they can't multi thread the whole game as lots of entity have tie with other and you can't seperate things well to update them at the same time. Knowing that they need to keep the game deterministicas well. Can't find the post talking about it, it was really well explained. Yes you can say it's because of structural design made in the past, but it's what make Factorio Factorio and not FactoryIdle or whatever other game in which you control a factory.

[ratchetfreak]

If you read the forum and FFF you should know that they can't implement multi threading and the big problem they have is RAM related not CPU related.

Is it really that they can't implement multithreading at all or is it that it's complicated due to structural design decisions made in the past?

Do you mean the memory prefetching? That is very much RAM related, yes. But it is even more CPU, cache and branch prediction related. Here, the type of RAM and the interface between CPU and ram and the caching strategy, cache size and the speculative prefetching of the CPU and the interplay between multiple threads all are very important factors. And it's these details where the CPUs may show big differences in performance.

They have implemented a bit of multithreading for 0.16, for some entity that can be done, but it doesn't bring that much performance, over 30% for two CPU. But they can't multi thread the whole game as lots of entity have tie with other and you can't seperate things well to update them at the same time. Knowing that they need to keep the game deterministicas well. Can't find the post talking about it, it was really well explained. Yes you can say it's because of structural design made in the past, but it's what make Factorio Factorio and not FactoryIdle or whatever other game in which you control a factory.

The biggest issue is that there are updates that need to cascade in the same frame across the map, like space freeing up on on the end of a long belt, train rails getting changed, ...

[hreintke]

I am relative new to the game and probably an atypical player.
Using peacefull mode and evem detroying all enemy structures with console when starting a game. I just don't want to fight, only logistics.

That's why I would like to have the logistic robots much more "moddable" .
Would open a way to create mods that update the behaviour of bots and/or the logistic network.

- Assign bots to a specific route
- Have different type of bots acting different (slow, higher payload -> long distance / fast, low payload -> short distance)
- Proritizing chests / routes
- Altenative charging options.
- ....

Don't know whether this or similar is in the pipeline and if the proposed optimization would prevent thsi.

[ratchetfreak]

I am relative new to the game and probably an atypical player.
Using peacefull mode and evem detroying all enemy structures with console when starting a game. I just don't want to fight, only logistics.

you can stop them spawning altogether when creating a map.

[Neemys]

I am relative new to the game and probably an atypical player.
Using peacefull mode and evem detroying all enemy structures with console when starting a game. I just don't want to fight, only logistics.

you can stop them spawning altogether when creating a map.

Specifically, setting the "enemy base" to none (in size)

[Selvek]

God I wish you and your team would go work on the multi-thousand-dollar CAD software I use at work. Imagine factorio...except that every time you add, remove, or edit any entity, there is a 1-2 second lag and a 0.1% chance of crashing. Then pretend you do that 40 hours a week for a job.

At least there are no biters... but I would gladly take them to make the crashes go away!

I think I just died.
Cause of death: Cringing.

Yup.

This is why I spend my time browsing this forum instead of doing real work...

[ske]

Considering I am specifically hired to optimize code for the company I work for, yeah, I do dare to say I know my stuff relatively well

You do seem to know your stuff don't get me wrong. Anybody could have said what you said. It's better to ask if there is substrance behind it.

Optimizing data structures and cache access helps both CPU families pretty much equally. What factorio devs do, (making data structures smaller, closer in memory and sequental to access) does make things a whole lot better for both CPUs and I can't really see how stuff like that could hit any kind of edge cases. Cache line lengths are the same for both and anything that allows to pull data you'll need in future to caches before you need it helps both.

I think you're right. Less memory is less memory. Nothing wrong about that. The architectures must be pretty similar performance-wise because they are designed to execute the same code. The data size is probably big enough that cache size is not the critical factor.

Sure but multithreading is a whole new level of optimization and considering Factorio needs to sync up stuff 60x per second and have everything be deterministic, multithreading isn't something that would make that much sense. They do parallelize some parts of the game loop but just chopping the map into pieces to calculate each separately isn't something that would help much considering how much extra work has to be done to make it be deterministic. Amdahl's law is a bitch

Multithreading and determinism are not mutually exclusive. Also 60 UPS are nothing to be afraid of (I hope). The chopping is probably the problem. They didn't forsee that they have to chop at one point and now everything is designed in a way that makes chopping it into multiple pieces really hard. Maybe it's already too late. The ship has sailed. Burning down the house is inevietable. We'll have to wait for factorio 2.0 in order to unlock the benefits of our 1024 core machines.

Also, as was said, Factorio isn't really limited by computational power but memory bandwidth and latency.

This is bad. This means that multithreading won't bring any benefit at all... unless they have independent memory controllers. Which in turn would mean slow cross-node-memory access.

I'm well aware of that. Though looking at Steam hardware stats, more than 4 out of 5 PCs are using Intel CPUs and just one out of 20 CPUs has more than 4 cores. It wouldn't make much sense to optimize for *that* small part of the target systems. Especially when there are still optimizations that can be done to make stuff running faster on a single core.

Gamers buy intel because games run faster on intel because game makers optimize for intel because gamers buy intel.

I'm not saying to only optimize for AMD or even to focus on AMD but it would be wise to have an AMD test system running to keep an eye on performance issues. They probably already do that.

[hoho]

The chopping is probably the problem. They didn't forsee that they have to chop at one point and now everything is designed in a way that makes chopping it into multiple pieces really hard.

Main problem is, chopping things up and gluing it together itself will cause an overhead even if all other computations remain the same. This means that the benefit gained from multithreaiding has to be decent just to match the non-multithreaded performance.

In addition, having more threads run in parallel will mean more cache polluting. That will most likely harm performance more than making things run in parallel would help.

This means that multithreading won't bring any benefit at all... unless they have independent memory controllers. Which in turn would mean slow cross-node-memory access.

I think on machines that have independent memory controllers, there would be improvement in performance assuming the parts that have to be glued synced up between threads aren't too big.

Gamers buy intel because games run faster on intel because game makers optimize for intel because gamers buy intel.

Sure but there are tons of architectural reasons why Intel CPUs run majority of general-purpose code better than AMD. Similarly to how back in the K8 vs P4 times, AMD had superior architecture.

[ske]

Gamers buy intel because games run faster on intel because game makers optimize for intel because gamers buy intel.

Sure but there are tons of architectural reasons why Intel CPUs run majority of general-purpose code better than AMD. Similarly to how back in the K8 vs P4 times, AMD had superior architecture.

One of the reasons is the average number of instructions per cycle. Here, Intel currently is simply better. But AMD caught up. And the reason I assume why AMD caught up, is that there is a ceiling. With usual algorithms there are only about 3-10 IPS achievable even if you throw quasi infinite resources at the problem. We already burnt about halfway through that and additional (diminishing) gains cost exponentially more resources. AMD will catch up here over the next years. ARM has the edge over x86 in terms of energy efficiency. Regarding manufacturing technology the next step is increasingly expensive. Intel maneuvered itself in kind of peculiar situation where they are king of a hill made from sand and the tides are rising. I really hope we will see something like GaAs make a breakthrough and lead us to 100 GHz processors. People waited for decades for that to happen but Silicon kept on giving and it still does.