Panama Support about jocl HOT 3 OPEN

IIRC, there had been a bit of hassle for "getting JExtract running" in the first place, but only due to the usual suspects (linux / vs. windows \ path separators and such) - in general, I think it worked relatively smoothly.

And I'm at least aware that people already tried to use JExtract for OpenCL (quick searches bring things like https://mail.openjdk.org/pipermail/panama-dev/2020-January/007280.html , but I think that there also have been more detailed discussions). But I have not tried it out for myself. I could imagine that OpenCL might cause fewer headaches than CUDA. For example

• It does not mess together 10 libraries (like CUDA with CUBLAS, CUFFT, CUSPARSE etc)
• It has much less "legacy" aspects (nothing like CUBLAS vs. CUBLAS_v2 and such
  (I mean, CUDA is version 12.4, and OpenCL is version 3.0...).
• It has a much more clear distinction between "host- and GPU memory" - there is cl_mem, whereas CUDA is throwing around some void* pointers where you never know what they are pointing to....

since it might require a higher level binding API like JOCL to make it user friendly!

I wouldn't call JOCL 'high-level'. It is still a 1:1 mapping of OpenCL. But of course, there are some design decisions in that already. I think that one very reasonable approach would be to generate these low-level 1:1 bindings with JExtract (and it does not matter whether they are "ugly" or "hard to use"), and then build a proper, object-oriented abstraction on top of that.

In fact, I think that OpenCL already does have a very "object-oriented" structure - but this structure is hidden under the necessity to create a plain, raw C-API. For example, looking at something like the JOCLReduction sample, there's a lot of boilerplate code and low-level API access. But eventually, this could be implemented in Java with something that could be really, really close to something that could look like pseudocode:

CommandQueue queue = Magic.getPlatform().getContext().createQueue();
Kernel kernel = Magic.createKernel(sourceCode);
float inputData[] = ...;
float outputData[] = ...;

Mem inputMem= queue.copyToBuffer(inputData);
Mem outputMem= queue.createBuffer(outputData.length);
queue.launch(kernel, inputMem, outputMem);
queue.readBuffer(outputMem, ouputData);

I once started drafting such an OO-layer. But the design decisions that would have to go into such an OO layer would require a lot of time for planning, implementation, and testing. And eventually, the effort for maintaining many libraries may be prohibitively large. I've been maintaining JCuda and JOCL for 15 years. And ... it may have been useful for others. But if I hadn't done this, I'd be in the exact same place as I am now...

from jocl.

I did actually try out JExtract 5 years ago: https://mail.openjdk.org/pipermail/panama-dev/2019-February/004443.html

But beyond that, I have not been able to follow the developments of Panama recently (or rather: for quite a while now). I think that trying to "upgrade" JOCL or JCuda to use the new functionalities could be difficult. It would almost certainly be a "breaking change", on many levels. (E.g. the Pointer class that is so central in both projects will probably no longer exist afterwards).

More generally, it's unlikely that I'll be able to allocate the time that would be necessary to investigate Panama, plan any implementation, and actually implement and maintain the projects based on the new infrastructure.

from jocl.

Thanks for the reply.

Great discussion with the panama team. Seems the API has changed considerable since then, like pointers are now MemorySegments with address long getter and other helpful native memory java functions, and also fewer classes now in one single package.

As I finished writing the original posts, I tested JExtract many times, with difficulty until I realised I need to install visual studio C++ tools to get the stdlib.h (Microsoft is absurd for this), and then succeeded in generating OpenCL bindings. I haven't tested the generated code, but it seems it has a lot of details which could be challenging to grasp without prior knowledge of FFM API and C. I might look at it one day in detail, since it might require a higher level binding API like JOCL to make it user friendly!

Anyway, I understand. Maintaining a library is not an easy task, furthermore, changing the design to accommodate new APIs is another stress level that requires time and resources.

from jocl.