Entity tier list for UPS

[foamy]

And out of power entities not sleeping I'm pretty sure of - it was discussed on forums few times.

Indeed. out of power entities consume compute time because they could be reactivated any time power comes back, whereas entities gone dormant because output is saturated are just put in sleep mode and start to consume CPU only once there is room for the output.

I really wish that that wasn't the case if, and only if, the only power connection to that block is a power switch that's turned off. Because if it's off, then the power off is commanded and all the entities should be put to sleep as their local power reserves drain. That'd make power switches far more useful in the case of the only bases that actually care about UPS -- turbobeaconed megabases.

I have no idea how you'd make it happen though =/

[Koub]

That'd make power switches far more useful in the case of the only bases that actually care about UPS -- turbobeaconed megabases.

Free your mind, Neo foamy ! There are other scenarii where a power switch could be useful.

For example turning off all the non vital parts of your factory (aka science production) if your power storage falls below a certain level, allowing you to upgrade your power production while keeping your defenses fully operational. I'm sure there are other way more creative uses to the power switch.

[foamy]

That'd make power switches far more useful in the case of the only bases that actually care about UPS -- turbobeaconed megabases.

Free your mind, Neo foamy ! There are other scenarii where a power switch could be useful.

For example turning off all the non vital parts of your factory (aka science production) if your power storage falls below a certain level, allowing you to upgrade your power production while keeping your defenses fully operational. I'm sure there are other way more creative uses to the power switch.

That is precisely the situation I was thinking of, but if you're not a big base you don't care about the UPS hit and if you're not using beacons you don't need to use switches to turn stuff on and off (because you can, for example, disable the outputs). The big, unique thing power switches let you do are control the flow of electricity -- useful for backup systems or reserving power for certain critical things, like powerplant overheads -- and turning off beacons, which otherwise can't be manipulated at all.

So if you're using switches en-masse you're probably doing so to turn off beacon draw. The conditions I use are input failures, low accumulator charge, high accumulator discharge rate, and jammed output. I just wish doing so was performant, y'know?

[mrvn]

The reason why blocking the input/output of assemblers puts them to sleep is because the assemblers will register with the fluid box or inserter to be told when the blockage is resolved.

Why couldn't power switches (or rather electrical networks) have that same "register" capability? The assemblers go to sleep and when the electrical networks has power again it wakes them up.

This could even work on the different power priorities. When the network gets power it first wakes up all the laser turrets. If any energy is left after that it wakes up the assembler. If there is still energy left it wakes up the accumulators.

[Rseding91]

The reason why blocking the input/output of assemblers puts them to sleep is because the assemblers will register with the fluid box or inserter to be told when the blockage is resolved.

Why couldn't power switches (or rather electrical networks) have that same "register" capability? The assemblers go to sleep and when the electrical networks has power again it wakes them up.

This could even work on the different power priorities. When the network gets power it first wakes up all the laser turrets. If any energy is left after that it wakes up the assembler. If there is still energy left it wakes up the accumulators.

There is no such logic for fluids or electricity because they change literally every tick and having to send e vents as all of the power/fluid flows everywhere would drastically slow the entire thing down.

It is expect that there is power; not having power is the edge case. It is expected to have fluid; not having fluid is the edge case.

[foamy]

The reason why blocking the input/output of assemblers puts them to sleep is because the assemblers will register with the fluid box or inserter to be told when the blockage is resolved.

Why couldn't power switches (or rather electrical networks) have that same "register" capability? The assemblers go to sleep and when the electrical networks has power again it wakes them up.

This could even work on the different power priorities. When the network gets power it first wakes up all the laser turrets. If any energy is left after that it wakes up the assembler. If there is still energy left it wakes up the accumulators.

There is no such logic for fluids or electricity because they change literally every tick and having to send e vents as all of the power/fluid flows everywhere would drastically slow the entire thing down.

It is expect that there is power; not having power is the edge case. It is expected to have fluid; not having fluid is the edge case.

Fluids maybe, but grids are unified entities -- there's normally far fewer of them in a base than there are fluid boxes. And in either case it'd only need to throw events on the transition from no-stuff to stuff, right? Which shouldn't be happening every tick, at least without circuit intervention.

[varundevan]

what are you guys talking about ... !

[orzelek]

CL is just a very small part of the whole cycle of operations for performing one "read".
On the contrary, frequency applies to literally everything. So 5% higher frequency globally means the whole read operation will last close to 5% less (I'm rounding here, it's a bit less in reality), while a 37.5% improvement on CL just applies to maybe 1/15th of the whole operation, so you'll be into the 2.5-ish % improvement.

It's like making your hand 5% shorter will result in a shorter hand than only shrinking your fingernail by 37%, if the analogy fits you.

I do not guarantee the numbers are correct (I'm just an enthusiast who's read a lot, not an expert), but the overall idea is.

