UPS wars: smelting challenge (design competition)

[Xtrafresh]

Ok, I got some things working this morning and did some testing. With some margin of error because my tests are very crude and only run once, I found that the version 2.0 that I submitted goes from a score of 27 to a score of 41 just by cutting it down to 1/8th the size. With the way my setup works, none of those 8 modules should affect eachother, so shouldn't the score be the same? This means that the test favors small setups, pretty disastrous for designs that are supposed to go into megabases

Ofcourse, I could be getting this wrong.

[Optera]

Ok, I got some things working this morning and did some testing. With some margin of error because my tests are very crude and only run once, I found that the version 2.0 that I submitted goes from a score of 27 to a score of 41 just by cutting it down to 1/8th the size. With the way my setup works, none of those 8 modules should affect eachother, so shouldn't the score be the same? This means that the test favors small setups, pretty disastrous for designs that are supposed to go into megabases

Ofcourse, I could be getting this wrong.

Reading through the preliminary results here it seems larger logistic networks score worse then segregated small ones.
Not quite sure I understand why fewer longer trains would score worse though.

[Xtrafresh]

Ok, I got some things working this morning and did some testing. With some margin of error because my tests are very crude and only run once, I found that the version 2.0 that I submitted goes from a score of 27 to a score of 41 just by cutting it down to 1/8th the size. With the way my setup works, none of those 8 modules should affect eachother, so shouldn't the score be the same? This means that the test favors small setups, pretty disastrous for designs that are supposed to go into megabases

Ofcourse, I could be getting this wrong.

Reading through the preliminary results here it seems larger logistic networks score worse then segregated small ones.
Not quite sure I understand why fewer longer trains would score worse though.

Not fewer longer trains, fewer IDENTICAL trains. I have eight functionally identical setups using 6 trains each. No bots, no railway connections between them, the only thing connected was the electrical grid. And when I deleted 7 of the setups and ran just one, i scored 41 instead of 27.

[hypnobunny]

Not fewer longer trains, fewer IDENTICAL trains. I have eight functionally identical setups using 6 trains each. No bots, no railway connections between them, the only thing connected was the electrical grid. And when I deleted 7 of the setups and ran just one, i scored 41 instead of 27.

I have also found that my setups do not scale linearly as I increase their size. My first thought was that the most efficient setup would have as much mining/train transport as your offloading system could handle (thus maximizing the use of those entities). With few exceptions, this really hasn't been the case. I have only come up with one design so far that performs nearly the same when scaled up 2x. Everything else has been better at 50-60k plates/min than the exact same (modular) setup producing 80-100k plates/min.

[Optera]

The Void Chest Mod used in this test is seriously flawed and rather slow.
It will not work with any void-chest created outside this mod.

I've rewritten Buggy's Void Chest which has roughly 3 times better performance than his or your version and also can take over void chests created by the plethora of void chest mods.
https://mods.factorio.com/mods/Optera/VoidChestPlus

[TBTerra2]

with regards to scaleing, i have broken out a full profiler and will try to see what isnt scaling properly

with regards to void chests being slow, aaargha has already made a fix that give 10x performance with large numbers of them, but to keep it fair (and so i dont have to spend 13hours retesting designs) im not aplying that update untill aftre the competition

[aaargha]

More on inserter UPS usage:

I tried comparing circuit connected inserters to sleeping ones in an idiot setup where no inserter should be able to do anything. Savefile connected inserters is attached.

Use this command to disconnect all inserters from the circuit network, takes about a minute to process though.

Code: Select all

/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-inserter"}) do
	ins.disconnect_neighbour(defines.wire_type.red)
end

Results from benchmarking ~6.4k inserters over 100k ticks:
Circuit connected and enabled 30071.684 ms
Circuit connected and disabled 29157.366 ms
Unconnected 12705.188 ms

This basically confirms what TBTerra2 said, though I'm not really sure at which swing rate clocking them becomes more efficient.

[DaveMcW]

with regards to void chests being slow, aaargha has already made a fix that give 10x performance with large numbers of them, but to keep it fair (and so i dont have to spend 13hours retesting designs) im not aplying that update untill aftre the competition

I think you should test the leading designs with the best technology available.

Just read through this thread and I'm loving the timer solution. Before this, I had been trying to fix the problem by using slower inserters. I sent in two new versions, one using red inserters (which almost exactly use their full stack bonus without external input) and then another making use of the circuit network.

Congrats, you figured out my solution.

You will probably score better due to the small build bias, since I mined the full resource patch.

For comparison, here are full resource patch designs for both.

[Optera]

More on inserter UPS usage:

I tried comparing circuit connected inserters to sleeping ones in an idiot setup where no inserter should be able to do anything. Savefile connected inserters is attached.

Use this command to disconnect all inserters from the circuit network, takes about a minute to process though.

