|
|
|
|
|
|
by SleepyMyroslav
21 days ago
|
|
|
as for my experience, yep I do not have Java experience and a long list of C++ projects. > what is exactly that you'd think makes Java harder to compile in an optimised way than C++? In games C++ is doing some simulations and data delivery for GPU. Code that does work on GPU is not mixed with rest of C++ code. So invoking Cuda (or the likes) in the middle of computation is a cheat code that Java does not have. Simulations on the CPU need to be efficiently parallel ( think 12 hardware threads for last gen or 4-6 threads for smaller platforms) and most likely specialized for hardware SIMD ( think AVX2 for last gen or SSE2 like for smaller platforms). To wrangle multi GB data efficiently a lot of compression/decompression and data structures are needed. Does Java still has overhead per class instance? It might force designs with arrays of primitive data types that are more verbose. Add there per platform I/O and everything. It means that games force people to unlearn everything that language ever thought about standard I/O. Even more about being cross platform. In C++ it means something completely different. In C++ you can't trust language implementation vendor with anything. From your comment I assume that Java teams rely on language implementation in lots of ways. In C++ being efficient means do it yourself. How efficient our memory allocation is? Answer can only be per engine/project. There is no 'average' because 'vendor provided' is the bottom of the barrel quality. No one is improving vendor provided exactly because no one is expected to use it. In short there are hard to compare many different C++. I can't see them compare to each other much less to other programming languages like Java. This might be not the answer you wanted but that's all I have. |
|
|
It does (and has since JDK 22). But what we're working on now is JIT-compiling Java code to CUDA (not arbitrary code, but certainly code that's suitable for a kernel): https://openjdk.org/projects/babylon/articles/hat-matmul/hat...
> and most likely specialized for hardware SIMD ( think AVX2 for last gen or SSE2 like for smaller platforms)
Yep, we've had good SIMD support for a few years now. (https://javapro.io/2026/04/09/java-vector-api-faster-vector-...)
> Does Java still has overhead per class instance? It might force designs with arrays of primitive data types that are more verbose.
That is the last area where Java is still behind but the work on arrays-of-structs (with no headers) is nearly complete. A first release of that is imminent.
> In C++ being efficient means do it yourself
Right, and that's precisely what I meant about low-level languages being optimised for control and not performance. You could do things at such a low level in Java, but the main problem is not the performance but that it's just less convenient than in C++.
Anyway, aside from some outdated (or soon-to-be-outdated) things, what you pointed out is mostly about lack of convenient direct low-level control rather than general performance, and that is exactly when low-level languages can be a better fit.