Noisium

[Madis0]

CurseForge link

https://curseforge.com/minecraft/mc-mods/noisium

CurseForge Mod Distribution

Allowed

Modrinth link

https://modrinth.com/mod/noisium

Source/other link

https://github.com/Steveplays28/noisium/

Mod file size

34.7KB

License

(any other license)

What it does

Worldgen performance optimisation mod for Minecraft, which speeds up chunk loading. Noisium is meant to fill in the gaps, worldgen performance wise, left by other mods currently. For me, the performance improvements lie between 20-30% for the methods that are optimised.

It's fully compatible with other optimisation mods, such as C2ME and Lithium. It also fully works with any terrain generation (e.x. vanilla, datapack, and modded).

Why should it be in the modpack

• Performance improvement
• Said to be very compatible with other mods

Why shouldn't it be in the modpack

• I'm afraid of differing worldgen - tests with seeds are needed
• Is it really that impactful, considering we already have Lithium and chunk loading improvements of 1.20?
• Singleplayer and LAN only (though it is not necessarily an issue, as Lithium seems to be similar)

Additional details

No response

[AnOpenSauceDev]

Just quickly glossing over the code, nothing seems to be game-breaking here. I can't vouch for compatibility, as it uses @Overwrite mixins, that could probably be replaced with a few less-destructive mixin types.

^ This is outdated now.

[AnOpenSauceDev]

* Is it really that impactful, considering we already have Lithium and chunk loading improvements of 1.20?

Absolutely, I see a roughly 11-30% performance boost per call in my own testing. This coupled with A) the fact that minecraft calls these methods a lot on world load, and B) that the mod also multithreads one of the laggier types of these generation calls, chunk building is a lot faster on my machine w/ high render distances.

[Madis0]

Some users on Discord see less or vanilla-equivalent world loading times. More tests are needed to evaluate.

[AnOpenSauceDev]

In my testing, it's not actually chunk loading that is faster, but rather new chunk generation. Loading up an already-existing world probably wont have a difference for that reason.

[brl0]

I am a recent convert just passing by, so my input shouldn't be taken too seriously, but I wouldn't want to use this if it had any chance of changing the world generation at all.

While I am here, thanks to the maintainers and contributors who make this such an awesome modpack, your efforts are much appreciated!

[AnOpenSauceDev]

I am a recent convert just passing by, so my input shouldn't be taken too seriously, but I wouldn't want to use this if it had any chance of changing the world generation at all.

Just to clarify, Noisium does not use a faster noise algorithm that might deviate from what minecraft + mods use, but instead optimizes what's already there. The name is a bit of a misnomer, as it just makes sampling and blockstate placement faster. Not every mod has to or inherently will break compatibility just because it changes a core feature.

[RedGreenBlue09]

It is in fact 20-30% faster when generating new chunks, which is not significant imo.

[AnOpenSauceDev]

It is in fact 20-30% faster when generating new chunks, which is not significant imo.

30% is still 30% :shrug:, and I've done far more destructive optimizations in my own mods to gain 15% more performance before. Considering that it also multi-threads noise sampling means it could be faster on newer hardware.

[RedGreenBlue09]

@AnOpenSauceDev I'm using this mod outside of FO personally because yeah, the gain can be noticed. But in context of this modpack, I think it's not that significant.

Edit: Nvm, I think this 30% increase can be significant on slow CPUs, especially when travelling to non-generated regions.

[davidstraka2]