I turns out that misconfiguring your BIOS is easy.. figuring out what's wrong not so.
So I have a bit more actual results:
Badly configured DDR4-3200 at CL22:
78UPS https://factoriobox.1au.us/result/977cd ... 53940f5ddd
Properly configured DDR4-3200 at CL16:
83UPS https://factoriobox.1au.us/result/63607 ... b50815f47c
Properly configured DDR4-3200 at CL14 (different memory kit):
85UPS https://factoriobox.1au.us/result/b3d4b ... 41e860c270

And with the CL14 memory UPS on OP's map is 48-51 (for context: it was 42-45 with badly configured one).

It's worth to read through ones BIOS manual from time to time

[varundevan]

CL is just a very small part of the whole cycle of operations for performing one "read".
On the contrary, frequency applies to literally everything. So 5% higher frequency globally means the whole read operation will last close to 5% less (I'm rounding here, it's a bit less in reality), while a 37.5% improvement on CL just applies to maybe 1/15th of the whole operation, so you'll be into the 2.5-ish % improvement.

It's like making your hand 5% shorter will result in a shorter hand than only shrinking your fingernail by 37%, if the analogy fits you.

I do not guarantee the numbers are correct (I'm just an enthusiast who's read a lot, not an expert), but the overall idea is.

I turns out that misconfiguring your BIOS is easy.. figuring out what's wrong not so.
So I have a bit more actual results:
Badly configured DDR4-3200 at CL22:
78UPS https://factoriobox.1au.us/result/977cd ... 53940f5ddd
Properly configured DDR4-3200 at CL16:
83UPS https://factoriobox.1au.us/result/63607 ... b50815f47c
Properly configured DDR4-3200 at CL14 (different memory kit):
85UPS https://factoriobox.1au.us/result/b3d4b ... 41e860c270

And with the CL14 memory UPS on OP's map is 48-51 (for context: it was 42-45 with badly configured one).

It's worth to read through ones BIOS manual from time to time

or , do not touch any of those setting and run at default all the time ..

[mrvn]

CL is just a very small part of the whole cycle of operations for performing one "read".
On the contrary, frequency applies to literally everything. So 5% higher frequency globally means the whole read operation will last close to 5% less (I'm rounding here, it's a bit less in reality), while a 37.5% improvement on CL just applies to maybe 1/15th of the whole operation, so you'll be into the 2.5-ish % improvement.

It's like making your hand 5% shorter will result in a shorter hand than only shrinking your fingernail by 37%, if the analogy fits you.

I do not guarantee the numbers are correct (I'm just an enthusiast who's read a lot, not an expert), but the overall idea is.

I turns out that misconfiguring your BIOS is easy.. figuring out what's wrong not so.
So I have a bit more actual results:
Badly configured DDR4-3200 at CL22:
78UPS https://factoriobox.1au.us/result/977cd ... 53940f5ddd
Properly configured DDR4-3200 at CL16:
83UPS https://factoriobox.1au.us/result/63607 ... b50815f47c
Properly configured DDR4-3200 at CL14 (different memory kit):
85UPS https://factoriobox.1au.us/result/b3d4b ... 41e860c270

And with the CL14 memory UPS on OP's map is 48-51 (for context: it was 42-45 with badly configured one).

It's worth to read through ones BIOS manual from time to time

or , do not touch any of those setting and run at default all the time ..

Lets see, 78 UPS to 83 UPS is a 6.4% gain and CL22 to CL16 is a 37.5% gain. Assuming 100% of the time is spend on memory access that would mean roughly 1/6 of memory access would be the CL to give you that improvement. Since clearly you aren't always waiting on memory the effect of CL (or whatever else you had misconfigured) must be even more. A lot more than the 1/15th Koub mentioned. Makes me think I didn't read the timing diagrams for ram access to badly.

Anyway, have fun with the speed boost.

[orzelek]

If you leave it at default settings it's even worse.
Standard speed for this memory seems to end up at DDR4-2133 CL15 and that nets this:
67UPS https://factoriobox.1au.us/result/d82b2 ... 91a01d4914

Basically if you are going to get ram that is capable of decent speed you will need to set it up or you end up with worse defaults
XMP profiles are considered overclocking (not 100% sure about that) so it won't use those as defaults.

[Koub]

Moderator note : All the discussion on RAM speed and timings is quite (totally) off topic. If people in here are OK with that, I can try to split the posts on the RAM speeds and timings into another thread. The result won't be ideal though, there might be holes in the discussion.

[Yoyobuae]

Fluids maybe, but grids are unified entities -- there's normally far fewer of them in a base than there are fluid boxes. And in either case it'd only need to throw events on the transition from no-stuff to stuff, right? Which shouldn't be happening every tick, at least without circuit intervention.

You can bet there will be at least one player that will setup a power switch that flicks on/off every tick and then complain why their game suddenly runs at 0.1 UPS.

