It ded.bobucles wrote:Where's my spiderbot?
![Neutral :|](./images/smilies/icon_neutral.gif)
It ded.bobucles wrote:Where's my spiderbot?
Every optimization I've seen talked about applies just as well for AMD as well.TheTom wrote: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.
Do you really know your stuff about micro-optimization and have looked at the optimizations they used?hoho wrote:Every optimization I've seen talked about applies just as well for AMD as well.
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.ske wrote:Do you really know your stuff about micro-optimization and have looked at the optimizations they used?hoho wrote:Every optimization I've seen talked about applies just as well for AMD as 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. 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.
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.BigDub wrote: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 believe that the Factorio devs aren't intending to make vanilla Factorio any more complex becauseBigDub wrote: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.
...
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?Neemys wrote: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.
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 wellske wrote:Do you really know your stuff about micro-optimization and have looked at the optimizations they used?hoho wrote:Every optimization I've seen talked about applies just as well for AMD as well.
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.ske wrote: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.
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 bitchske wrote:Another essential topic is multithreading.
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.ske wrote: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.
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.ske wrote: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?Neemys wrote: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.
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.
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, ...Neemys wrote: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.ske wrote: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?Neemys wrote: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.
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.
you can stop them spawning altogether when creating a map.hreintke wrote: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.
Specifically, setting the "enemy base" to none (in size)ratchetfreak wrote:you can stop them spawning altogether when creating a map.hreintke wrote: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.
Yup.Jap2.0 wrote:I think I just died.Selvek wrote: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!
Cause of death: Cringing.
You do seem to know your stuffhoho wrote: 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![]()
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.hoho wrote: 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.
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.hoho wrote: 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![]()
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.hoho wrote: Also, as was said, Factorio isn't really limited by computational power but memory bandwidth and latency.
Gamers buy intel because games run faster on intel because game makers optimize for intel because gamers buy intel.hoho wrote: 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.
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.ske wrote: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.
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.ske wrote: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.
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 wrote:Gamers buy intel because games run faster on intel because game makers optimize for intel because gamers buy intel.
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.hoho wrote: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 wrote:Gamers buy intel because games run faster on intel because game makers optimize for intel because gamers buy intel.