Integer in kernelContext.globalIds causes generation of Unbox/PiNodes

[andrii0lomakin]

Hi.
Because KernelContext uses Integers for KernelContext variables.
Code like that var i = kernelContext.globalIdx; causes cryptic compilation errors, which, in the core, are caused by the fact that TornadoVM generates not alive PiNode's that can not be replaced during compiler optimizations.

Is it possible instead to use final int fields to avoid such confusion?
What is the root cause of this decision to use wrappers instead?

[jjfumero]

Hi @andrii0lomakin . Can you provide a test case that breaks?

As far as I remember, we decided to use the wrapper types due to optmizations in the Graal Compiler. If it is a primitive final, Graal will provide directly the constant value (which makes sense). In TornadoVM, to prevent this, we have at least two options:

1. Use functions (e.g.., kernelContext.globalIDx()`)
2. Use a wrapper and keep the field.

We preferred the style of fields to access the thread-ids. However, we are open to suggestions.

[andrii0lomakin]

@jjfumero this simple kernel fails to compile:

 static void addVectorToVectorKernel(FloatArray first, int firstOffset, FloatArray second, int secondOffset,
                                        FloatArray result, int resultOffset, KernelContext kernelContext) {

       var i = kernelContext.globalIdx;
        result.set(resultOffset + i, first.get(firstOffset + i) + second.get(secondOffset + i));
    }

[andrii0lomakin]

I understand that this test failure can be treated as "developers fault" but IMHO API usability is an important factor of the popularity of tools, so probably would be worth considering to change this API.

[andrii0lomakin]

Another possible motivation for changing this API by using functions would be the ability to emulate the running kernels using Kernel API on the CPU. Imho the concept of barriers does not fit well in the JVM concurrency model. Still, modern support of virtual threads in JDK 21 will allow the implementation of barriers in the case of many workers and a limited amount of threads(read cores) for debugging purposes.

I already have a sketch of such emulation based on TornadoVM API, but the usage of Integer instead of methods makes it impossible, it seems like reflection API conflicts with the TornadoVM compiler, and I can not write tests that use both GPU and CPU scheduled kernels.

Usage of CPU scheduled kernels will greatly simplify debugging, of course, in case of usage of kernel API.

[andrii0lomakin]

By the comment above, I mean that my ideal development flow is:

1. Write kernel using TorandoVM API.
2. Test it on the CPU by writing unit tests. That will allow us to extensively debug kernel if needed.
3. Repeat the same tests on GPU, preferably using the same code, and replace only interface implementation (that can be achieved by usage of parametrized tests in JUnit 5).

I understand that we can use kernels made using annotations, but such tests do not emulate the concurrency part, and though it can only be limited imitation on CPU (it obviously does not distinguish local and global barriers), it is still usable.

Also, I prefer Kernel API for production use cases.