Few questions about TornadoVM

[DamagedOne]

Hi!

I am trying to use TornadoVM for Thomas algorithm and have a few questions

1. I am not sure on how to fine tune Tornado execution e.g. using methods resetDevice() and freeDeviceMemory(). What are recommendations on their usage? Should they be used upon each execution?

2. Is there a way to use TornadoVM with 8 or 11 versions of java?

3. I have encountered very strange behavior when using backward iteration. In some cases backward iteration is ignored by TornadoVM. Here is the example code (I use TornadoVM 1.0.3, and graalvm-jdk-21.0.1+12.1):

public static int SIZE = 62;

public static void main(String... args) {
	Matrix2DDouble A = new Matrix2DDouble(new double[100][1]);
	run(A, SIZE);
	StringBuffer sb = new StringBuffer();
	for (int i = 0; i < A.size(); i++) {
		sb.append(A.get(i, 0));
		sb.append("\t");
	}
	System.out.println(sb.toString());
}

private static void execute(Matrix2DDouble A, int size) {
	for (int i = size; i >= 0; i--) {
		A.set(i, 0, 4);
	}
}

public static TornadoExecutionResult run(Matrix2DDouble A, final int size) {

	TaskGraph taskGraph = new TaskGraph("s1").transferToDevice(DataTransferMode.EVERY_EXECUTION, A)
			.task("t0", Test3::execute, A, size).transferToHost(DataTransferMode.EVERY_EXECUTION, A);
	ImmutableTaskGraph immutableTaskGraph = taskGraph.snapshot();
	TornadoExecutionPlan executionPlan = new TornadoExecutionPlan(immutableTaskGraph);
	return executionPlan.execute();
}

Printed result would be 
4.0	4.0	4.0 ...
However if I change SIZE to 63 (or higher), then result would be
0.0	0.0	0.0 ...

Here is the device I am using:
  Tornado device=1:0
        PTX -- PTX -- NVIDIA GeForce RTX 3050 Ti Laptop GPU
                Global Memory Size: 4,0 GB
                Local Memory Size: 48,0 KB
                Workgroup Dimensions: 3
                Total Number of Block Threads: [2147483647, 65535, 65535]
                Max WorkGroup Configuration: [1024, 1024, 64]
                Device OpenCL C version: N/A


Best regards,
Ilya

[jjfumero]

Hi Ilya,
thanks for the report. My answers below:

1. I am not sure on how to fine tune Tornado execution e.g. using methods resetDevice() and freeDeviceMemory(). What are recommendations on their usage? Should they be used upon each execution?

• The resetDevice cleans all code cache, events, and other internal objects that are attached to the device.
• The freeDeviceMemory mark all buffers associated to an execution plan as free, so other execution plans can take those buffers if needed.

We noticed these two calls are a bit confusing, so we are actually improving them.

2. Is there a way to use TornadoVM with 8 or 11 versions of java?

No. TornadoVM supports JDK 21 and JDK22. The reason is that it uses the latest version of the Panama Memory API, and the Graal JIT compiler, which needs to correlate with a specific version of JVMCI.

3. I have encountered very strange behavior when using backward iteration. In some cases backward iteration is ignored by TornadoVM.

It might be a bug in one of our compilation phases. Let me analyse this. If you annotate the loop with @Parallel, do you also get incorrect results?

[DamagedOne]

Hi! Thank you for you quick reply and answers.

If I annotate backwards loop with @parallel I get following error (with simple loop @parallel works fine):

WARNING: Code Bailout to Java sequential. Use --debug to see the reason�[0m
Exception in thread "main" uk.ac.manchester.tornado.api.exceptions.TornadoBailoutRuntimeException: �[31mUnable to build sketch for method: execute(�[31mFailed to parallelize because of non-constant loop strides.
Sequential code will run on the device!�[0m)�[0m
at [email protected]/uk.ac.manchester.tornado.runtime.sketcher.TornadoSketcher.buildSketch(TornadoSketcher.java:190)
at [email protected]/uk.ac.manchester.tornado.runtime.sketcher.TornadoSketcher$TornadoSketcherCallable.call(TornadoSketcher.java:262)
at [email protected]/uk.ac.manchester.tornado.runtime.sketcher.TornadoSketcher$TornadoSketcherCallable.call(TornadoSketcher.java:252)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)

[jjfumero]

Thank you. This is a bug. We will work on it.