Why an optimization update is likely

[cpy]

Factorio is the ONLY game where you can have insanely impactful benchark when using different ram speeds!

 

i7-8700K OC 5.0 GHz (cache 5 GHz) + DDR4 4133 MHz (17-17-17-36-2T) - 200 UPS

i7-8700K OC 5.0 GHz (cache 5 GHz) + DDR4 3800 MHz (16-17-17-36-1T) - 176 UPS

Yep the only game i know that is ram speed starved

[Gurgel]

4 hours ago, Nightinggale said:

That's not true. Depending on the type of task it might not be doable to spread it across more CPU cores.

Some problems cannot be parallelized at all due to fundamental limitations. For others, in most cases communication and coordination will eat your performance at pretty low core cumbers. You can still use more cores, but you will get a speed-up below 1 (things get slower). The other limiters will be decreasing cache effects and memory I/O limits. And for complex algorithms, like path-finding or multi-party scheduling under real-time conditions, the speed-up for more cores begins to drop massively on pretty low core numbers and sometimes already when you use more than one. 

If that were not the case, the early massive multitasking architectures (for example the Connection Machine and the Transputer Systems) would rule computing now. The hardware was there and was capable. Except for a few specialized simulation tasks (mostly finite-elements) parallelization does not help that much. Even for something like ONI, you probably start to not gain anything anymore around 8-16 cores from fundamental limitations (i.e. nothing can be done). In actual reality, optimizing code to that degree is not only extremely hard and time-consuming, it massively limits the flexibility to do anything new.

Sorry folks, but the computing speed revolution is basically over and has been for a while. They are currently just moving stuff from the high-end to the consumer. But the high-end is not getting faster anymore. That parallel computations will not help that much in most situations has become clear 20-30 years ago when many fundamental and practical limits were found and the whole euphoria about parallelism died a pretty gruesome death. 

9 minutes ago, cpy said:

Factorio is the ONLY game where you can have insanely impactful benchark when using different ram speeds!

 

i7-8700K OC 5.0 GHz (cache 5 GHz) + DDR4 4133 MHz (17-17-17-36-2T) - 200 UPS

i7-8700K OC 5.0 GHz (cache 5 GHz) + DDR4 3800 MHz (16-17-17-36-1T) - 176 UPS

Yep the only game i know that is ram speed starved

That is impressive! Also the hallmark of a problem that parallelized extremely well (lots of small, weakly coupled components).

[Nightinggale]

53 minutes ago, Gurgel said:

The other limiters will be decreasing cache effects and memory I/O limits.

It's an open question how Ryzen Zen 2 affects this. They consist of a component called Core Complex (CCX). Each CCX consist of 4 cores*, 8 threads with 16 MB level 3 cache. You can then get CPUs with 2 or 4 CCXs allowing a total of 16 cores and 64 MB cache. However it seems a CCX can't read the cache from another CCX. This means using a lot of threads will not hit the cache usage in the same way as on CPUs where there is one shared cache for all cores. Also what does this mean for stuff like thread locking? Is there some sort of shared level 4 cache for that?

The big question is how will this affect CPU intensive tasks, both single and multi-threaded? I can't really answer that, but I know we can't assume it's the same as previous generations of CPUs. Too much have changed with the design.

*It's actually possible to get CCXs with 3 cores. I highly suspect they only produce with 4 cores and then they disable defective cores. Being able to sell even chips with certain types of production flaws means less waste during production, hence lower production costs. One hint that AMD is doing this is that a reduced number of cores will not reduce the shared level 3 cache, meaning there is cache for the disabled core. Intel is known to do the same. They produce high end CPUs and sell poorly made as CPUs with lower speed, not hyperthreaded, less cores etc.

[Gurgel]

4 hours ago, Nightinggale said:

 Also what does this mean for stuff like thread locking?

All cores "snoop" on what gets written to memory to keep caches coherent. A TAS (test-and-set) instruction used for elementary synchronization will immediately read and then write to main memory and ensure exclusive atomic access while doing so. Other CPUs will have to invalidate respective cache entries and may have to roll back affected speculative execution and may even have failed writes to deal with. There is also some arbitration logic that decides who comes first if two or more CPUs try to do this at the same time. The whole thing is a tricky special case with extra hardware taking care of it. As it is vitally important (locking can be done in software only, but it is even worse performance-wise), most standard CPUs have that special functionality. 

The whole thing is pretty inefficient, also because main memory is slow.

Historically, this was done in a "stop the world" fashion, where the CPU about to do that TAS told all others to stop what they were doing and waited until all had confirmed that. 

Since TAS always goes to main memory, CPU-shared caches are a secondary issue. 

Incidentally, I have a 3700X laying on the desk next to me right now and all the other stuff I need. Maybe I will find the time to build that new PC over the weekend.

[bobucles]

22 hours ago, Gurgel said:

 By "heavy lifting" I mean complex calculations that cannot really be broken down, for example planning and scheduling in not very regular environments. Factorio does a heavy amount of "light lifting". 

That's the wrong view. The reason Factorio does "light lifting" is because all the "heavy lifting" tasks were rejected at the design table. There MUST be thousands of entities on the map, therefore anything that MUST use a lot of CPU effort was never allowed into the code in the first place. The things that were accepted were optimized to hell and back. That's why for example bot pathing only travels in a straight line with no other considerations. It's a deliberate (and successful!) attempt to reduce CPU strain as the pathing is a one-and-done job.

There's still an enormous amount of other tasks under the hood. For example inserter logic has to interact with potentially every single item on the map, which sounds exceptionally slow when working with a lot of data, right? But there isn't any slowdown, because the optimized code only ever has to scan for the items immediately relevant to the inserter's job. The FFF is filled with dozens of such stories, where some "super slow, impossible to improve" code suddenly becomes 200% faster or even more. 

Of course, many of those tweaks were hard earned over the many years of development. It is unreasonable to expect ONI devs (or any devs) to put in that same level of excruciating effort. Optimizing is a difficult job that requires its own type of talents, and there are diminishing returns after a point. But at the very least, the stories from other devs who do optimizing for a living can still teach a thing or two.

 

[Gurgel]

1 hour ago, bobucles said:

That's the wrong view.

It is not. You forget that this is about comparing ONI to Factorio, not about analyzing Factorio itself. You have nicely described why this comparison does not make sense though.