uxlfoundation/oneDAL

When using MKL as backend for math functions such as exponentials and square roots, calls over long arrays are parallelized over threads, but the reference implementations do not perform any parallelization - for instance here: oneDAL/cpp/daal/src/externals/service_math_ref.h Line 326 in 4ab08f2 static void vSqrt(SizeType n, const float * in, float * out) Some of those could be made faster with multiple threads, but it might require large refactorings of the library to ensure it would work correctly, given the places where they are defined and used, and in order to ensure that they do not cause nested parallelization when they are used inside TBB blocks.

From discussions in #3837 It appears OpenBLAS is being built in sequential mode (single-threaded) when used as math backend instead of MKL. For the most part, BLAS calls happen in parallel through TBB so single-threaded mode is desirable, but there are some calls outside of TBB blocks where better performance could be achieved with multi-threading within BLAS and LAPACK - for instance, for linear regression, the heaviest part of the computation which is calculating t(X)*X is parallelized though TBB, but the Cholesky factorization of it is just a call to LAPACK, where multi-threading would be beneficial for large inputs. Aim of this issue is to use the OpenMP variant of OpenBLAS when building oneDAL (note that OpenBLAS is compiled from source in most instances where it is used), in both the Make-based builds and Bazel-based ones. Note that this might not be as simple as passing a compile option as it would also bring a dependency on OpenMP, which would need to be dynamically-linked and

ref #3795 When building oneDAL with clang-cl on windows, neither the Makefile nor the bazel scripts pass flags -fopenmp-simd or -fopenmp for vectorization. Aim of this issue is to add such flags wherever appropriate when building on windows. I am not sure if these are passed with other non-Intel compilers on windows either, so it might be needed in other places too.

As a follow up from #3718 (comment) It appears it is currently not possible to use oneDAL on aarch64 machines lacking SVE instructions, and this is not just a matter of options in the build system, because file service_math_ref.h has functions that call SVE intrinsics directly without having any fallback. Aim of this issue is to create versions of those SVE-only functions that would work with only the NEON instruction sets on aarch64. This should be a prerequisite for #3175

Windows on ARM64 is becoming an increasingly important platform, but oneDAL does not currently provide official support for it. It would be beneficial to add Windows ARM64 as a supported platform by: Enabling native ARM64 builds. Adding CI coverage for Windows ARM64. Publishing ARM64 binaries/packages where applicable. Official support would allow downstream projects, such as scikit-learn-intelex, to provide native acceleration on Windows ARM devices without relying on x64 emulation.