Factorio Forums

I bought the game about 3 weeks ago and it's awesome . But I saw people complaining about low UPS on big factories. I know what FPS is bit UPS is new to me.

Updates Per Second.

Unlike most common games, Factorio is much more limited by CPU speed then graphics processing power. And it runs in a fixed update cycle. Unlike other games that become less "accurate" if they your computer is too slow.

Daid wrote:Updates Per Second.

Unlike most common games, Factorio is much more limited by CPU speed then graphics processing power. And it runs in a fixed update cycle. Unlike other games that become less "accurate" if they your computer is too slow.

thanks for the quick response I can imagine that factorio needs more CPU speed then graphics processing power.

Maybe the devs find a way to use more of the gpu. Better then to let a field lie fallow.

Interestingly enough, it actually isn't the CPU that bottlenecks first.

According to rseding, the biggest bottleneck is actually RAM Latency. On a large factory there is so much data that needs to be fetched, processed, and updated again, that the system ram cannot respond to commands quickly enough to keep up.

On a modern CPU with up to date specifications, this ram bottleneck is reached before the CPU becomes the limiting factor in performance.

Even more fun is that the amount of data it takes to make the phenomena visible is far more than the CPU cache can contain, increasing said cache does little to avoid the problem. Only way I can think of around it would be to use server-duty hardware that performs dual channel and even quad channel memory access, spreading out the requests across more than one RAM stick so that multiple devices are working at the same time.

If you think about it, factorio's own parallelization concepts are mirrored pretty easily in computing and in mass production.

OdinYggd wrote:Interestingly enough, it actually isn't the CPU that bottlenecks first.

According to rseding, the biggest bottleneck is actually RAM Latency. On a large factory there is so much data that needs to be fetched, processed, and updated again, that the system ram cannot respond to commands quickly enough to keep up.

On a modern CPU with up to date specifications, this ram bottleneck is reached before the CPU becomes the limiting factor in performance.

Even more fun is that the amount of data it takes to make the phenomena visible is far more than the CPU cache can contain, increasing said cache does little to avoid the problem. Only way I can think of around it would be to use server-duty hardware that performs dual channel and even quad channel memory access, spreading out the requests across more than one RAM stick so that multiple devices are working at the same time.

If you think about it, factorio's own parallelization concepts are mirrored pretty easily in computing and in mass production.

Huh, sounds like HBM will be a boon to Factorio's performance (HBM=High-Bandwidth Memory; ATI GPUs have gen1 of the stuff in their latest, but HBM2 hasn't come out yet, but when it does, it could be used for system RAM as well, which could possibly solve this bottleneck for Factorio).

Frightning wrote:

OdinYggd wrote:Interestingly enough, it actually isn't the CPU that bottlenecks first.

According to rseding, the biggest bottleneck is actually RAM Latency. On a large factory there is so much data that needs to be fetched, processed, and updated again, that the system ram cannot respond to commands quickly enough to keep up.

On a modern CPU with up to date specifications, this ram bottleneck is reached before the CPU becomes the limiting factor in performance.

Even more fun is that the amount of data it takes to make the phenomena visible is far more than the CPU cache can contain, increasing said cache does little to avoid the problem. Only way I can think of around it would be to use server-duty hardware that performs dual channel and even quad channel memory access, spreading out the requests across more than one RAM stick so that multiple devices are working at the same time.

If you think about it, factorio's own parallelization concepts are mirrored pretty easily in computing and in mass production.

Huh, sounds like HBM will be a boon to Factorio's performance (HBM=High-Bandwidth Memory; ATI GPUs have gen1 of the stuff in their latest, but HBM2 hasn't come out yet, but when it does, it could be used for system RAM as well, which could possibly solve this bottleneck for Factorio).

If it is the latency, then higher bandwidth won't solve that. I've tested Factorio on a machine with quad-channel memory (double bandwidth compared to the typical PC with just dual channel) and it doesn't really go faster. The only things that do go faster with double bandwidth are compression algorithms like RAR and deflate.

I have also configured the said quad channel system to just use dual channel memory and it made no difference. Then I tested it with 2, 4 and 6 cores and it didn't make a difference. I came to the conclusion that Rseding might be wrong when he points out that specific hardware is the limiting factor. I am not sure if there is any single bottleneck at all. It might just be that the game works in a way that it can not use hardware resources efficiently.

If RAM is the bottleneck, thats... interresting.
Do we have some kind of overclocker here that can check on this, varying the Latencies and stuff?
The newer RAM-Technologies wont help because, as already pointed out, they mostly increase bandwith and not latency.
So, if Factorio is dependant on that, it would be the ONLY thing I know that would profit from faster Memory with those sharp timings more that 3% or something.
And that would mean it could be used as a RAM-Benchmark.

