oneMath links Intel oneMKL statically on Windows

[Rbiessy]

Summary

The CMake logics set MKL_LINK to static when building for Windows:

oneMath/CMakeLists.txt

Lines 231 to 235 in c3c85db

	if(BUILD_SHARED_LIBS AND NOT WIN32)
	set(MKL_LINK dynamic)
	else()
	set(MKL_LINK static)
	endif()

This creates a large library on Windows of around 100MB, whereas on Linux with dynamic linking it is around 3MB for the blas domain for instance. This is not practical to integrate in other applications.
I am wondering if someone from @uxlfoundation/onemath-arch-write know why this is the case? Would there be any risk to switch to linking Intel oneMKL dynamically today?

Version

It looks like this was introduced in c3c85db9
Pinging @mkrainiuk in case you have more context.

Environment

The issue happens on Windows with the Intel oneMKL backends.

[mkrainiuk]

I had to comment this line...

I guess there were at least 2 issues with using oneMKL SYCL DLLs:

1. oneMKL SYCL DLLs have explicit dependency on TBB threading (we still need to find a way to make the threading dependency more flexible)
2. The oneMath binaries are much smaller with dynamic link, that's true, but the final application requires oneMKL, and the full sized oneMKL DLLs most likely will take more space than oneMath with oneMKL linked statically.

I think we need to fix the first limitation before we can consider switching to dynamic link on Windows, and maybe the second problem is not an issue anymore.

[Rbiessy]

Thanks Maria.

1. So does that mean that when linking statically TBB is not added? I've not looked into that in detail but I noticed that linking against the CMake target MKL::MKL_SYCL::BLAS does add a TBB CMake target. I don't get how this workaround solves the issue.
2. I agree but I believe that is true for all libraries that provide shared object and static libraries given that the linker can strip unused symbols with static libraries. I think it should be up to the user of oneMath to use static libraries if the total size is an issue.

[mkrainiuk]

Hi @Rbiessy,

1. So does that mean that when linking statically TBB is not added? I've not looked into that in detail but I noticed that linking against the CMake target MKL::MKL_SYCL::BLAS does add a TBB CMake target. I don't get how this workaround solves the issue.

In case of static link user can link with oneMKL OpenMP threading instead of TBB for parallelization on CPU, or use sequential oneMKL. Since oneMKL SYCL DLL has hardcoded dependency on TBB threading, it's not possible in case of dynamic link at this moment.

2. I agree but I believe that is true for all libraries that provide shared object and static libraries given that the linker can strip unused symbols with static libraries. I think it should be up to the user of oneMath to use static libraries if the total size is an issue.

Right, however, right now user can only select type of oneMath libraries: static or dynamic, there is no specific option to define how oneMath dependencies should be linked. But it does make sense to align the link type anyway.

[Rbiessy]

In case of static link user can link with oneMKL OpenMP threading instead of TBB for parallelization on CPU, or use sequential oneMKL. Since oneMKL SYCL DLL has hardcoded dependency on TBB threading, it's not possible in case of dynamic link at this moment.

Oh I see, that's good to know, thanks. I suppose I'll keep this issue open until this limitation can be fixed.

Right, however, right now user can only select type of oneMath libraries: static or dynamic, there is no specific option to define how oneMath dependencies should be linked. But it does make sense to align the link type anyway.

Yeah I don't think it is very common to provide options for in-between linking configurations.