Code: Select all

/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-inserter"}) do
	ins.disconnect_neighbour(defines.wire_type.red)
end

Results from benchmarking ~6.4k inserters over 100k ticks:
Circuit connected and enabled 30071.684 ms
Circuit connected and disabled 29157.366 ms
Unconnected 12705.188 ms

This basically confirms what TBTerra2 said, though I'm not really sure at which swing rate clocking them becomes more efficient.

It would warrant investigating where the break even point for this setup is and if filter inserters in set filter mode have similar results.

[aaargha]

It would warrant investigating where the break even point for this setup is and if filter inserters in set filter mode have similar results.

That is a good point.

Stack filter inserters in set filter mode:
No filter: 24145.431 ms
Filter : 26090.869 ms
Stack filter inserters in enable/disable mode with no filter:
Disabled: 25588.459 ms
Enabled: 25542.712 ms
Stack filter inserters in enable/disable mode with filter:
Disabled: 25326.079 ms
Enabled: 25638.240 ms
Stack filter inserters not connected:
Filter: 12826.896 ms
No filter: 12763.919 ms

Re-run using stack inserters just to confirm that stack filter inserters are actually faster:
Connected & enabled: 30173.355 ms
Connected & disabled: 29285.514 ms
Disconnected: 12788.264 ms

Note that all measurements are one run only so some fluctuations are possible, the times seemed pretty stable though.

It's interesting that the stack filter inserters seem to consistently perform better than the regular stack inserters when circuit connected. It's also interesting how inefficient disabled circuit connected inserters are, it feels like there should be ways of doing that much better.

I wonder if it would be enough to fill the "starting" chests with a green circuits and limit the stack size (so the inserters will always be working) to get some data to calculate the breakpoint or if that won't work, It feels like that wouldn't give useful results. Then again, I'm not sure how else to design a test that would be conclusive either way.

commands used to change tests

Code: Select all

--disconnect red wire, slow
/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-inserter"}) do
	ins.disconnect_neighbour(defines.wire_type.red)
end

--copy circuit setings
/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-filter-inserter"}) do
	ins.copy_settings(game.player.selected)
end

--replace stack inserters with filter stack inserters, SLOW
/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-inserter"}) do
	game.player.surface.create_entity{name="stack-filter-inserter", position = ins.position, direction = ins.direction, force = ins.force, fast_replace = true}
end

--remove stack inserter items from the ground
/c for _,ent in pairs(game.player.surface.find_entities_filtered{type="item-entity"}) do
	ent.destroy()
end

--set filter for stack filter inserters
/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-filter-inserter"}) do
	ins.set_filter(1, "filter-inserter")
end

--remove filter for stack filter inserters
/c for _,ins in pairs(game.player.surface.find_entities_filtered{name="stack-filter-inserter"}) do
	ins.set_filter(1, nil)
end

[Optera]

It would warrant investigating where the break even point for this setup is and if filter inserters in set filter mode have similar results.

That is a good point.

Stack filter inserters in set filter mode:
No filter: 24145.431 ms
Filter : 26090.869 ms
Stack filter inserters in enable/disable mode with no filter:
Disabled: 25588.459 ms
Enabled: 25542.712 ms
Stack filter inserters in enable/disable mode with filter:
Disabled: 25326.079 ms
Enabled: 25638.240 ms
Stack filter inserters not connected:
Filter: 12826.896 ms
No filter: 12763.919 ms

Re-run using stack inserters just to confirm that stack filter inserters are actually faster:
Connected & enabled: 30173.355 ms
Connected & disabled: 29285.514 ms
Disconnected: 12788.264 ms

Note that all measurements are one run only so some fluctuations are possible, the times seemed pretty stable though.

It's interesting that the stack filter inserters seem to consistently perform better than the regular stack inserters when circuit connected. It's also interesting how inefficient disabled circuit connected inserters are, it feels like there should be ways of doing that much better.

I wonder if it would be enough to fill the "starting" chests with a green circuits and limit the stack size (so the inserters will always be working) to get some data to calculate the breakpoint or if that won't work, It feels like that wouldn't give useful results. Then again, I'm not sure how else to design a test that would be conclusive either way.

This seems to prove my suspicion that "set filter mode "uses normal sleep when no filter is set, while in on/off mode inserters never sleep.

With this knowledge using stack filter inserters sent a 1 copper plate impulse when a furnace has 10+ plates stored should be the most efficient way for this challenge.

Edit:
I benchmarked different options on my v3.3 map, 1040 stack inserter. Timed was set up to pull ~10 items per cycle.
Results where taken from running each benchmark 3 times for 10k ticks then taking the avg/tick.

constant enabled stack inserter
avg/tick 3,136 ms

timed stack inserter
avg/tick 2,996 ms

