UPS Wars 3 - Electronic Circuits

[DaveMcW]

60218.444 ms - quyxkh tuned
178680.570 ms - schmetterling

quyxkh takes the lead with the first entry using trains!

[flame_Sla]

Belts.
The clock is not optimal, but I'm too lazy to select the values)))

2.jpg (264.22 KiB) Viewed 5177 times

[DaveMcW]

62003.904 ms - flame_Sla

flame_Sla is now the leader in "belts only" category!

[quyxkh]

Okay, here's a second tuneup, stripped the rest of the excess capacity for an extra few percent and made the layout a little more retry-friendly just so it looks better while running, the retry dispatching itself is better than anything else I've thought of to try. Dedicated trains = excess capacity+congestion, more expensive. Metered dispatch (put a pulse converter on the stop-ready latches, keep a counter of un-dispatched ready stops) = circuitry more expensive to run than retries. I guess I could change the unload timing so the pickup capacity's a closer match to the production capacity, but this is so far down in the noise it doesn't seem worth any effort.

Maestro, I don't know if it's just my rig and the phase of the moon or what, but I get unusual variability in my performance readings on these maps, only when I shut down all background activity including browser, steam and notably the wifi link do I get back to get my expected within-1% repeatability. I suspect something like that could be affecting your readings, I'm still left with variable ratios between my results and yours on the various maps, or perhaps it's just different hardware reacting to the different workloads, I really don't know. For reference I've got a stock 3570K, 16GB@DDR3-1333, generally my results are a few percent slower than yours. On the plus side, I've noticed that the 100000-tick readings are overkill, doing three 10000-tick readings is much cheaper and seems more informative, and makes running a round less of a tedious wait and more of a sure, let's-do-one thing.

[DaveMcW]

57590.104 ms - quyxkh tuned 2


I have a stock i5-6400 and 16GB DDR3-1600. Slower CPU and faster RAM than you. I run the headless server from the command line in recovery mode, with literally nothing else running.

I also get results +/- 1%, and for some reason the first run after a cold boot gets -2%. I have started throwing out the first run, and using an average of 3 runs for competitive entries. If things get close at the end I will average even more runs. I like big benchmarks because they make it harder to cheat by timing train cycles.

[Stevetrov]

Could we have a category for off-patch smelting? On patch smelting is well known to be the most efficient but most megabase builders consider it to be impractical due to the huge number of mining bases that are required even with maxed vanilla settings.

[DaveMcW]

Sure, off-patch smelting sounds like a fun category. I believe knightelite is the current leader.

I did try to limit the map to approximately what you can get out of the vanilla map generator, though.

[knightelite]

Second submission from me, all trains all the time!

Needs some tuning now I guess, since quyxkh is destroying me still. Since I have a lot more cars now (960 as compared to 80 in my previous map), the cars sleeping makes a much larger performance difference.



My PC seems to be a bit faster than DaveMcW machine I think, though the computer is still 8 years old now (i7-3770k, running at 3.9GHz. 16GB DDR3@1866Mhz).

[Stevetrov]

Here are a couple more of my submissions, they are completely different designs, but one is all belt and the other is all trains. Both use off patch smelting and I believe are very competitive in that category.

[Allaizn]

I started out with quyxkh's design and initially only wanted to make a few minor improvements, but I ended up rebuilding most of it.

• Nearly everything is clocked (perfectly) with circuit network
• No train signals, who needs them anyway?
• 45 miners per patch instead of 40
• The total production is mathed out to be very slightly above 100k, the production graph shows that by not being able to decide between 99k/100k
• No chest stubs for plate pickup, the inserters are instead clocked via CN achieving the same effect
• The only layout I found that was able to insert everything directly from belt to assembler while still having the same global look as quyxkh's layout needed cars
• Car->Train inserters are primed to always sleep on the rail or train, never on the car, and thus minimizing useless wakeups

The train load/unload times sadly work out in a way that disallows a train to serve two stations, but it's probably possible to make 2 trains serve 3 stations or sth like that. I don't like trains, and thus kept it simple.

[quyxkh]

I started out with quyxkh's design and initially only wanted to make a few minor improvements, but I ended up rebuilding most of it.

I loaded it up and the instant I saw your production cell I knew I was beat.

quyxkh: "I don't need no stinking cars".

allaizn: "this is how you use a car."

Everything else is just noise, you found space to lose the buffer steps. Tip'o'the hat.

[Allaizn]

Tip'o'the hat.

Thanks
I also ran a verbose benchmark for both of our maps to see how they perform. I ran each map 3 times (cause I didn't want to wait) for 100k ticks (i7 8700K @ 4.7GHz, 3600MHz DDR4 RAM), then took the median time for each tick acrross the three runs. Libreoffice really didn't like to plot a graph with 100k points, so I summed 100 consecutive values to get down to 1k samples. Treating the 100 values for each sample as a random distribution, I also plotted the 95% confidence interval for it, so that the graph shows how much the actual values jump around (the yAxis scale is nanoseconds, note that it doesn't start at zero!):

The average across all values is 0.428ms per tick on my map and 0.460ms per tick on quyxkh's.
It's somewhat surprising to me how stable the averages are, considering that a typical 100 tick window looks like this (tick 63.300-63.399):

[Allaizn]

Seems like the map I uploaded above didn't quite manage to produce the 100k because I was sloppy with the 3 leftover assemblers. Thanks to quyxkh for pointing this out to me
If this one doesn't do it, then I'll actually have to clock even that thing (and I really don't want to )

[DaveMcW]

57029.672 ms - Allaizn circuit.everything.2
66104.114 ms - Stevetrov belts 1.1b
68401.553 ms - Stevetrov trains 1.2_proof
82141.411 ms - knightelite build2 - trains - cars_sleeping

Allaizn is now the overall leader!
Stevetrov is now leading in "off-patch smelting" category.
Stevetrov is also leading in "trains only" category.

[knightelite]

Turns out that trains build I posted has terrain generation happening in it, which consumes quite a bit of compute time. Here's a new one without terrain that should show some improvement. Steve's is probably still faster though.

[DaveMcW]

79042.199 ms - knightelite build2.1 - trains - cars_sleeping

One problem I can see with your save is the copper smelting trains. They each see the same green signal and leave the station, but only one can use the track and the other is stuck at the red signal keeping the inserters awake.

[knightelite]

79042.199 ms - knightelite build2.1 - trains - cars_sleeping

One problem I can see with your save is the left copper smelting train tries to leave the station, but is stuck at a red signal. This prevents all the copper ore inserters from going to sleep.

Thanks, I'll take a look. Biggest problem I can see though (after doing some analysis) is that steve's save has half as much rolling stock as mine and (consequently, no doubt) his train update cost is about half as much. That's about 85% of the difference between our saves right there .

[flame_Sla]

The trains
build for GC stole from Stevetrov)
my build for smelting iron and copper

[DaveMcW]

62303.966 ms - flame_Sla v9.1 - train - Stev_GC

flame_Sla is now the leader in "trains only" category!
(And could do even better when he stops throwing iron plates into void chests.)

[flame_Sla]

I completed my build
trains + cars