Hacker News Reader

Comment by MrBuddyCasino | Hacker News Reader

One would think such relatively low-hanging fruit (dispatching to an existing avx512 lib) would have been picked by now, considering the massive effort to improve the JVM in other areas (virtual threads, value objects, C interop, Graal, novel GCs).

Maybe Array.sort() isn’t that frequently used, as data sorting is often done by the database?

View on HN

The big issue here (provided that I'm reading the PR correctly) is that it's purely for arrays of the primitive number types. Whereas most real applications (that I've seen) will be sorting objects by some (potentially computed) property, be it an ID, a timestamp or a name. For all of these cases, the linked pull request won't be doing anything useful. The most useful application for this (outside of getting nicer numbers on a benchmark) that I see is computing the median/quantiles of some property on a bunch of objects that aren't already sorted by the interesting property.

You still see quite a lot of primitive number sorting in library code. If you want your Java code to go fast, you typically stick to primitives in arrays.

Most Java application code doesn't, but it typically uses libraries that do. A sorted array is a priority queue, a binary search tree, etc.

I think the number of applications that will see a measurable speed-up from this improvements is very small.

If you have an application that is truly bottlenecked the performance of number-sorting in any measurable way, then you most probably didn't write it in Java. It's not really a number crunching language for a variety of reasons.

Java high-performance programming would be significantly improved by generics over primitive types. Writing performant code in Java feels like writing Fortran or C.

You end up using libraries like fastutil, which is "generic code" templated by C preprocessor macros,

https://fastutil.di.unimi.it/

> Java high-performance programming would be significantly improved by generics over primitive types.

This is planned as phase two of Project Valhalla [0]:

    The second phase will focus on generics, extending the generic type system 
    to support instantiation with inline classes (which will include primitives), 
    and extending the JVM to support specialized layouts.

[0] https://cr.openjdk.org/~briangoetz/valhalla/sov/01-backgroun...

Sure and I'll be happy to use it when available assuming I'm still working with JVM applications then. Meanwhile I'll still be stuck with fastutil-style templating for another ten years and it kinda sucks.

(Scala has specialization and value classes and opaque types so that covers a fairly big range but they make interop with Java tricky.)

Project Valhalla has been announced 9 years ago and nothing relevant is in the JDK yet, I don't think this will be relevant for day-to-day Java for several more years at least.

Probably, but "nothing relevant is in the JDK yet" is not quite fair. Several sub-projects are in "Preview Feature" [0] status, which is defined as "a new feature of the Java language, Java Virtual Machine, or Java SE API that is fully specified, fully implemented, and yet impermanent".

This includes JEP 401 "Flattened Heap Layouts for Value Objects" [1, JEP 402 "Enhanced Primitive Boxing" [2], and I think also "Value Objects" [3] and "Universal Generics" [4].

It is a huge task with many dependencies and requires careful design. It feels like it might finally make it in the next long term release.

[0] https://openjdk.org/jeps/12

[1] https://openjdk.org/jeps/401

[2] https://openjdk.org/jeps/402

[3] https://openjdk.org/jeps/8277163

[4] https://openjdk.org/jeps/8261529

Reply on news.ycombinator.com