AnOpenSauceDev
[OTHER]: Did you abandon the project?
Does an issue already cover this?
- [x] I have searched for any existing issues, and didn't find any.
Issue description.
The mod has not been updated since version 1.21.1
Technically not, although I generally have stepped away from modding for a long while.
I feel a bit guilty to maintain the mod, as the newer (and less unstable) versions in my testing it didn't give too much of a performance increase (below 5% iirc, and that number varied a lot), and still screwed with vanilla worldgen. I did have a branch that optimized how random works more, but had the earlier tradeoffs of making parts of the game unpredictable.
Because of that (and life), I haven't updated/published anything new in terms of mods. I don't think there's any reason for the modding community to use my mods for such a tiny performance improvement.
Randomization is used in 60% of calculations, it is difficult to call a tiny increase.
I think the problem with the mod is related to vanilla parity, because, like most popular Minecraft optimization mods (Sodium, Lithium, Starlight/ScalableLux, etc.), they do not change vanilla mechanics or parity. So, I believe you should focus on maintaining parity rather than adding new optimizations for now. As for the 'tiny increase,' I don't really think it's tiny, but even if it is, it's still appreciated by the modding community, as modpacks often consume many resources. It would be unfortunate to see this mod discontinued. But it is your decision if you want to continue it or not.
To add on to what others are saying here, I would really appreciate this being updated to 1.21.x for Neoforge. Framerates aren't the only form of optimisation this provides; terrain gen also gets optimised, and I've been struggling with Distant Horizons' slow speeds quite a bit.
I also don't see vanilla parity as super important, especially for those wanting a modded survival experience (like myself).
Sorry for the late reply,
I'm not too sure if I should update Faster Random, even if it's just a bump of what it currently is.
While DH does get a bit of a boost with nextInt calls iirc, I feel like the majority of worldgen random code (barring mods that might do some weird stuff) doesn't take up that much of the total generation time. I also think that other systems like Entities shouldn't be that big of a deal, at least for vanilla mobs.
I personally haven't been able to benchmark Faster Random properly due to some bottleneck showing up first (i.e thermals and RAM), and haven't really tested how it performs in heavily modded situations.
if you're seeing a major increase in performance from Faster Random, either:
- Some mod(s) are causing tonnes of repeated random calls every frame
- the state of 'optimized' worldgen (or DH LoD generation) is no longer mostly bottlenecked by I/O, RAM, or other CPU-related things
- worldgen mods are more random-dependent than I realized
I feel like anything noticeable here is likely the placebo effect or the first cause listed.
performance/modding rant
DH at 128 chunks + basic shaders runs at a 'playable' framerate as a LAN host on my 6-year-old Pentium laptop without Faster Random, so I don't know if it really matters much anymore?
While most users probably don't want to do this, doubling RAM with zstd zram and changing some settings for IO with the Linux Kernel made my performance go significantly higher than anything Faster Random might have done.
The performance bottlenecks for Minecraft are seeming to become low level to the point where I'm not sure if much more can be done without turning Minecraft into a completely new codebase for mod devs in terms of compatibility.
It also seems like there are some performance regressions in 1.21.4+, so Faster Random could appear to slow the game down to some if they directly jump up.
It just feels like nowadays it's pretty easy to get really good MC performance on anything that can at least run Windows 11.
I've also noticed that over time, some (smallish) server forks focused on 'performance' started to have code that resembled Faster Random's own code (I think even during the old, threadlocal generator versions). While I don't really care too much about the code itself, the usage of these generators was often undisclosed, and probably affected some (most likely vanilla) worlds without the hosts knowing.
I really don't want a similar thing to happen again, since it can make some interesting worlds non-replicable to the average player, which I also think is the kind of person most likely to be disappointed after trying out a seed to a world that was made using Faster Random-like code.
While I can delist my own mistakes, I can't stop others from copying them.
I haven't been in the modding scene for ages, so my opinions on some things might be wrong now, but I feel like I need more non-anecdotal evidence that Faster Random is helpful in some way before I potentially release something that I'll regret.
TL:DR: I'm not too confident in Faster Random's relevance in the realm of modern optimization mods, but if there is evidence that it really is helpful still, I will try to release an update.
I personally haven't been able to benchmark Faster Random properly due to some bottleneck showing up first (i.e thermals and RAM), and haven't really tested how it performs in heavily modded situations.
Hit me up if you need to run anything, your mod really helps a lot so I'd love to contribute.
I can code as well, but I've never done Minecraft mods before and mainly focus on Python projects, but I understand Java and OOPs.
Specs:
It does look like there are benchmarks for server worldgen nowadays like for C2ME, so Faster Random could be benchmarked with the same methodology (and maybe with other popular optimization mods to remove bottlenecks?). Mob performance could probably be done as a large farm in a void.
A large modpack could also be tested the same way, but that wouldn't be a reliable benchmark of mod-optimized worldgen. (it could be a good 'large multiplayer server' benchmark, though)
The two things I don't know how to test reliably is Distant Horizons worldgen and client performance (which does use quite a bit of random at times).
@AmazingGabriel16, Hit me up if you need to run anything, your mod really helps a lot so I'd love to contribute.
Thanks for offering!
Your system definitely has enough threads to do a similar benchmark, but I don't know if Windows has something comparable to straight tmpfs (a ram disk) in terms of speed. If so, please don't go overboard with a Linux install if you haven't used it before! You could use a VM (I don't think WSL2 handles tmp correctly) to test this safely.
Please don't feel pressured to do any of this though! I'll be able to do these tests myself when I upgrade my system later on.
Hey @AnOpenSauceDev,
I've got PopOS running on another PC, but unfortunately the specs are nowhere near mine.
Hit me up with a system image for virtual box if you want me to test things for you, I'd be happy to load it in and test the stuff.
Hey @AnOpenSauceDev , if you need me to help benchmark I could help, i have almost the same specs as AmazingGabriel, and if you need me to switch to Linux just for a test you can let me know
https://github.com/AnOpenSauceDev/FastRandom/issues/64#issuecomment-3082759755
I'm proud of doing my small part to revive this project :3 And, also excited to see this project get developed further, of course!
As far as my side of things is concerned, I have a Ryzen 7600 and an RTX 3090, running on Linux. If I can get a clear, idiot-proofed benchmarking process provided to me, I'm also down to contribute benchmarks. Though...
@AnOpenSauceDev
Your system definitely has enough threads to do a similar benchmark
...the 7600 is a 6-core CPU, so probably unsuitable?
I didn't expect there to be this much interest!
Hit me up with a system image for virtual box if you want me to test things for you, I'd be happy to load it in and test the stuff.
C2ME's benchmark just uses plain Debian, so you can install it to a fresh VM via iso, and download a non-headless jdk and FabricMC's server jar (debian also provides those broken headless jdks, so be careful!)
the 7600 is a 6-core CPU, so probably unsuitable?
I was referring to a near 1:1 of C2ME's 2-80 thread method, which falls off in the 30's (see footnotes), but these CPU's are quite different and might still show a difference on their 1-10 thread benchmark.
I don't really know how well Virtualbox handles virtualization though, and I think Window's Hyper-V alone is much closer to native performance (I haven't used windows in 3+ years, so I don't know if this is a big difference).
If anyone testing could also upload their spark profile from their run, it would be greatly appreciated!
C2ME's benchmark just uses plain Debian, so you can install it to a fresh VM via iso, and download a non-headless jdk and FabricMC's server jar (debian also provides those broken headless jdks, so be careful!)
Not sure how to do a C2ME benchmark, Googling doesn't show much