Frightning wrote:Huh, sounds like HBM will be a boon to Factorio's performance (HBM=High-Bandwidth Memory; ATI GPUs have gen1 of the stuff in their latest, but HBM2 hasn't come out yet, but when it does, it could be used for system RAM as well, which could possibly solve this bottleneck for Factorio).

HBM isn't compatible with classic DDR standards. HBM has only that much throughput because it has a 1024 bit interface in the first generation and probably even more for the upcoming HBM2 (I've heard about speculations with up to 2048 bit). Scaling the interface width is the major source of HBM performance, that and a very short low-latency distance between the memory stack dies and GPU die as they basically sits on the same interposer.

With other words to develop memory module sockets around HBM would be an absolute nightmare, if not impossible for economical reasons because of how many pins would go off-chip to the motherboard. That and you'd probably lose a great deal of the performance due to synchronization latency that become more appearent with greater distances especially the more parallel lanes you have.

So if you don't want to sacrifice the ability to put as much RAM into your computer as you want then people should pray that Intel/AMD never come up with the idea of pairing a CPU with HBM because that would mean you can't upgrade the RAM anymore as the RAM would become an integral part of the CPU interposer itself. Upgrading RAM would then mean you'd have to buy a new CPU altogether. The overall costs may be lower that way which is why I think that Intel and AMD will eventually consider that approach anyways, especially for the low end sector, but you'd hope they don't because it makes the CPU-Memory configuration fixed.

hansinator wrote: If it is the latency, then higher bandwidth won't solve that. I've tested Factorio on a machine with quad-channel memory (double bandwidth compared to the typical PC with just dual channel) and it doesn't really go faster. The only things that do go faster with double bandwidth are compression algorithms like RAR and deflate.

I have also configured the said quad channel system to just use dual channel memory and it made no difference. Then I tested it with 2, 4 and 6 cores and it didn't make a difference. I came to the conclusion that Rseding might be wrong when he points out that specific hardware is the limiting factor. I am not sure if there is any single bottleneck at all. It might just be that the game works in a way that it can not use hardware resources efficiently.

That's interesting. I would think that quad channel ram would round-robin the commands between each of the four channels, allowing the latency to be somewhat offset by using multiple devices. The flaw in that thinking is that the CPU probably has to wait for the transaction to finish before it can start the next one, completely preventing quad channel from being any performance advantage over dual channel.

In which case there is in fact no solution to the memory latency problem, other than optimized data structures to minimize how much data needs to be handled for each tick.

To that end, rseding91 is already working on the issue optimizing the performance of everything the game has in order to try and get the most out of the computing resources people have available.

OdinYggd wrote:In which case there is in fact no solution to the memory latency problem, other than optimized data structures to minimize how much data needs to be handled for each tick.

While efficient data structures are useful, a trick which must not be ignored when memory latency is a concern, is localizing data, and creating serial access patterns. The idea being that if the next thing you want to process is already "close" to the CPU (in the L1, L2, Lx cache) then it will be much faster to get to that next thing and avoid the "remote" memory completely.

While it is not always possible to do, it can sometimes be arranged that a memory intensive operation can be optimized by ordering the data in memory such that the data you need to process next will be pulled in before you need it. This is especially true with modern systems where the memory controllers identify sequential (and other regular pattern) access to memory and will prefetch the next chunks before they are requested. This can start the latency delay significantly earlier, and thus the latency impact on the actual code is significantly reduced, and sometimes eliminated.

In other words, having the memory you need in local cache is always faster than having to fetch it, and you can improve the odds of having it in cache by using less memory in general, putting sequentially accessed memory locations sequentially in memory, and by not having things you don't need mixed in with things you do need in memory pages.

Although this article is linux-based, the logic/systems/processes are common to pretty much all architectures and OS's https://lwn.net/Articles/255364/

MeduSalem wrote:With other words to develop memory module sockets around HBM would be an absolute nightmare, if not impossible for economical reasons because of how many pins would go off-chip to the motherboard. That and you'd probably lose a great deal of the performance due to synchronization latency that become more appearent with greater distances especially the more parallel lanes you have.

Yes you are absolutely right MeduSalem. HBM only works because it basically sits right next to the graphics chip on a so called interposer. They form one unit and you can't separate them. The distances between the chips must be very, very short. If you had HBM modules you would need to insert them into the CPU package like a micro SD card, just with a few thousand pins