This would be especially useful addition if Distant Horizons (#240) was ever to be added to the modpack. From Noisium's description:

Distant Horizons: Noisium speeds up LOD world generation threads, since LOD generation depends on Minecraft's world generation speed.

[TheBossMagnus]

It is in fact 20-30% faster when generating new chunks, which is not significant imo.

30% is still 30% 🤷, and I've done far more destructive optimizations in my own mods to gain 15% more performance before. Considering that it also multi-threads noise sampling means it could be faster on newer hardware.

Maybe the tasting method wasn't right, but i and another user tried benchmarking its impact measuring the time to generate an x radius of chunk via chunky. We had results in the margin of error identical to vanilla (at best -5%, but even some +3%)

[AnOpenSauceDev]

Interesting, what machine was this tested on? I'm curious if this is because the disk or ram is being bogged down (because chunky usually gets very slow when one of the two are saturated).

This issue prevents me from using chunky as a benchmark for stuff, because usually something else gives way.

[TheBossMagnus]

Interesting, what machine was this tested on? I'm curious if this is because the disk or ram is being bogged down (because chunky usually gets very slow when one of the two are saturated).

This issue prevents me from using chunky as a benchmark for stuff, because usually something else gives way.

I don't think so, it was tested on a Ryzen 9 7945hx, rtx 4080m, Samsung 980 pro 1tb, 16gb ddr5

[ExecuteOrd66]

On my machine (Ryzen 3 3100, and 16GB DDR3 3200MHz Cl16 RAM), the speedup is noticeable, and worth it in my opinion. I'll see if I can do more concrete benchmarks and I'll report to you all later

[ExecuteOrd66]

Interesting, what machine was this tested on? I'm curious if this is because the disk or ram is being bogged down (because chunky usually gets very slow when one of the two are saturated).

This issue prevents me from using chunky as a benchmark for stuff, because usually something else gives way.

I don't think so, it was tested on a Ryzen 9 7945hx, rtx 4080m, Samsung 980 pro 1tb, 16gb ddr5

The performance drop might be caused by the threads being executed on different CCDs across your CPU, introducing additional latency. https://www.reddit.com/r/Amd/s/yQ98PaJmoN

[AnOpenSauceDev]

In that case, only allowing minecraft to run on cores within the same CCD for the benchmark should show the difference straight away. (possibly disable 8 cores?)

I will say that literally just getting the nano time at the start and end of a method already shows that aforementioned 11 to 33% uplift, so it's technically "objectively faster" from a CPU perspective.

[TheBossMagnus]

In that case, only allowing minecraft to run on cores within the same CCD for the benchmark should show the difference straight away. (possibly disable 8 cores?)

I will say that literally just getting the nano time at the start and end of a method already shows that aforementioned 11 to 33% uplift, so it's technically "objectively faster" from a CPU perspective.

Is this misurable in real Minecraft? How?

[AnOpenSauceDev]

Windows and Linux have something called "affinity". It's pretty easy to go do on windows via task manager, but it essentially only lets a program run on certain cores.

When I was talking about the "nano time benchmark", I literally am referring to getting System.nanoTime on the same seed at the method start and end to see the difference vs. vanilla over thousands of trials.

[AnOpenSauceDev]

I found something pretty interesting when starting a Fabric server on 1.20.1 on my underclocked 2x E5-2680V2 server, running off of HDDs.

It seems that C2ME + Noisium + Faster Random (was testing my own mod at the time too) makes every core work significantly less harder, even with 6+ players flying around a mostly ungenerated world. And this is between two different CPUs. TPS almost never dropped below 20 for me.

Before, the world would frequently hitch (and even sometimes timeout everyone) when lots of chunks got generated, even with C2ME. Adding Noisium and (biased) Faster Random instantly turned my server from a space heater at 100% per core into being almost unnoticeable. Pregeneration is completely unessecary for my servers now.

So when lots of chunk generation tasks are distributed across lots of threads and cores via C2ME, there seems to be a massive performance improvement from parallelization, and any further performance uplift is spread across all the cores. (when every core is doing worldgen-related work, that's 30% x 40 = 1200% less time spent sampling noise)

So it seems that Noisium is useful alongside C2ME when travelling fast through a world, especially if in a multiplayer situation. When I am able to again, I will benchmark this with just Noisium. I don't think that CCD latency has anything to do with this.

On my machine (Ryzen 3 3100, and 16GB DDR3 3200MHz Cl16 RAM), the speedup is noticeable, and worth it in my opinion.

I also notice chunks generating faster on my cursed 1 CCD Ryzen 3500X machine, But even working across CPUs I still see (and feel) a significant performance improvement (chunks generate as if they were being loaded from an SSD in singleplayer). Perhaps something is being bottlenecked by Chunky, but I haven't looked at the code for it yet.

It's worth noting that I've only tested on Debian Linux (as a server and as a VM), Ubuntu Server, Ubuntu Linux, Pop!_OS and briefly Raspberry Pi. I haven't tested on windows at all, and that might be causing less performance.

[cochcoder]

I've done some brief testing on a single player world and noticed faster generation with this mod. With just the modpack it would take 2 minutes and 5 seconds to load sixteen chunks, while it takes 1 minute and 40 seconds with Noisium in a worst case scenario. In one world, it took the modpack ~45 seconds to generate the equivalent of 5-10 seconds with Noisium (12-14 chunks).

Even some cases won't see a major time reduction, it feels faster as chucks are loaded more consistently around the player and rarely, if ever, has a group of chunks take forever to load, which is something I run into consistently, without this mod.

Considering the performance improvements that weaker systems gain from this mod, while having a stable experience, I think that this mod will be a good addition to this modpack.

[TheBossMagnus]

How have you measured the time to load 16 chunks? 2 min+ feels a bit off...

[cochcoder]

How have you measured the time to load 16 chunks? 2 min+ feels a bit off...

I used a stopwatch, it was a crowded forest and my computer is really slow when it comes to generating chunks.

[AnOpenSauceDev]

Just upgraded to a 5700X, and to create a world in vanilla, it's about 3.1 seconds on average. With Noisium it's roughly 2.7s on average.

[nyabinary]

Just upgraded to a 5700X, and to create a world in vanilla, it's about 3.1 seconds on average. With Noisium it's roughly 2.7s on average.

Can reproduce

[nyabinary]

If this is added, it probably should be added along with C2ME (C2ME: every world generation thread runs faster. The biome population multithreading is also done in a much better/more performant way in C2ME, so it's been removed from Noisium since v1.0.2. It's suggested to run) - From Noisium mod page. #39

[Firebolt360]

After running tests with inputs lined up in an editing program, I've found that Noisium's inclusion in a Fabulously Optimized-adjacent performance modpack (no C2ME or Faster Random, but with Nvidium) for 1.21.1 did give me consistently faster world load times from the "Create new world" button to seeing the first frame of the sky. I experienced a range of 5-30% improvement favoring Noisium across 3 tests for each of the 2 mod configurations.

Additionally, when flying at the same height and starting to fly forward at the same moment in the newly created worlds (granted, possibly off by a couple frames, but corrected in the editing program so the tests lined up in terms of the moment I started moving forward immediately after pasting a teleport command in chat to y=160), there was no huge visual difference in chunk load times. However, pausing on different frames showed Noisium slightly ahead in terms of how far I could see chunks loading on screen, which was also consistent across the 3 tests for each mod configuration. My testing was on a high-end PC at a render distance of 32.

[Firebolt360]

After more testing, I also haven't noticed any issues with world gen parity compared to vanilla. Not that there would be any since that's not how Noisium works, but I thought I'd mention it. Seems consistent with vanilla's own random noise (grass, clay patches underwater, seagrass, etc.).