Hit on performance: Transport belts vs Train infra?

[Siim]

If i simply start to use transport belts over silly long distances, how much it would affect fps over time? i have i9 9900K. with 16G DDR4 (4400Mhz). TItan X pascal gpu.

[Hedning]

If your belt is full there's no problem having long belts. Turn on show gaps in the debug menu to see if your belts have gaps. Every gap is tracked, so if you have them then over a long belt it's going to be a lot of gaps and that will destroy performance. If you don't have gaps there's nothing to track so it's fine.

Trainless megabase is perfectly valid for performance, but to really max it out you want to play in creative or start building it in a completely new location, lest you will never finish because of the time it takes to sort out the spaghetti.

[PunCrathod]

Originally posted by Hedning:

If your belt is full there's no problem having long belts. Turn on show gaps in the debug menu to see if your belts have gaps. Every gap is tracked, so if you have them then over a long belt it's going to be a lot of gaps and that will destroy performance. If you don't have gaps there's nothing to track so it's fine.

This is outdated thinking. Gaps shouldn't affect performance that much. I remember seeing on reddit a person did extensive testing and pretty much the only things about belts that affected performance was when items were moved from one belt segment to another(splitters, sideloading etc) and when an active inserter hovers over a belt trying to grab an item or waiting for a gap to place an item. Of course if you have gaps inserters could take longer to pick up items from the belt and thus take more cpu cycles but that does not care about how long the belt is.

I mean logically thinking if the gaps aren't changing why waste processing power on them. All you have to do is track the first group that can move. All the groups after the first will always be exactly the same distance behind the first moving group.

[Hedning]

Originally posted by PunCrathod:

This is outdated thinking. Gaps shouldn't affect performance that much.

I don't think it is very outdated. Dosh made a sushi belt base 4 months ago and showed his transport lines time usage. It was horrendous.

Logically thinking a string of 1s is going to be a lot easier to calculate with than a random string of 1 and 0.

[Hurkyl]

I had thought that the belt optimizations tracked compressed belts as one aggregate entity, but I'm wrong. I looked up the FFF

https://factorio.com/blog/post/fff-176

and the visualizations suggest the include gaps in the aggregate.

Which makes sense, since an empty spot on the belt is not really any different from a filled spot -- the difference in behavior is when a sequence of moving items meets a backed up section, or with an inserter that's willing to pick up anything.

[Hedning]

Originally posted by Hurkyl:

I had thought that the belt optimizations tracked compressed belts as one aggregate entity, but I'm wrong. I looked up the FFF

https://factorio.com/blog/post/fff-176

and the visualizations suggest the include gaps in the aggregate.

Which makes sense, since an empty spot on the belt is not really any different from a filled spot -- the difference in behavior is when a sequence of moving items meets a backed up section, or with an inserter that's willing to pick up anything.

You're quoting something from version 0.15 (2017). I am almost certain they have done a lot better since then.

[PunCrathod]

Originally posted by Hedning:

Originally posted by PunCrathod:

This is outdated thinking. Gaps shouldn't affect performance that much.

I don't think it is very outdated. Dosh made a sushi belt base 4 months ago and showed his transport lines time usage. It was horrendous.

Logically thinking a string of 1s is going to be a lot easier to calculate with than a random string of 1 and 0.

Logically thinking what the value of a variable is makes no difference on how hard/easy it is to calculate. Only the type&size of the variable and the amount of variables to calculate matters. Also Items on a belt are not just simple here is a 1 on this position to denote an item. The items themselves contain position data. The items are grouped. And each group has a float that tells how big the gap in front of the group is. If two groups are both moving on the belt the distance between the groups stays constant. Without inserters only the first gap on a segment of belt can change. The rest are guaranteed to stay constant and thus do not need to be updated.

Dosh had a lot of transport lines time usage because he had a lot of splitters etc. But with a long belt that has no interactions whether there are gaps or not should not make any difference.

[Hedning]

Originally posted by PunCrathod:

Logically thinking what the value of a variable is makes no difference on how hard/easy it is to calculate. Only the type&size of the variable and the amount of variables to calculate matters. Also Items on a belt are not just simple here is a 1 on this position to denote an item. The items themselves contain position data. The items are grouped. And each group has a float that tells how big the gap in front of the group is. If two groups are both moving on the belt the distance between the groups stays constant. Without inserters only the first gap on a segment of belt can change. The rest are guaranteed to stay constant and thus do not need to be updated.

What do you even mean with a segment? In the fff quoted a segment is a short piece of belt. Is that what you mean or do you mean the distance between two inserters/splitters?

In the fff quoted they say they "store" the distance between items. If the distance is always 0 that sequence has a lot less info than one with multiple gaps of random length. No matter what operation you are doing on it, even if it is to simply "store" it, it takes more calculations.

At the end of the day we can speculate about how they are doing it, but since neither of us are modders who actually know it is kind of pointless.

[DaBa]

With a PC like this, uinless you're building a stupidly large mega factory it will not make any difference either way. 9/10 people who obsess over things like these never even built a factory large enough for this to become a factor.

[Hurkyl]

Originally posted by Hedning:

In the fff quoted a segment is a short piece of belt. Is that what you mean or do you mean the distance between two inserters/splitters?

Probably something like this comment

Originally posted by FFF 176:

Also there are dynamic merging/unmerging routines which keep transport lines under inserters or side-loading at some limited range, maybe 9 tiles, while inserter-free lines can be 100 tiles long.

The point being that inserters have to track what is nearby, so they need to keep the groupings small so that the compute code related to inserters don't have to do much work.

So, the expected performance is that a 100 tile long belt with a bunch of inserters at the beginning and end would perform a lot better than a 100 tile long belt with evenly spaced inserters.

In the fff quoted they say they "store" the distance between items. If the distance is always 0 that sequence has a lot less info than one with multiple gaps of random length. No matter what operation you are doing on it, even if it is to simply "store" it, it takes more calculations.

