Basic parfor-loop support in DaphneDSL #515

[yesoer]

This pullrequests targets Basic parfor-loop support in DaphneDSL #515.
It can be used instead of regular for-loops to parallelize iterations.
There are some limitations though which are listed below.

Note : By default parallelization is disabled. Use the build flag --enable-parallel-parfor to enable it. This is to keep automatic testing predictable.

Performance Test

We used the following daphne script for testing performance :

vals = rand(1, 250000, 250.0, 500.0, 1.0, -1);

parfor(i in 0:249999) {
    vals[0, i] = vals[0, i] * 2;
}

Without parallelization it ran in 24.192882 seconds.
With parallelization it ran in 8.019115 seconds.
To make sure we only time the actual execution, we implemented it in the kernel.
Whether you want to include timing can be controlled by a build flag, just like the parallelization itself. Namely --enable-time-parfor.
For an even more reproducible setup you might want to set the OMP_NUM_THREADS env variable e.g. export OMP_NUM_THREADS=2. In our setup this resulted in 12.233227 seconds, which clearly shows good usage of the two threads compared to the single thread version that took ~24 seconds.

Dependencies

For parallization we used omp in the kernel. Omp is bundled with gcc (13) and the corresponding cmake module basically just sets the flag -fopenmp.

Limitations

We support loops that go from some value to some other value. Optionally one may provide a step. By default the step is assumed to be 1. Any more advanced for loop headers are not supported in this PR.

We do support if statements i.e. scf.if within the parfor body but not for loops.

This pullrequest does not provide dependency analysis to check whether the iterations are independent of each other and can actually be parallelized. The following options were considered :

• DataFlow does not provide the required analysis tools for this task.

• LLVM and Affine dialects cannot be used, as they lack any understanding of the semantics of Daphne kernel calls.

• To implement the necessary analysis by hand, we first need alias analysis — identifying which SSA values or operations refer to the same memory. Once that’s in place, we can enrich the IR with read/write flags using DataFlow. This, however, requires defining aliasing behavior for all Daphne operations.

As of now we do not support function calls nested in parfor loop bodies. Also the usage of parfor inside of functions is not possible at the moment. That is because of the missing type inference of ParForOp.

We support multiple return values but not of different types.
The supported types are DenseMatrix double, DenseMatrix float and DenseMatrix int64_t.
Related to this is issue #397.