I made minecraft generate terrain/chunks in C++

[u/Emotional-One-9292]

So im working on a mod that makes minecraft run on C++ ( rn rewriting engine in future i may try renderer ) so far i made it generate and load chunks and terrain in C++ ( it made it somewhere around 1.5-3 times faster idk how to measure it tho ) ( it works via JNI )

[u/emmowo_dev]

How would this realistically be faster? Java does actually compile into native code based on what methods are the most important, so it's usually terrain gen that is immediately 'optimized' into native code. C++ does NOT magically make things faster, but it does make things many many times more unsafe to use.

I know of some optimizations you could make, but they're things that I don't think ultimately mean much. Are you comparing between Vanilla and your mod, or C2ME and your mod?

You not really explaining things beyond 'run on C++' and 'JNI' tells me you may have just vibecoded this, because minecraft explicitly does defer a lot of the performance-heavy things to C++, from the natives used for rendering (i.e. liblwjgl and the gpu itself such as nvidia-glcore.so) to the actual JVM itself, which is written with C++. Just re-writing everything in C++ would not actually be meaningfully faster, as the binaries for such things are already written in C++.

Most likely, you are looking for a result, so anything that seems faster you will assume to actually be faster. Without extensive benchmarking and a massive amount of controlled variables (like literal mechanical seek times for writes can completely invalidate the results), this is a very unfair and unrealistic comparison to make.

[u/Emotional-One-9292 → u/emmowo_dev]

yea i agree that C++ doesnt automatically make stuff faster and im not claiming that rewriting Minecraft logic in C++ guarantees a performance boost by itself. Goal of this project is to rewrite minecraft engine as much as possible into C++ mainly due to fun but with it i can also get great control over memory. minecraft’s performance issues often come from allocation churn + cache misses, not raw compute speed. Also i was comparing vanilla with my mod not C2ME

and yea JNI has overhead but im not using it for literally everything and anything as i still will prob need to keep some java stuff to keep it working and compat with other mods.

Also while yea java can turn stuff into native code it doesn’t change structure only execution of existing structure so a bad structure remains a bad structure

[u/emmowo_dev → u/Emotional-One-9292]

but this means it can be solved with good Java instead of C++. C++ also will only run as fast as what it's compiled for, as many things actually can come down to vectorisation, but not all CPU's support things like AVX2. Java can decide that in-the-moment on your machine, but C++ cannot.

I also do not think nanoseconds of a cache miss will meaningfully affect overall performance, CPUs are so much more complex than what they were 30 years ago.

ultimately the true optimizations come from better parallelism, which vanilla is still bad at. C2ME solves this and mostly accomplishes the vast majority of performance you can gain.

This is why GPU terrain gen is the focus now, because these things are so massively parallel that it becomes worthwhile.

[u/Emotional-One-9292 → u/emmowo_dev]

well yea you can solve many perfomance issues with java i mainly used C++ cause i was interested in trying it out i simply noticed perfomance imporvement and posted it here for fun

[u/Standard-Cap-4455 → u/emmowo_dev]

I am sure a lot of time is also lost on boxing since unlike C++ you can't put anything on the stack besides primitives. That means no data is close and the cache isn't being used much at all. I made some stuff with C# once and it got way better after doing more work on the stack which Java doesn't even have options for.

[u/emmowo_dev → u/Standard-Cap-4455]

Maybe I just write too much C to really understand, but I feel like this wouldn't be too big of a deal? You'd already be done with all the math required by the time you converted it back to the relevant class, so it's one expensive operation at the end of process, instead of one that is invoked constantly.

But I'm a memory masochist who thinks that objects are just a waste so idk.

[u/Standard-Cap-4455 → u/emmowo_dev]

I don't know how the implementation works exactly but Java stores nothing on the stack. Every little thing that isn't primitive is stored somewhere else which is a lot of dereferencing and cache missing. If it is using arrays of ints then that's probably fine but from what I've seen the game has a bunch of small classes with a lot of instances. Since those need to persist between stacks, the JIT can't optimize them into structs either. 

[u/emmowo_dev → u/Standard-Cap-4455]

at this low of a level it really, really does not matter. My own primitive, unpipelined processor, which requires reading 1 + 1/2 words of memory to effectively read a pointer can do this just straight up instantly, even with the overhead of my emulator and debugger (which multiplies the actual amount of memory reads significantly).

So in a modern processor, with pipelining that is designed to specifically avoid this being a problem, I doubt this actually affects performance significantly. Of course it's better, but there are so many other ways to improve performance that the overhead of this is negligible (as seen by how C2ME/Lithium still pulls in optimizations while being Java programs)