search

KingContaria / seedqueue

Minecraft mod that generates multiple worlds concurrently and lets players reset them on an ingame wall screen.
MIT License
32 stars 18 forks source link

Affinity-like world gen prioritization #15

Open jojoe77777 opened 2 months ago

jojoe77777 commented 2 months ago

Similar to affinity in Julti, it would be very useful to have locks & previews that have just started generate faster than other previews. This would help runners enter locked instances faster, and generate chunks in new previews faster, rather than world gen resources being shared equally between all previews

KingContaria commented 2 months ago

I'm not sure what the best approach for an affinity-equivalent in SeedQueue is.

Codewise the easiest approach is just to make a seperate executor, the same way the wall executor and background executor are seperated. However this fails when you have say 10 generating seeds, all using the "before preview" executor, allocated 16 threads, then one of them finishes that phase and goes to the "after preview" executor, which is only allocated 8 threads. This is supposed to slow it down by having less threads to use, but in practice it now actually has 8 threads all for itself, while the other instances share 16 threads across 9 seeds. It also means the more spread out seeds are on the different stages, the more total executor threads are active, taking resources from other threads. It could still be worth it to look into adding an (optional) extra executor for locked previews, since atleast on higher concurrent seeds counts the amount of locked previews that are still generating should almost always be much lower than the rest of seeds, meaning even with very little special threads allocated they could be prioritized more. This would still suffer the mentioned above issues, but might work well for some configurations.

To actually solve this issue, it would probably necessary to implement our own executor with a priority system. However this comes with a lot of new problems, firstly having to write our own executor or finding a suitable one. Secondly it has to be ensured that the executor doesn't behave too differently from the ForkJoinPool vanilla uses in a way that it could mess with randomness of world generation.

All this to say I've put thought into this but it's not an issue I want to focus on right now, if anyone has any input feel free to comment on this PR :)