Java is a piece of crap with JVMs imposing an 8-24 byte overhead per object, which destroys caching, memory footprint, and any chance of low-level optimization. Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable. That, along with lacking SIMD, imposing stupid decisions like bounds checks on all array accesses, making arrays boxed (int[] is not an array of ints, sorry), or using exceptions for control flow, which is the wrong way to use exceptions, is a just part of the big laundry list of why Java is a piece of obsolete crap that nobody serious about low-level hardware programming uses. Java SE/ME is a fucking joke, as is every book I have read about "high performance Java". People who promote Java for low-level hardware programming, real-time systems, and the like, just have absolutely no fucking idea what they're talking about and they get their garbage published only because of the low standards of publishing nowadays. They do get the "Java Champ" badge from Oracle, though. Noobs award other noobs badges, as it turns out.
You want project Valhalla, or more specifically Value Objects, which are in preview [0]. If you really want the highest performance related to cache accesses, you want to arrange things as SoA (struct of arrays) anyway, which has approx 0 object overhead and doesn't require Value Objects.
> Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable.
This is silly. This happens with all other languages, and Java will give you better results on average. Use a different compiler or runtime for your C code, or run it on a different processor architecture, and have fun tuning your code.
> That, along with lacking SIMD
The Vector API [1] is available in preview.
> imposing stupid decisions like bounds checks on all array accesses
It's widely understood that doing the opposite has been perhaps one of the largest mistakes in the history of the industry. JITs elide access checks when safe, and it's easier for them to do with high performance code that doesn't bounce around in memory and thrash cache.
> making arrays boxed (int[] is not an array of ints, sorry)
What does this even mean? An int[] is a linear array of 32-bit int values in memory.
> or using exceptions for control flow, which is the wrong way to use exceptions
Are we now just talking about a small slice of people who write bad code?
> is a just part of the big laundry list of why Java is a piece of obsolete crap
I appreciate your response. My original post was a rant for sure, but let me reply to your comments.
> You want project Valhalla, or more specifically Value Objects, which are in preview [0]. If you really want the highest performance related to cache accesses, you want to arrange things as SoA (struct of arrays) anyway, which has approx 0 object overhead and doesn't require Value Objects.
SoA requires unboxed arrays, otherwise it defeats the purpose. I may have been wrong about int[] being boxed (it seems to be unboxed in most implementations), but the fact that ints still auto-promote to Integer in certain circumstances is just ridiculous for any kind of low-level programming.
It's also hilarious that Value Objects are still in preview. Even C# has had structs (value semantics) since forever.
> This is silly. This happens with all other languages, and Java will give you better results on average. Use a different compiler or runtime for your C code, or run it on a different processor architecture, and have fun tuning your code.
This is false. structs in C or C++ don't have a language-imposed overhead. They may have different sizes depending on the alignment requirements of the platform.
> The Vector API [1] is available in preview.
Also hilarious. It's 2024.
> It's widely understood that doing the opposite has been perhaps one of the largest mistakes in the history of the industry.
Checking every single array access in a tight loop, for example, is stupid. It's the naive, dumb, and inefficient way of doing it (i.e., the Java way.) The right way to do it is to enforce up front that the index may never be out of bounds. Ada helps with this by having user-defined ranges and integer types, for example.
> What does this even mean? An int[] is a linear array of 32-bit int values in memory.
Yes, I think I botched that one, but see also my comment above.
> Are we now just talking about a small slice of people who write bad code?
No, I am talking about Java.
> Ah, ok. Have a fine day.
Oh, and how does Java do low-level systems programming without unsigned integer types, lol? Oh, yeah, you need to cast to/from the next largest integer representation so that you can encode all of the positive values. And you better hope you don't need more than the native size, because then you get fuck-boxed into Integer (see my comment above.) Fucking hilarious, y'all.
Also, you don't even have a guarantee that a variable is allocated on the stack even when the dumbest compiler can tell it's bound by function scope. You need to hope that the JIT will do it, and from my past experience in Android (which this post is about), it doesn't. This is why, for example, if you look at the math library of LWJGL [1], all functions are defined to mutate one of the arguments, they never allocate a new vector to return. This is just completely stupid because mathematical vectors should have value semantics and the compiler optimize the fuck out of them. (Don't get me wrong, I love LWJGL and the guys. This is a criticism of the language, not the library; they are doing the best they can given the language's stupid decisions.)
In all fairness, simd<T> in C++ and portable-simd in Rust are both in preview. Not that there is a lack of alternate options there but still.
The languages that do have these APIs stable are Swift, C#, Mojo, Zig and Julia if I’m not mistaken. Stability means different things for some of these as Mojo and Zig are young languages.
C++ compilers today already auto-vectorize simple loops, even without manual unrolling. For manual SIMD, I agree a built-in type would be best to abstract over the 10 different HW APIs.
This is true, but it is also very brittle and cannot kick in where compiler cannot assert that e.g. source and destination do not alias, where it might change semantics or where there might be side-effects that the compiler cannot hoist out of the loop body on your behalf.
Which is why most code that really cares about optimal HW utilization is vectorized explicitly - it's problematic to assert against potential regressions between compiler versions and addressing them is just as brittle.
FWIW, I spend a lot of my time writing low-level code, but more for desktop/server machines and less-so for mobile.
> SoA requires unboxed arrays, otherwise it defeats the purpose. I may have been wrong about int[] being boxed
Yeah, that's wrong. Primitive arrays aren't "boxed". An int[] is not an Integer[], and no boxing is performed unless you ask for it. SoA is fine in Java.
> the fact that ints still auto-promote to Integer in certain circumstances
It's pretty easy to avoid boxing if you don't want it. They are separate types after all. Even so, Android lint has an inspection for it, and Intellij (presumably Android Studio too?) has an inspection you can turn on to detect it [1]. If you're running afoul of autoboxing, it's probably mostly in collections-based code and you'll want something like fastutil [2].
> It's also hilarious that Value Objects are still in preview.
Agreed, it's been a long time coming, but they've been doing a good job of releasing features that don't need deprecating five years later.
> This is false. structs in C or C++ don't have a language-imposed overhead. They may have different sizes depending on the alignment requirements of the platform.
Sorry, I misunderstood your comment. You were talking about different overheads on different platforms, and I read that as general overhead. (For example, if you run the exact same x86_64 binary on an Intel and AMD processor from the same generation, you can get drastically different results. Heck, you can get drastically different results within the same family from the same manufacturer for a half-dozen reasons). In any case, I wouldn't lose sleep over the varying size of object headers on different platforms. In the cases it matters, you should be avoiding them altogether.
> Also hilarious. It's 2024.
I don't know when Valhalla will land, but the Vector API is far smaller in scope. It's on its 8th incubator, and seems likely to land soon. You could give it a try.
> Checking every single array access in a tight loop, for example, is stupid.
This is a red herring in most situations. Your array accesses did get elided, you need to rewrite your code so it's easier for them to get elided, or the checks didn't have a performance impact. Also, you dev for mobile in Ada?
> No, I am talking about Java.
You must not be, because there are no exceptions used for control flow in code I write or review.
> Oh, and how does Java do low-level systems programming without unsigned integer types, lol?
It's annoying. You don't cast, you promote through a mask, e.g. val & 0xFF; That said, jOOU [3] looks interesting.
> And you better hope you don't need more than the native size, because then you get fuck-boxed into Integer
I don't understand this. You aren't using more than "native size" on any platform in any language without some sort of emulated Big* type.
> Also, you don't even have a guarantee that a variable is allocated on the stack even when the dumbest compiler can tell it's bound by function scope.
Implementations typically have both escape analysis and a nursery generation for this. This works well in a desktop/server environment. I can't speak to ART. Ultimately, Valhalla will solve this for constrained implementations.
> I love LWJGL
I'm knee-deep in GDX and LWJGL, right now, but again not in a mobile context. I used to hang out in the Java gaming forums with the folks who originated LWJGL (e.g. cas).
> This is a criticism of the language, not the library
I think your criticisms are mostly with ART. I agree there are a handful of language changes that would make things easier for ART.
> Yeah, that's wrong. Primitive arrays aren't "boxed". An int[] is not an Integer[], and no boxing is performed unless you ask for it. SoA is fine in Java.
Yes, I botched that one, agreed.
> It's pretty easy to avoid boxing if you don't want it. They are separate types after all. Even so, Android lint has an inspection for it, and Intellij (presumably Android Studio too?) has an inspection you can turn on to detect it [1]. If you're running afoul of autoboxing, it's probably mostly in collections-based code and you'll want something like fastutil [2].
Autoboxing is a contradiction of "It's pretty easy to avoid boxing". It's specifically egregious for any place where you need performance guarantees.
> I don't understand this. You aren't using more than "native size" on any platform in any language without some sort of emulated Big* type.
Because you don't have unsigned integers (or arithmetic). So, for example, if you're playing with a 16-bit unsigned value, then you need a 32-bit signed integer to hold the 16 bits you care about (and you can kind of pretend you have 16-bit unsigned arithmetic.) But if you need a native-sized unsigned integer, you're out of luck.
> Implementations typically have both escape analysis and a nursery generation for this. This works well in a desktop/server environment.
Not on Google's VM the last time I tried. Shit went on the heap and the "concurrent" GC would then stall the entire application for ~1s every ~10s.
> I'm knee-deep in GDX and LWJGL, right now, but again not in a mobile context. I used to hang out in the Java gaming forums with the folks who originated LWJGL (e.g. cas).
I used to be on #LWJGL on Freenode, but it seems the guys moved to Discord or something.
By the way, we haven't talked about how horrible the JNI is, which requires you to wrap every C function so that you can pass around the JNIEnv handle and to manually marshal data structures to/from, like you're writing fucking Lua bindings or something. The right way to do FFI is the Haskell way, where you just call the function and get compiler support for auto-marshalling data structures (and, if you want, you can get your Haskell program to build and statically link the C library from source; no need to compile separately using another build tool and then dynamically load a shared lib.) Even C# does it better than Java. So in the use case where you have optimized C code and the rest of the application in Java, even the bridge itself is a pain in the ass to write.
I feel so out of place when interviewing for firmware/embedded roles and the interviewers turn out to be java snobs. I honestly still have a hard time comprehending the situation; how does it come to this? Thanks for your insight
It's really sad. I think Java is a rather ill-designed and boring language, not even worth learning for intellectual purposes, but it does have a mature ecosystem around databases, web services and stuff, and it has its use cases. Beyond that, it really beats me where this attitude comes from. I attribute it to living in your bubble and not exploring what the guys over on the other side of the fence are doing. This is why one should learn as many programming languages (and paradigms) as possible, even if you don't end up using half of them. It's like when those guys come out with a new "minimalist" CSS framework, and the bitch downloads a 2MB payload just to bootstrap your "hello world".
Java is a piece of crap with JVMs imposing an 8-24 byte overhead per object, which destroys caching, memory footprint, and any chance of low-level optimization. Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable. That, along with lacking SIMD, imposing stupid decisions like bounds checks on all array accesses, making arrays boxed (int[] is not an array of ints, sorry), or using exceptions for control flow, which is the wrong way to use exceptions, is a just part of the big laundry list of why Java is a piece of obsolete crap that nobody serious about low-level hardware programming uses. Java SE/ME is a fucking joke, as is every book I have read about "high performance Java". People who promote Java for low-level hardware programming, real-time systems, and the like, just have absolutely no fucking idea what they're talking about and they get their garbage published only because of the low standards of publishing nowadays. They do get the "Java Champ" badge from Oracle, though. Noobs award other noobs badges, as it turns out.