4 ms·
nice! This is the sort of area where it feels the JVM has some under utilised potential, as these type of optimisations can take advantage of the strong guaran
by zmmmmm 3y ago
nice!
This is the sort of area where it feels the JVM has some under utilised potential, as these type of optimisations can take advantage of the strong guarantees of the JVM runtime.
Am curious though if it can work with other SIMD AVX versions since AVX512 is only selectively supported. And what's the potential to go all the way and add OpenCL or CUDA implementations?
- sakex 3y agoYou typically wouldn't want an OpenCL or CUDA implementation because developers expect their code to be running on a single core. If random functions started using multiple cores or running or the GPU, it would become very difficult to manage core allocation of highly parallel programs. On the other hand, they could provide a different function (GPUSort for instance) but they shouldn't replace the default one with different threading requirements.
- Cthulhu_ 3y agoI'm of a different opinion there. When I call e.g. sort on a list, I write what my intent is, the what; I don't care about the how, and I'd rather have the JVM decide to do a multicore / gpu driven optmized sort than that I have to think about implementation details like that. If I want to fine-tune my implementation and write code that works well with the underlying hardware, I'd write it in a language more appropriate for that particular goal. Java is for business applications, where the developer expresses what the code should do; lower level languages (C, Rust, etc) give the developer more options and responsibility in the how it should do it. Simple example, for-loops vs functional functions (map, reduce, etc); the former is the how, the latter is the what.
- h4x0rr 3y agoEven in java, you often times care about threads / core utilization. For example in a web api, you typically don't want to use multiple cores on a single client
- sakex 3y agoI agree to an extent, but you have to at least be aware of the complexity of your algorithms (time and space) and understand the trade offs. If the trade offs change depending on compiler optimisations, then you'll have some difficult debugging on your hands.
- xmcqdpt2 3y agoThe Java Streams API does various functional maps and reductions and can do them in a multithreaded fashion, when asked. I don't think it makes sense to parallelize by default. Although Java is used to write all kinds of business applications, it's also used to write the platform those applications run on, like Netty for example. If I'm writing a thread pool implementation (which is eventually going to be used by "business applications"), I want to have control over concurrency. I don't want to accidentally introduce pauses in my users web apps just because I sorted an array in my library. One could argue that web servers shouldn't be written in Java at all but you can't really support JVM applications efficiently on a non-JVM backend. All the great instrumentation tools that are available on the JVM will have trouble inspecting your library code, memory use becomes more complicated because the GC no longer knows how much memory is truly allocated, and users can't put breakpoints in your code easily in their IDE.
- rightbyte 3y agoThe computer gets unusable for multitasking you swamp the CPU.
- mschuster91 3y ago> And what's the potential to go all the way and add OpenCL or CUDA implementations? Wouldn't make sense outside of environments like Apple's M-series SoCs or some gaming consoles that have unified memory between CPU and GPU. Normal Intel-based architectures would waste too much time shuffling data over PCIe.
- kllrnohj 3y agoNearly every consumer Intel CPU sold for the last 10 years has had unified memory between the CPU & GPU. Similarly nearly every Qualcomm, ARM, etc... SoC for the last 10+ years has had unified memory. This isn't a rare or new architecture. Apple didn't invent this or popularize this with the M-series SoCs. Now since you mention PCIe you're almost certainly only thinking of discreet GPUs. Those of course are not unified memory. But the vast majority of consumer CPUs also have an integrated GPU and that is often unified.
- mschuster91 3y agoThese integrated GPUs however often are barely worth calling them by that name, and completely forget about the crap Qualcomm and others ship.
- touisteur 3y agoI wish I could easily use the 2 TFLOPS Xe GPU of the TigerLake gear I have with something else than the whole opencl/oneAPI/dpc++ kitchensink. I wish Intel really made an effort on the programability of all their offload hardware, be it GPUs or Myriad-X stuff... Either open everything and support a community, or make the sustained long-term CUDA effort... Hopefully SYCL gets us there but I still feel TigerLake was a grossly missed opportunity...
- re-thc 3y agoThere are all sorts of intrinsic in the JVM via feature detection.
- janwas 3y agoAs to portability to other SIMD instruction sets: vqsort[0] is portable to >10 different instruction sets, and actually faster than this when running on AVX-512. Disclosure: I am the main author; happy to discuss. 0: https://github.com/google/highway/blob/master/hwy/contrib/sort/ https://github.com/google/highway/blob/master/hwy/contrib/so...