Didn't we decide that it's better NOT to include a separate clock mechanism with each smelter array? Rather, we want to use a single clock and link the circuit networks together, right?
1. How do you load/unload the belts: the standard infinity loader?
2. Your output doesn't look like standard output, are you using a powershell script? (could you share it?)1
3. as stated, this saves were for a quick indication. tonight or tomorrow I ll run a test with 500 belts each save.
disentius wrote: Fri Feb 18, 2022 5:11 pm
Thanks!
1. How do you load/unload the belts: the standard infinity loader?
2. Your output doesn't look like standard output, are you using a powershell script? (could you share it?)1
3. as stated, this saves were for a quick indication. tonight or tomorrow I ll run a test with 500 belts each save.
1. load - mining drills ( if the ore is fed from the train, then the inserters + infinity chest ), unload - infinity chest
2. https://gist.github.com/flameSla/b614b1 ... d1689256bahttps://gist.github.com/flameSla/79517f ... df8fa30657
2.1. scripts put next to factorio.exe
2.2. edit the script "UPS optimized 12-beacon smelting.ps1": set variable $saves; change variables $ticks, $runs
2.3. run the script "UPS optimized 12-beacon smelting.ps1"
the benchmark.ps1 script performs a benchmark for the files specified in $saves
2.4. for another benchmark, create a copy of the script "UPS optimized 12-beacon smelting.ps1", edit and rename
2.5. the benchmark results are added to the file test_results.txt
Welcome here! Why not put signals 0/1/2/3/4 on the same wire? Can you do a left->right direction verison of this BP so we can benchmark? I'd like to measure 5x100 lanes w/one controller circuit only. Having 5 wires makes it pretty challening. I'll do a 1 wire version of this idea - which could work a bit better than signal compression, as the inserters would get only 2 state transitions / 144 cycle (0-1-0) and not 6 (0-1-2-3-4-5-0). Not sure how Factorio signal processing is optimized...
disentius wrote: Sat Feb 19, 2022 8:33 pm
already did that, see above results (davemcW v5) it looks like its faster, but the differences are marginal with 100 belts
Belter wrote: Sat Feb 19, 2022 8:22 pm
Welcome here! Why not put signals 0/1/2/3/4 on the same wire?
My reasoning was
Number of networks remains O(1) anyway, so I assume that overhead is negligible.
Number of networked inserters is the same in both cases => shouldn't impact performance
Yet number of wakeup calls is exactly 1 per inserter, compared to single wire version, and this difference scales with the number of inserters, so 1000 vs 5000 difference is not so negligible.
That said, we won't know for certain anyway, until tested. I will post updated blueprint soon.
Belter wrote: Sun Feb 20, 2022 8:18 am
Removal of editor extensions would make testing more painful, I'm look into that now.
vanilla has everything for a benchmark, editor extensions is not needed
I don't understand why everyone started using editor extensions
apparently someone is advertising this mod on YouTube
@belter: Why make a separate post on 100 vs 500? lets keep it here:)
@flame_Sla: force of habit, I happen to like Editor Extensions. I don't think it really matters, our testing is about relative results. Different solutions tested in the same environment with the same hardware, mods, and configuration.
some additional thoughts:
- there is a different number of beacons in use for 1 row of 500 vs 5 rows of 100. within the same test use one or the other exclusively.
- make sure the production is stable. (run for at least 10 minutes, or until all furnaces are filled. (all builds here have a slight overproduction)
- keep the original authors name in the save
I 'll make a 500 belt test run of the latest builds later today
disentius wrote: Sun Feb 20, 2022 11:51 am
@flame_Sla: force of habit, I happen to like Editor Extensions. I don't think it really matters, our testing is about relative results. Different solutions tested in the same environment with the same hardware, mods, and configuration.
mods somehow affect the result
I have no guarantee that without mods in vanilla, the benchmark results will be preserved
therefore, for myself, I make benchmarks only in vanilla, and in my script, all the mods for the benchmark are forcibly disabled
Note: I've replaced my benchmark here as this finding made it invalid, as I've mixed vanilla and EE results. Will redo it with a consistent way, most likely vanilla.
I've re-created an 500 lane test for 3 scenarios to test EE impact
- Zero Mod EL: no mods, using express loaders / infinity chests (B004-zm-Belter-v6.80-500.zip)
- EditorE but EL: same as above, but EE mod loaded (B004-ee-Belter-v6.80-500.zip)
- EditorE UG: express loaders/infinity chests replaced to EE underground belt (B004-eet-Belter-v6.80-500.zip)
Result: 13% UPS diff
- I have a quick 5000 tick result only, will update here with a longer test:
- Editor Extension mod loaded alone does not have any impact
- Editor Extension Underground Belt does have a negative impact - slower than vanilla express loader/infinity chest:
- 18% diff in entity update time! It leads to 13% UPS difference
- UPS numbers: 162 UPS (EE UG) vs 183 UPS vanilla
- I'd suggest going to vanilla - Editor Extensions is cooler looking but does add noise to our benchmarks
- It does not mean our benchmarks done with EE are invalid. Just they had an increased overhead cost which is not good
