Is your feature request related to a problem? Please describe.
I would like my Minecraft server and client to be able to utilize more of my CPU's processing power. I have had problems where I would have had a lot of mods which run fine on a server with multiple people to start but once a lot of additional things happening like lots of machines, ai, or block updates the server TPS can drop significantly and the server is utilizing the maximum amount of the CPU that it can. With plans to play with a large number of mods in the future on fabric once enough mods are added or ported from Forge to replace Forge for particular things I want to make sure the game is properly optimized and can utilize as much power as I can give the server to avoid the performance issues of large modpacks or having lots of players. I would also like to be able to raise the server render distance higher with a large number of mods but right now it doesn't seem possible.

Multithreading has been requested as an official feature of Minecraft but It seems to be ignored. It is ranked 14th in the number of votes of all the posts on the official Minecraft feedback page, but it is seems like it is being ignored because posts with half the votes are marked as under review and most of the post that rank similar are marked as well. See "Additional context" for link to the post. So it could be a long time with out multithreading being official added and Lithium code would then have to be optimized for multithreaded operation anyways (to my knowledge) so the only difference would be that Minecraft would handle giving the client and server access to more threads.

Describe the solution you'd like
I would like Lithium to allow the Minecraft server and client to be able to use more CPU threads. To enable better performance when more processing power is available. With the optimizations provided by Lithium and the access to more system resources Lithium should be able to provide a exponential increase to performance on modern multicore CPUs and server CPUs. (high core count)

Describe alternatives you've considered
AI Improvements (Forge) I have used ai improvements when playing on Forge but it disables features unlike Lithium. It does have plans to multithread the ai nav pathfinder. Unfortunately I have not seen any plans for Fabric and would like proper optimizations like Lithium.
I have used other optimization mods as well with Forge but they also disable things to improve performance.
With fabric I used Sodium, Phosphor, and Lithium. As well as fastbench and fastfurnace for optimization.

Additional context
Official feature request Made on the Minecraft feedback page by QueazyBranch929.

As pointed out in the comment above, it would be major changes to the Minecraft codebase, and would most likely break many vanilla things, which would have a problem with Lithium's goal of vanilla parity.

Yeah that's the sad part. It would be nice if it was easier to add multithreading. I still see Lithium as the best alternative and would think it would be cool if it were properly implemented. @jellysquid3 and the rest of the development team seem like the perfect people to do it if a mod ever multithreaded Minecraft. Even if it end up being a separate mod than Lithium.

This is what Dinnerbone, a minecraft developer, said on multithreading.

Correct, but there is still plenty of things which could benefit in some cases from multithreading. You can also only multithread the server since that can be ran on professional hardware in a high core count high clock speed environment and add an option to disable it for people that run servers on old computers for example.

I would argue that most players have no idea how software programming works and are woefully under-qualified to make bold suggestions such as "just multi-thread the game!" In particular, the community loves to bash Mojang over the head for not making the game more parallel, which I find frankly unfair. As author of three optimization mods for the game, yes, I do agree that performance is lacking and even with my mods it isn't enough, but, to put it bluntly...

Multi-threading is not a magic bullet. It's an immensely complex topic, and at the surface level, there is an immense amount of work that has to go into synchronizing other tasks as they run parallel to one another. You can't have one thread modifying data beneath another one without everything bursting into flames and exploding. Developers have to take special care to package up tasks for consumption by other threads in a manner which makes them independent of the other thread's work.

For tasks that don't need to modify game state (we'll call these read-only tasks), this is arguably much easier. For example, path-finding all current mob trajectories doesn't require modifying the world, so we can generally (gross over-simplification alert) create a task for each mob and throw them at every available CPU core and then await all their results on the main thread.

However, for things such as actually ticking mobs, this is not a cake walk. Consider what happens if a Creeper explodes before all those path-finding tasks finish. You'll have a hole in the world, and depending on where you are in the path-finding queue, only some mobs will see that hole in the world, with others having complete path-finding before it was ever created. This is where the problem of synchronization comes into play.

One solution is to break the tick loop into multiple discrete phases. You could have all mob ticking occur only after all path-finding has completed, which happens before all block updates and random block ticking, but the code would need to be re-built from the ground up to accommodate this new mindset. Right now, we're stuck with one giant tick() method for every entity, with no way to tick entities in discrete phases.

But that doesn't acknowledging the issues in fundamentally serial tasks, where the next computation depends on the results of the previous computation. For example with block updating, you won't be able to get any parallelization out of it without being able to break the world up into independent regions which can't modify one another (i.e. unique loaded areas around each player), and this is yet another massive stack of work that would need to be done in order to achieve what Minecraft players ask for.

Obviously, these are simple examples. I'm trying to cover the easier to understand areas here, and as a result we're really glossing over the much more technical issues in the game, such as the fact that Minecraft is full of global mutable state or the fact that the current multi-threading constructs are full of bugs and very inefficient as-is.

The state in which Minecraft exists today makes it extremely difficult to parallelize the main server thread without a complete re-architecture of the game's code, which would be agonizingly painful from a mod's perspective. I'm not considering this in Lithium and quite frankly if I was to ever attempt it, I'd just make my own game rather than try to re-build another company's product.

Multi-threading isn't an easy thing to implement and someone can't just "add" it to their game as it would require a significant rewrite of how much works in the game, potentially introducing a lot of bugs and behaviour changes. There are also, as lithium proves, many other things that can be improved in minecraft's code other than "adding multi-threading".

Proper multi-threading would be nice tho ngl