timed stack filter inserter, constant filter, enabled mode
avg/tick 2,939 ms

timed stack filter inserter, set filter mode
avg/tick 2,972 ms

Conclusion:
Even in this lab environment the gain from changing inserter operation seems minuscule compared to the drain from trains and logistic networks. In a real base the benefits will be too small to be noticeable.

[aaargha]

Another test using connected inserter in circuit mode "none", meaning that they should sleep poperly but still have the overhead from the circuit network, same setup otherwise.

Stack inserters: 21214.604 ms
Stack filter inserters with filter: 20358.010 ms
Stack filter inserters no filter: 20365.378 ms

Looking at them, they were all inactive, I wonder what makes the filter inserters faster.

This seems to prove my suspicion that "set filter mode "uses normal sleep when no filter is set, while in on/off mode inserters never sleep.

Hmm, I'm not really sure about that, it seems like some other quirk to me at least.

[Sicnarf]

Was there ever a winner declared? I'm curious what the most efficient design was.

[quyxkh]

Assuming the score ratio between my demo on my box and on tbterra's holds for the maps DaveMcW posted, his clocked-inserters(-and--no-chests) setup should score about 95 and produce more plates/hr than mine, which would make it the runaway winner. edit: holy crap, that clock-noise-isolation trick is _huge_.

[MisterSpock]

Ok, i think its a good try. I also uploaded my savefile.

The idea was to do it with midgame tools. I dont use direct insert and bots. Only belts and trains.
Note: i increased the voidchest count from 360 to 384.

Im not expecting to win with this, ehm obviosly .
Its more a represenation of what "normal" people build, ups wise.

Belts and Trains

[quyxkh]

This setup is ~20% more cpu efficient than DaveMcW's while producing >40% more output. No mods needed in 0.16, the infinity chests are lovely.

quyxkh.clocked.shorter.trains.zip

(2.13 MiB) Downloaded 157 times

It gets ~83 plates delivered/cpu ms on my box, ~234k plates produced/game minute, It'd have scored ~110 on tbterra2's rig if the 75/57 ~ 110/83 ratios stay the same. (edit: rerunning my older submissions on 0.16 says train-only performance is very comparable between versions, within a couple percent).

Lessons learned: locomotives are costly, so much so that putting up with bad acceleration, is worth it until you start needing more trains to drain the the supply. This runs on four 5-57 trains rather than DaveMcW's sixteen 14-14-1-13-1-13-1-13 ones. 5 3-57 trains lost a few percent performance, 4 3-57's couldn't get around the track fast enough.

[quyxkh]

Heh. Turns out just the one unload station was a bottleneck throttling train throughput enough that with twinned unload stations I can run 3 trains instead of 4 thus cutting congestion several ways, boosting the score on my box to 89 plates/cpu ms, ×75/57 for test-rig normalization this setup would score ~117:

quyxkh.clocked.3x5-57.trains.zip

(2.1 MiB) Downloaded 135 times

tbterra, if you're reading this, when I asked if we could use more than 360 unload chests I wasn't expecting _this_

[mulark]

I took both of the top contenders maps and resaved them in 0.16.18, completely vanilla, and replaced daves unloader station with infinity chests. Then I benchmarked the maps for 60000 ticks. 3 runs later these are the results.

DaveMcW Clocked inserters _ update 16.18.zip
0.3491
0.3053
0.2939
quyxkh.clocked.3x5-57.trains.zip
0.4562
0.4486
0.4519

It appears they are almost nearly equal, when you account for the difference in capacity. On further inspection, it looks like quyxkh's map is utilizing mining productivity 25, daves 200. I intend to test this further, but I want to normalize production to the same value.

[quyxkh]

The ~20% variability in cpu usage (I'm assuming that's the reported average cpu ms/tick?) between benchmark runs on Dave's map combined with the really envy-inducing speed difference between your rig and mine makes me think Dave's map might be close to fitting in cache, the sim's deterministic so that's the only thing I can think of that could produce such a huge variance, cache interference from something external causing drama. On my rig they show .656 for DaveMcW's, .705 for mine (newly upgraded to mining level 200), with almost no variance between runs when I just wait for it. The mining output is 159871 vs 234526 per minute, both maps never vary outside a half-percent range from that over any five-minute interval.

[mulark]

I reran the dave's benchmarks and the variance was eliminated. I think it was some windows background process that hurt that one run in particular. For funzies I reran the bench on my Linux install:

avg_ms
DaveMcW
0.367
0.365
0.356
quyxkh
0.523
0.522
0.545

I do think we're comparing too many variables at once here though. I'm going to set up a new test suite that covers each aspect individually (difference of blueprints; difference of train engine counts; difference of size (1x, 10x, ~50x of each bp's)
When that's complete I'll upload the map pack here along with a customized script so anyone can test without any hassle.