Batch Training (The Good, The Bad and The Ugly)

[DesertRose]

If we compare no batch to 2-10 batches.

After 60 seconds:

2	1.02767254972061
3	0.985794108773369
4	0.96419601647961
5	0.842511233639707
6	0.809886682621353
7	0.787635316056181
8	0.725540687970097
9	0.624656521911935
10	0.485888389876762

Meaning after 60 seconds only 2 batch production is ahead, and only by ~2.8%

After 90 seconds:

2	1.07140697286798
3	1.08663652712691
4	1.07784597069266
5	1.03953334109689
6	1.03076486879081
7	1.00244494770787
8	0.923415421052851
9	0.849421381590345
10	0.855485117783215

After 90 seconds 2 batch production is ahead by ~7.1%, 3 batch production by ~8.7%.

After 120 seconds:

2	1.09181637033674
3	1.12649376026016
4	1.13088261599208
5	1.13147699124358
6	1.13384135566989
7	1.10268944247865
8	1.07930705300764
9	1.0801167081955
10	1.05440758719945

This is what I found surprising. After just 120 seconds even producing Civilians in 10 batch sizes you are already head of producing them 1-by-1.

2 batch production is ahead by ~12.6%, and 3 batch production by ~13.1%.

After 180 seconds:

2	1.10904224897359
3	1.16689945242606
4	1.20032846736228
5	1.21690362218682
6	1.22988990026177
7	1.23128368774283
8	1.23040276261435
9	1.21621697818618
10	1.22489914591688

4 batch production and up is at least 20% ahead.

After 240 seconds:

2	1.12005300060407
3	1.1872998244697
4	1.22837249668105
5	1.25907655790822
6	1.2772006075362
7	1.29365142554231
8	1.30261196052646
9	1.30358913058077
10	1.30814403567772

After 360 seconds:

2	1.14110639562759
3	1.21895993515409
4	1.27224294299109
5	1.31293842431479
6	1.34318602533905
7	1.36823258770606
8	1.38768049672411
9	1.40154527962407
10	1.4115504443423

 

1 hour ago, Deicide4u said:

I imagine you would need to build additional training buildings sooner. 

I have updated the sheet with the table above and with a column how much batch production increases production speed, assuming a batch multiplier of 0.8.

2	1.14869835499704
3	1.24573093961552
4	1.31950791077289
5	1.37972966146122
6	1.43096908110526
7	1.47577316159455
8	1.5157165665104
9	1.55184557391536
10	1.58489319246111

I have not looked (yet) at how producing from more buildings with less batch sizes compares to less buildings with bigger batch sizes (but both having the same total production speed).

 

0AD_Batch_Size_Calculations.ods

Edited March 13 by DesertRose

[Seleucids]

Interesting

I will try 3 by 3 then 4 by 4 and let you know

The bigger the batch the less flexible you are though 

[guerringuerrin]

57 minutes ago, Seleucids said:

Interesting

I will try 3 by 3 then 4 by 4 and let you know

The bigger the batch the less flexible you are though 

are we still talking about batches here? 

[Seleucids]

10 minutes ago, guerringuerrin said:

are we still talking about batches here? 

yes

[ffm2]

Tbh. I didn't fully understand what each is doing here. But as I understand it, the pro of small batch is the units can get faster to work, the pro of higher batch sizes is the total train time decreases.

In this simulation a unit with total cost of 100 gets produced, gathers with 0.75 without ways to drop of, at different batch sizes from one cc. To account for the ways one could reduce the gather rate.

I wouldn't take any practical advice from this. Just spectate some games with good eco scores. This leaves out the timings of the next barracks which costs again.

batch.py

[noxafy]

Here is my attempt at the question what batch size is optimal for a given maximum time batches are running. I wrote a little script to calculate the total alive time of units, based on the batch time formula in the original post (ignoring the auto-queue rounding at first). Let's start with base training rate 10 and modifier 0.8. Plotting it as a heatmap looks like this

This doesn't tell too much yet, as more time means more units have spent more time alive. No surprise here. But you can already see interesting irregularities at the lower end, which hints at that there are optima. So, to make them more visible, I normalize each time step by the 1-by-1 alive time

The first 10 time steps are now shown white because it's dividing by 0. The upper right corner is black, because the larger the batch, the longer there is no unit yet to accumulate alive time. Makes sense so far.

However, it is still a bit mushy, so to really highlight the optimal batch size for each target time, I apply a softmax. You see the result on the left below (notice these interesting secondary modes). In the right figure, I have included that auto-queue rounds up the batch train time, giving it a more jagged shape.
 

That jagged behavior is at least nice to determine some optimal batch size values. I'll leave some here for future reference:

With auto-queue active, for base rate 10 and modifier 0.8, until about 90s target duration 1-by-1 is optimal (without auto-queue the cross over to batch size 2 is around 59s). Then in short window 90s-102s batch size 2 is optimal, followed by a somewhat longer optimum for batch size 4 at 102s-122s. Interestingly, 3 seems to never be optimal, 5 only very shortly. However, batch size 6 is good 136s-240s, surprisingly versatile! Similarly, batch size 9 is useful 240s-340s. Keep in mind that I used a quite strong inverse temperature for these plots, so if there shows some color means it is already close-to-optimal. Similar to batch size 3, the sizes 7 and 10-12 seem generally useless.

For other base rates or modifiers the optima are different. With base rate 8 (laborers), 1-by-1 is optimal up to 46s, batch size 2 for 46-93s, 5 for 94-161s (or even down to 200s), and 7 is useful from 130s down to 260s (though in the shortest and longest times only close-to optimal). Batch sizes 3, 4, 6 and 9 are never good here.


For Romans the base rate 9 favors batch sizes 1 up to ~70s, 3 for ~70-140s and 6 for ~125-225. Avoid batch size 4.

Longer base rates tend to favor smaller batch sizes (though you don't necessarily wanna maximize alive time with these ones), while a smaller modifier favors larger batch sizes. Here is the plot for base rate 10 and modifier 0.7:


The graphs without auto-queue are very similar, but look more smoothly and do not have such batch size preferences. Code is attached to play around yourself  Cheers!

 

batch.py

Edited 1 hour ago by noxafy