Maria Kraynyuk

We already search for required library in our cmake/FindCBLAS and fail if it's not found https://github.com/oneapi-src/oneMKL/blob/722f6c51b528a2bc09bf549b1097f7d8fdc37826/cmake/FindCBLAS.cmake#L25 So we really can improve this function implementation with new variable: https://github.com/oneapi-src/oneMKL/blob/f43e4e5943d0ef3a85ff3331d567eadb09c8fe71/tests/unit_tests/blas/include/reference_blas_templates.hpp#L49 But I...

Sorry for the super long delay as I worked on another project for last two months. I think as more global solution would be using runtime loading mechanism for reference...

Summon people participated in the discussions mentioned in the Related Work section: Julia @staticfloat @ViralBShah FlexiBLAS @grisuthedragon BLIS @devinamatthews OpenBLAS @xianyi

Hi @WeiqunZhang, yes, we plan to provide device API for selected oneMKL domains including random number generators. We did some prototyping, and currently discussing API. If you have any ideas...

summon @marius-cornea

Hi @ManjulaChalla! It looks like the profiling tool limitation. As I see on different forums users recommend adding a symbolic link in your project's root directory to the shared libraries...

Thanks for the great feedback! Hi @grisuthedragon > * the _64 is built although BUILD_INDEX64=OFF `BUILD_INDEX64` and `BUILD_INDEX64_EXT_API` are completely independent options: * The main idea of `BUILD_INDEX64_EXT_API` option is...

> From my opinion, as mentioned before, we need three build variants. The standard build, without any special options, suffixes or similar one, that leads to the LP64 variant, as...

> That's something nobody can guarantee and it is up to the programmer. Right, but with the suffixes we can give a chance to programmers to ensure the correct ILP64...

> The case where both symbols in one Library cause problems is easily constructed... On the one hand Julia, Python load it via dlopen and flags like RTLD_GLOBAL and RTLD_NOW...