Add vectorized algorithm for forest mean/variance in aarch64/riscv

[david-cortes-intel]

Vectorization for calculations of mean/variance in random forests was recently added with this PR:
#3362

It doesn't quite work like the rest of the vectorized codepaths, as it involves non-trivial reductions and keeping of aggregates that require knowing the size of the simd lanes apriori:

oneDAL/cpp/daal/src/algorithms/dtrees/forest/regression/df_regression_train_dense_default_impl.i

Line 180 in 97f37b5

#if (__CPUID__(DAAL_CPU) == __avx512__)

I guess that perhaps other architectures might have instructions that could be used to vectorize those operations, but I am not familiar with them so I made the PR to only use vectorized paths on x86, with different parameters for avx2 and avx512 according to what they can do.

Aim of this issue is to add vectorization for other architectures that might support it, with conditional ifdefs to make them use the right constants.

CC @rakshithgb-fujitsu @theComputeKid @keeranroth

[theComputeKid]

Does the software architecture allow us to have vector length agnostic (i.e. SVE) instructions, or is it inherently vector length specific?

[david-cortes-intel]

Does the software architecture allow us to have vector length agnostic (i.e. SVE) instructions, or is it inherently vector length specific?

It needs to be for a specific vector length.

[theComputeKid]

I thought so. Is this a hard requirement as per the design spec of the library? I would imagine Fujitsu would contribute SVE-256 vector length specific code, and this would set a precedent where we would not utilize the scalability of SVE for other/future machines and require code duplication. Having said that, VLS SVE-256 is reasonable since Fujitsu contributes more actively so it makes sense to accommodate them.

[david-cortes-intel]

I thought so. Is this a hard requirement as per the design spec of the library? I would imagine Fujitsu would contribute SVE-256 vector length specific code, and this would set a precedent where we would not utilize the scalability of SVE for other/future machines and require code duplication. Having said that, VLS SVE-256 is reasonable since Fujitsu contributes more actively so it makes sense to accommodate them.

The algorithm works in such a way that it keeps parallel streams of aggregations which are then merged at the end. In order for this to work, it needs to know how many streams to keep. It's not a design principle of the library, but just the way the mathematics work out for these computations.

[jondea]

Thanks for the heads up @david-cortes-intel. Would you be open to having multiple vector length specific SVE versions? I.e. it wouldn't cause too much code or binary size bloat?

[david-cortes-intel]

Thanks for the heads up @david-cortes-intel. Would you be open to having multiple vector length specific SVE versions? I.e. it wouldn't cause too much code or binary size bloat?

Sure, that shouldn't be a problem if you can do it in such a way that the x86 versions wouldn't start producing additional copies. Which should be easy with ifdefs and templated configurations.