I don't completely understand how Factorio update loop works, but I do know that every entity is updated pretty much on it's own in some deterministic sequence which is highly optimized for CPU cache utilization, etc.

Your way of "throw an event and update the entities" breaks the update order, because now when some power switch is changes state then some/many other entities may need to be updated again. This introduces a non-trivial CPU cost which is worsened because the entities might be in random parts of the factory (ie. in random parts of memory).

[mrvn]

Fluids maybe, but grids are unified entities -- there's normally far fewer of them in a base than there are fluid boxes. And in either case it'd only need to throw events on the transition from no-stuff to stuff, right? Which shouldn't be happening every tick, at least without circuit intervention.

You can bet there will be at least one player that will setup a power switch that flicks on/off every tick and then complain why their game suddenly runs at 0.1 UPS.

I don't completely understand how Factorio update loop works, but I do know that every entity is updated pretty much on it's own in some deterministic sequence which is highly optimized for CPU cache utilization, etc.

Your way of "throw an event and update the entities" breaks the update order, because now when some power switch is changes state then some/many other entities may need to be updated again. This introduces a non-trivial CPU cost which is worsened because the entities might be in random parts of the factory (ie. in random parts of memory).

I think you are misunderstanding the mechanics I'm suggesting. Every single belt, chest and inserter uses this already and they do flicker on and off constantly. Overall it's still a gain.

Currently every tick the game goes over all entities and checks how much power they would like to have. It then checks how much power there is and decides how much everyone gets. It then goes over every entity again and gives it that power. The order in which it does this is the order in which entities have been created. There is nothing optimized there to be sequential in ram. It randomly jumps all over the space. The going to sleep and waking up that happens when the output of an assembler is full further scrambles the order already.


Now with the new mechanic that still happens normally. Except when an entity runs out of power it goes to sleep. That gains you the same performance benefit as when the output is blocked, big win. The electrical network then has no power so I assume it doesn't iterate over any entities even now. When power comes back the electrical network again iterates over all connected entities. What's new now is that it wakes up any entity sleeping due to lack of power. Same as if an inserter had removed something from the output of an assembler or an item goes by an inserter on a belt. So really I'm not suggesting anything new that would change the behavior or order of entities any more than it already does (which is random in the first place anyway).

Now if you turn on a power switch every other tick here is what happens: Your power consumption will be twice as high for one tick and 0 for the other tick. Apart from that nothing happens. Each entity has an internal energy buffer that lets it run for the tick it has no power and the other tick it refills the buffer. The entities wouldn't go to sleep or even show any difference to having full power.

If you want to create a worse case you have to combine this with a brownout. When the switch is on there isn't enough power to fill the entities energy buffer more than a fraction. Then the next tick they are out of power and go to sleep.

I don't know how expensive the "goes to sleep" and "wakes up" is but every time an item on a sparse belt moves past an inserter it wakes up and goes back to sleep. Every time you take something out of an assembler it wakes up and goes back to sleep. I imagine it's just a linked list so all it takes is altering 2 or 4 pointers. The far more costly aspect is probably all the "out of power" icons appearing on the screen every other tick.

[Rseding91]

Currently every tick the game goes over all entities and checks how much power they would like to have. It then checks how much power there is and decides how much everyone gets. It then goes over every entity again and gives it that power. The order in which it does this is the order in which entities have been created. There is nothing optimized there to be sequential in ram. It randomly jumps all over the space. The going to sleep and waking up that happens when the output of an assembler is full further scrambles the order already.

Electric networks don't work like that: all of the energy buffers for entities in a given network are in one contiguous array in the electric network. You can read more about how it works here: https://www.factorio.com/blog/post/fff-209

[mrvn]

Ok, sorry, should have worded that better, missed a sentence or two in there.

Currently every tick the game goes over all entities and checks how much power they would like to have. It then checks how much power there is and decides how much everyone gets. It then goes over every entity again and gives it that power. The order in which it does this is the order in which entities have been created.

Ok, here is where I missed a step. Yes, the electrical info is put nice and sequential in arrays. In the order entities have been created.

So now I was switching over to the entities themself. The entities themself remain random in memory. Unless I missed some further optimisation. All the non electrical processing is ..

There is nothing optimized there to be sequential in ram. It randomly jumps all over the space. The going to sleep and waking up that happens when the output of an assembler is full further scrambles the order already.

Electric networks don't work like that: all of the energy buffers for entities in a given network are in one contiguous array in the electric network. You can read more about how it works here: https://www.factorio.com/blog/post/fff-209

I was refering here to the other work being done on e.g. assemblers to see if they can and should produce something or not. The part that gets shut down when they go to sleep because the output is blocked. That's the part where time is wasted when assemblers have no power. Even asleep they still consume electricity so the electric network loop doesn't change in that regard unless there is some further optimization you didn't mention in an FFF. With the putting entitites to sleep or waking them up I refer to the non-electrical work.

Hope that makes it clearer.