5 ms·

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 Ob

by yazzku 2y ago

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.) [1] https://github.com/JOML-CI/JOML/blob/main/src/main/java/org/joml/Vector3f.java#L699 https://github.com/JOML-CI/JOML/blob/main/src/main/java/org/...

neonsunset 2y ago
> Vector API 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.
- yazzku 2y ago
  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.
  - neonsunset 2y ago
    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.
foobazgt 2y ago
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. 1) https://www.jetbrains.com/help/inspectopedia/boxing.html#locating-this-inspection https://www.jetbrains.com/help/inspectopedia/boxing.html#loc... 2) https://github.com/vigna/fastutil https://github.com/vigna/fastutil 3) https://github.com/jOOQ/jOOU https://github.com/jOOQ/jOOU

by yazzku 2y ago

neonsunset 2y ago

> Vector API 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.

yazzku 2y ago
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.
- neonsunset 2y ago
  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.

foobazgt 2y ago

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. 1) https://www.jetbrains.com/help/inspectopedia/boxing.html#locating-this-inspection https://www.jetbrains.com/help/inspectopedia/boxing.html#loc... 2) https://github.com/vigna/fastutil https://github.com/vigna/fastutil 3) https://github.com/jOOQ/jOOU https://github.com/jOOQ/jOOU