Add random tick batching config option

[okx-code]

This is a config option where, instead of running random ticking once every tick, you can run it once every n ticks, but when randomly ticked, chunks will be ticked n times more. While this does affect vanilla behaviour, the nature of random ticking is that this effect is barely noticeable, but it can have a significant impact on TPS.

With 50 bots randomly spread on a server, and a benchmark running for two minutes, setting randomTickScale to 10 reduced the footprint of optimiseRandomDespawn from 6 ms/t to 3.9 ms/t. On a real server with about 90 players, I have observed a reduction in the footprint from 4.04 ms/t to 0.76 ms/t (both with approximately 28,000 chunks loaded, plus or minus 10%), which is a significant performance boost for such a simple option.

[vadcx]

Is my understanding correct that the randomization of ticking prevents aliasing, such that not all chunks run the bundled random ticks all at once?

[okx-code]

Yes, if randomTickScale is set to 10 for instance, on average 10% of chunks will be random ticked per tick

[Toffikk]

this pull request seems to modify the moonrise patch, as such it should be pr’d to the moonrise repo iirc

[lynxplay]

This patch does not require moonrise and needs to be moved infront of moonrise.
The moonrise patch then needs to be adapted to the patch.

Additionally, IntOr.Disabled would make more sense here.
Naming on the option is a bit weird, "scale" is not really what this does.
I don't have a better suggestion right now tho.

Lastly, the premise of this patch seems pretty interesting.
The entire saving here would have to come from skipping the section iteration in optimiseRandomTick, which 2ms on a 50 bot world seems pretty uh interesting.

[vadcx]

Naming

https://en.wiktionary.org/wiki/batch ?

entire saving

cache locality too. Something OOP is usually bad at, and Minecraft's architecture never tried to work around.

[lynxplay]

Sure, cache locality may account for some savings.

2ms saving tho, even assuming a 100ns on RAM reads, is a pretty strong estimate around a 28k ticking chunks as we'd have to miss nearly every single cache read to get to numbers like 2ms saving.

I am not saying these numbers are false or anything, just that a lot of profiling needs to happen around this to find out how "supported" we would want to consider something like this.
Given the relatively small patch surface I would not have much of an issue pulling it if we find it to be beneficial, but yea.
Definitely something to investigate before pulling this patch.

[okx-code]

It's not exactly a fair benchmark because one was on 1.21.4 and one was on 1.21.8, but you can see the spark reports I based it on here. Feel free to try and benchmark this yourself as well.

randomTickScale = 10 https://spark.lucko.me/BVRT4Sikki
no randomTickScale https://spark.lucko.me/WcUisNbfDM

I'll change the PR to work before the moonrise patches

[okx-code]

I've changed the PR to work by apply the changes before moonrise. I'm not sure about using IntOr.Disabled though because this option being 1 is semantically the same as vanilla behaviour, so I'm not sure if it's really helpful to say that it's "disabled". Many other options in the Paper config work like this, for instance the TickRates config

[lynxplay]

Yea but we are adding a completely new concept here that doesn't exist yet.
The tick rates should be using IntOr.Default as well.
If the config option ends up being called randomTickBatching, having it default to disabled makes a lot more sense because, by default, the game does not batch random ticks like this.

[okx-code]

That does make more sense, should I change it to be called randomTickBatching and work like that?

[lynxplay]

Yea I think that' be great 👍

[okx-code]

should be good now