Discrepancy between Wiki and Config

[Obscure2020]

I've found a strange discrepancy between what actually showed up in my Smooth Boot config .json and what the Smooth Boot wiki says should appear in the .json. The page of the wiki in question is Configuration ~ Fabric 1.16+.

You see, my CPU has 4 cores, but 8 threads thanks to Intel Hyperthreading. (It's a 10th-Gen Intel Core i7.) The page of the wiki linked above states that certain thread counts are supposed to be calculated from your CPU's thread count, but the values I found in my .json (which I have not modified) do not match what the wiki suggests should be there. The wiki also states the Thread Priority values that Smooth Boot uses, but once again, the numbers provided by the wiki do not match up with what I found in the .json.

Now, for the Thread Priorities I suspsect the wiki just needs to be updated. The Thread Count discrepancy is more worrying, though. Either the wiki is lying, or the Smooth Boot is calculating the thread count incorrectly.

Here are my findings regarding Thread Count:

Option	Vanilla Default Value, according to wiki	Smooth Boot Default Value, according to wiki	Expected Value on My Computer	Actual Value found in config .json
Bootstrap Worker Thread Count	Total CPU threads, up to 7	1	1	1
Main Worker Thread Count	Total CPU threads, up to 7	1/2 of total CPU threads	4	❌ 7 ❌

Here are my findings regarding Thread Priority:

Option	Vanilla Default Value, according to wiki	Smooth Boot Default Value, according to wiki	Actual Value found in config .json
Game Thread Priority	5	5	5
Bootstrap Worker Priority	5	3	❌ 1 ❌
Main Worker Priority	5	3	❌ 1 ❌
IO Worker Priority	5	3	❌ 1 ❌
Integrated Server Priority	5	5	5

[Obscure2020]

Ooh! I was right! SmoothBoot is actually programmed wrong, and the wiki is lying!
I found the line of code responsible for calculating the default Config values, and that line is indeed written wrong.

I'm going to assume that the 1/2 of total CPU threads stated by the wiki is what it's supposed to be. I think I'll try my hand at fixing this myself and submitting a pull request, as I've never submitted a pull request before and I should probably learn how.

Hang tight.

[UltimateBoomer]

I think the wiki is very outdated by this point. Right now the default values of the mod config is CPU threads - 1, and it's likely better than limiting to 7 or 1/2 of total thread count especially for systems with higher thread counts. It's probably better to just update the wiki with the current default config values.

[Obscure2020]

Actually, I think CPU threads / 2 is the better option. As total system threads increase, Minecraft will likely need fewer of them to run adequately. I think it's worth testing on more machines (I've already tested it on mine), but I think CPU threads / 2 will still provide the game with enough threads to run well without bogging down the rest of the system unnecessarily.

On my 8-thread CPU, a 7-thread game runs alright. But so does a 4-thread Minecraft.

On a 24-thread CPU, does the game really need 23 threads? No. It'll be more than fine with 12.

[Obscure2020]

And for that matter, we're only specifying the default here. The user still has the ability to change their config if they want more threads.

They also still have the ability to install other mods to increase parallelization, such as C2ME, which I use.

[vadcx]

As total system threads increase, Minecraft will likely need fewer of them to run adequately.

A reasonable limit should be found by testing some currently targeted Minecraft versions to find the sweetspot, where increasing concurrency does not help. Then limit by:

• N physical core count (for SMT systems) - Unfortunately, there's no standard way to find logical vs ph. thread count
• N-1 phys. core count (non-SMT)
• with an upper bound found through testing

On Windows you can limit the amount of cores the OS boots up with using msconfig . While you could start the Java process with an affinity mask (fewer cores allowed for scheduling), I'm afraid this would make a slightly different benchmark.

On Linux there's the maxcpus kernel parameter. And apparently you could power down CPU cores live, though pay attention for them to not start again.

For consistency, you should exit background programs and make sure the entire Minecraft instance ends up in the file cache (reading all files in the folder).

A mod to ease the testing would be neat, one which logs current time when the main menu is entered. This way you can start MC, come back later and calculate the time from the logs. Waiting with a stopwatch is sooo 20th century!