Seems like a nice win even if it just does the example they have:
void matmul(Matrix2DFloat A, Matrix2DFloat B, Matrix2DFloat C, int size) {
for (@Parallel int i=0; i<size; i++) {
for (@Parallel int j=0; j<size; j++) {
float sum = 0f;
for (int k=0; k<size; k++)
sum += A.get(i,k)*B.get(k,j);
C.set(i, j, sum);
}
}
}
But the elephant in the room is the Vector API. Is that going to end up like logging - a standardised API nobody uses because it came 10 years late to the party and isn't as good as what was already established?
And why confuse everybody by calling it a VM when it ships as a JAR file that runs in an existing VM?
i might be overly optimistic, but I'm assuming it'll do the tiling by itself with the above. As long as there's not an algorithmic reason to do it a specific way, in theory you could just optimise it for the target hardware.
... which is a single JAR that does SIMD accelerated inferencing of local models, dependency free. Everything is written in Java from the tokenizer up. It can also use Metal on macOS. Small models can be surprisingly powerful these days and all you need is a fast CPU. It works not only for LLMs but also image models, video models and speech.
Remarkably, it is significantly faster than llama.cpp on some tasks like prefill (decode is memory bandwidth constrained so language hardly makes a difference). At least as long as you run on GraalVM (JVM or native image, both work). So you can actually beat C++ performance for AI in Java.
https://github.com/beehive-lab/TornadoVM this is main repo.
You can use it with any JDK21+ and Nvidia or Apple hardware and their Nvidia libs or MLX libs.
And what about TPU support? Is it compatible with Google TPUs or strictly limited to gpu backends like CUDA and Metal?
no TPU support yet, just NVIDIA, Apple and any other HW thats supports OpenCL
Seems like a nice win even if it just does the example they have:
But the elephant in the room is the Vector API. Is that going to end up like logging - a standardised API nobody uses because it came 10 years late to the party and isn't as good as what was already established?
And why confuse everybody by calling it a VM when it ships as a JAR file that runs in an existing VM?
what about tiling? seems better to call into existing kernels, fused megakernels than rewrite kernel in java.
i might be overly optimistic, but I'm assuming it'll do the tiling by itself with the above. As long as there's not an algorithmic reason to do it a specific way, in theory you could just optimise it for the target hardware.
I actually use the logging API, it is good enough, and maybe I am old enough not to like to cowboy install dependencies if I can avoid it.
Does this mean we can use Java to build AI infrastructure?
Or an abstract AI infrastructure factory?
https://github.com/beehive-lab/jitllm there is already an vllm-like inference engine that uses tornadovm as the GPU backend all written in java
I'll be disappointed if this isn't named AbstractAiInfrastructureFactory
These kind of complaints get tiresome, here for some Objective-C fun,
https://github.com/Quotation/LongestCocoa
That’s probably the next thing after Software Factories.
Yes (or any JVM lang). There is also this:
https://qxotic.ai/
... which is a single JAR that does SIMD accelerated inferencing of local models, dependency free. Everything is written in Java from the tokenizer up. It can also use Metal on macOS. Small models can be surprisingly powerful these days and all you need is a fast CPU. It works not only for LLMs but also image models, video models and speech.
Remarkably, it is significantly faster than llama.cpp on some tasks like prefill (decode is memory bandwidth constrained so language hardly makes a difference). At least as long as you run on GraalVM (JVM or native image, both work). So you can actually beat C++ performance for AI in Java.
It's impressive stuff.
Why GraalVM specifically? Is it something special with the Graal JIT?
It optimizes more aggressively, yes.
Basically JAX for Java instead of Python
Many components for a jax for java are already tested in https://github.com/beehive-lab/jitllm
"your scientists were so preoccupied with whether they could they didn't stop to think if they should"