(this section is longer and technical, so I've highlighted where sushi belts are mentioned)

That's not true. If the operation is, for example, "adjust the last element, and maybe remove it", the number of other elements in the data structure are irrelevant, because you aren't doing any calculations on them.

That's what "O(1)" means in that article. It's a computer science term that there is some fixed upper bound on how much work an operation is, no matter how big the data you're working with is.

As an example -- one probably rather pertinent to this discussion -- a "double-ended queue" (deque) is a list of items two operations on it: you can insert a new item at the head of the list, or you can remove an item at the end of a list. And for typical ways to implement a deque, those operations take O(1) work. (depending on the implementation, that could be per-operation or averaged over all operations)

(for the optimization they want to do, one would also need to be able to look at and modify the item at the end of the list)

---

I imagine what they are storing is not individual items, but instead runs of items -- the data is "type of item and how many". In that case, adjusting the number is going to be quicker than moving items between data structures.

(and empty stretches of belts could use the same structure: with item type being "empty")

So a sushi belt loses in this regard since there aren't stretches of identical items, so the game has to shuffle things around rather than just increment/decrement counters.

There's also memory usage, which can affect how your computer performs in subtle ways. A sushi belt would require more memory. Memory usage can affect how your computer performs in subtle ways -- more memory and frequent shuffling around of items are both ways that typically make things worse.

At the end of the day we can speculate about how they are doing it, but since neither of us are modders who actually know it is kind of pointless.

I actually do programming so these exercises are still useful. (especially since my interests tend to lie in high-performance stuff)

It also has a point if one is interested in UPS optimization, since having ideas about how the game is implemented would help one devise theories (which one could then test) about what designs would be better for performance.

[PunCrathod]

Originally posted by Hedning:

Originally posted by PunCrathod:

Logically thinking what the value of a variable is makes no difference on how hard/easy it is to calculate. Only the type&size of the variable and the amount of variables to calculate matters. Also Items on a belt are not just simple here is a 1 on this position to denote an item. The items themselves contain position data. The items are grouped. And each group has a float that tells how big the gap in front of the group is. If two groups are both moving on the belt the distance between the groups stays constant. Without inserters only the first gap on a segment of belt can change. The rest are guaranteed to stay constant and thus do not need to be updated.

What do you even mean with a segment? In the fff quoted a segment is a short piece of belt. Is that what you mean or do you mean the distance between two inserters/splitters?

In the fff quoted they say they "store" the distance between items. If the distance is always 0 that sequence has a lot less info than one with multiple gaps of random length. No matter what operation you are doing on it, even if it is to simply "store" it, it takes more calculations.

At the end of the day we can speculate about how they are doing it, but since neither of us are modders who actually know it is kind of pointless.

Just because you don´t know does not mean we can´t know. How belts work has been researched in great depth by the community. https://www.reddit.com/r/technicalfactorio/comments/r6ye86/mechanics_of_transport_line_splits/ And the consensus is that a long stretch of belt with no inserters, splitters, sideloading or circuit connections is O(1) no matter how many items and gaps there are. I´m not speculating. I´m just repeating what people who have done in depth research are saying.

[Siim]

Ok, thanks everyone. My brain went a bit sushi when I read all the posts but a long 100% filled belt without interaction shouldn't hurt performance even a long distance.(btw as background music remastered old starcraft 1 terran theme songs are awesome)

[Hedning]

Originally posted by PunCrathod:

How belts work has been researched in great depth by the community. https://www.reddit.com/r/technicalfactorio/comments/r6ye86/mechanics_of_transport_line_splits/ And the consensus is that a long stretch of belt with no inserters, splitters, sideloading or circuit connections is O(1) no matter how many items and gaps there are. I´m not speculating. I´m just repeating what people who have done in depth research are saying.

Ok, now that I know it's not just your speculation I'll believe you.
That's not to say there couldn't have been a difference. That posts talks about "inactive" belts which takes even less computation. The two types are stopped and empty. Well, a lot of games "cheat" where a steady state thing is not actually simulated. Empty, stopped and full belts could all have been treated the same by the game, all of them being inactive, and the moving of pieces on the full belt could have been not actually pieces moving but just a segment replaced by a looping animation and items going into it would literally teleport to the end.

My point is that you cannot just refer to logic, because people made the game and have a choice in how they do things. But after reading that post you linked I of course accept what they say and that there is no difference between a belt with gaps and one without, unless the gap is 200 pieces long or more.

[Hedning]

Originally posted by Hurkyl:

That's what "O(1)" means in that article. It's a computer science term that there is some fixed upper bound on how much work an operation is, no matter how big the data you're working with is.

Big O is general maths notation.

Originally posted by Hurkyl:

So a sushi belt loses in this regard since there aren't stretches of identical items, so the game has to shuffle things around rather than just increment/decrement counters.

A sushi belt could be different, but also not. If the size of the data (eg a segment that costs 2 byte to describe vs a segment that costs 2MB to describe) doesn't matter then you can just as easily store different items in it as all the same items.

[Hurkyl]

Originally posted by Hedning:

Big O is general maths notation.

I am aware asymptotic analysis is used in fields other than analysis of algorithms.

Originally posted by Hurkyl:

So a sushi belt loses in this regard since there aren't stretches of identical items, so the game has to shuffle things around rather than just increment/decrement counters.

A sushi belt could be different, but also not. If the size of the data (eg a segment that costs 2 byte to describe vs a segment that costs 2MB to describe) doesn't matter then you can just as easily store different items in it as all the same items.

Okay, but this quote was about what you are doing with the items at the edges of the list.

Feel free to disregard if you're still thinking about comparisons with doing something with every item on the list rather than just what's at the ends, since this optimization only becomes relevant when working with just the ends becomes a significant fraction of the work.

(unless cache effects are at play, but that's a whole 'nother can of worms)

[Hedning]

Originally posted by Hurkyl:

Okay, but this quote was about what you are doing with the items at the edges of the list.

I know. I am questioning the difference you are proposing. Why does it suddenly matter if it is 1 iron plate followed by a copper plate rather than 2 iron plates? The only difference is how much information the segment takes to describe, but if you are only working on the edges then that doesn't matter. You are working on 1 iron plate in both cases.