rodinia/gaussian sycl and ndpx implementation

[roxx30198]

Added the sycl and numba-dpex implementation for gaussian elimination benchmark for rodinia.
Runtime for 100x100 matrix with fp64 on cpu:
sycl:
max execution times: 12.190916ms (12190916 ns)
min execution times: 6.433963ms (6433963 ns)
median execution times: 7.595746ms (7595746 ns)
repeats: 10
numba_dpex_k:
max execution times: 3.994273296s (3994273296 ns)
min execution times: 2.814416425s (2814416425 ns)
median execution times: 3.585554875s (3585554875 ns)
repeats: 10

[adarshyoga]

Overall looks in good shape!

[adarshyoga]

median execution times: 7.595746ms (7595746 ns)
repeats: 10
numba_dpex_k:
max execution times: 3.994273296s (3994273296 ns)
min execution times: 2.814416425s (2814416425 ns)
median execution times: 3.585554875s (3585554875 ns)

These numbers look scary. 500X slowdown in numba_dpex over sycl.
I think we should carefully review the range selection in both implementations. I suspect the parallelism might be different.
I see that sycl impl is using range multiplication. Since range arithmetic is not yet supported in numba-dpex, you are manually computing the range in the numba-dpex impl. We need to make sure that there is not mismatch in the range used in the two impls.

[ZzEeKkAa]

@roxx30198 please split commits so one commit is responsible for infrastructure changes and another one is for the gaussian implementation

And let's set the input the way dpex implementation does not exceed 1s for S input.

@adarshyoga does input sizes for M and L sounds reasonable for you?

[adarshyoga]

@adarshyoga does input sizes for M and L sounds reasonable for you?

We would need to experiment with this workload to arrive at an appropriate M and L. I think we can merge this PR with the current values of M and L. We can change them as we do deeper analysis into this workload and Rodinia, in general.

[ZzEeKkAa]

LGTM! Thank you!