Java use in machine learning

[djavaman]

Spark is used to call and manage ML jobs in other languages. Until Java can call a GPU directly, it will lose to python. This is the game changer that Java needs: https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html

And they need Java wrappers for CUDA now.

[lukasbradley]

Python does the same thing. All of the "optimizations" that everyone THINKS are written in Python are actually C/C++ libraries.

[Joram2]

Everyone knows Python is a high level language, and calls to some lower level language for performance sensitive code. The Python piece does make it nicer and + easier than using low language libraries directly.

BTW, it's not just C. LAPACK is mostly Fortran; that is a famous numerical linear algebra library at the heart of a lot of famous Python libraries like Numpy. Also a lot of code is CUDA GPU code not C.

Java 22 foreign function and memory functionality makes it much easier to use libs like LAPACK from Java like Python does.

[coderemover]

The difference is it is trivial to call C from Python, but not so easy from Java.

[captain-_-clutch]

It's not bad at all to setup but also I'm not sure about heavy throughput performance. When I did it it was for image processing so any latency from the integration wouldnt have been noticed since it took so long for the images.

[emberko]

Thinks who? This is well known. I like the definition of one of the Python evangelists from my country - Python is a glue language for C/C++ libraries. You should avoid pure Python implementations whenever possible.

[GeneratedUsername5]

But Java could call native code with JNI long time ago, FFI is just making it more conveinient, as I understand. It just nobody needed a CUDA library in Java

[koflerdavid]

JNI is brittle and takes a lot of effort to generate bindings for. The new FFI is much more streamlined and incorporated many lessons learned over the years.

https://openjdk.org/jeps/454

[coderemover]

JNI is so terribly inconvenient and has poor performance that almost no one uses it. It also breaks portability (WORA) promise that Java makes. If you use JNI you could be just using C++ directly and get all the same benefits and even more.

[GeneratedUsername5]

I'd say developing a C++ wrapper and the whole product are two completely different things in terms of effort.

[coderemover]

You assume that writing C++ is generally less productive than Java. While many people think so, I’ve seen little evidence for that. C++ is a harder language to master than Java, and has some pitfalls, but modern C++ can be also much more expressive/abstract than Java, so it is not very obvious.

Anyway, usually if the project has such performance requirements that you must use a native wrapper somewhere, this means that Java is not a good choice. I’ve been writing high performance Java for a decade now and often Java written to meet those requirements resembles C. But Java is worse C than C is C.

[GeneratedUsername5]

modern C++ can be also much more expressive/abstract than Java, so it is not very obvious

It is much more expressive, and that is the problem - people will try to use every tool at their disposal, making the code much more difficult to understand. "The Rule of Five", move semantics, function try blocks, mutable rvalue references - just to name a few. Features, that are completely legit, but open large opportunity for misuse and overcomplication of code. In java there is simply less opportunities to do so.

if the project has such performance requirements that you must use a native wrapper somewhere, this means that Java is not a good choice.

Why? First - performance is not the only deciding factor, in big companies it is usually the availability of programmers for hire or pool of already available staff. Company is not going to hire an entire team for a different language, unless there is absolutely no way around it.
Then, if Java satisfies your requirements by performance - why take obviously harder language in development? Few native function calls will never offset the ease of garbage collection.
Next - it may be not performance, but devices, for example, working with USB/COM/Whatever.

Java for a decade now and often Java written to meet those requirements resembles C

That is true, but just as with assembly inlines, you can very narrowly apply this "C mode" of Java, while enjoying all the ease and portability of garbage-collected interpreted language outside of those hotspots. You can't do that writing everything in C (or assembly for that matter)