Docker containers for oneMATH

[vmalia]

Motivation

• The oneMATH project can be built from source, which requires setting up the device drivers, compiler and runtime, and the backend library on the user-side manually.
• Each of these products have their own install instructions on different web locations and may need other dependencies - for example - building the LLVM compiler with CUDA support requires building LLVM from source.
• All oneMATH backends are available as docker images on dockerhub as official images from the vendors.

Design Overview

• From oneMATH usability perspective, the most important decision is backend selection.
• Depending on the backend selected, there may be one or more compilers that support that backend.
• If we want to enable a separate Docker container for each supported compiler+backend configuration, it would look something like this:

   - Dockerfile.base          # Base container
   - Dockerfile.onemkl.intel  # Intel compiler + oneMKL backend
   - Dockerfile.onemkl.llvm   # LLVM compiler + oneMKL backend
   - Dockerfile.onemkl.acpp   # AdaptiveCPP compiler + oneMKL backend
   - Dockerfile.cuda.llvm     # LLVM compiler + CUDA backend
   - ...

• Alternatively, we can have only backend specific Dockerfiles and the compiler selection could be done through docker environment variables when starting the container.
• Optionally, docker compose can also be implemented to provide pre-configured docker services that can be run on the fly or deployed in automation with minimal system or docker modifications.

Example: oneMATH/Dockerfile.cuda at docker_backends · vmalia/oneMATH

Other Advantages

• Docker can be configured on the user/dev/test machine to use available hardware like GPU and manually allocate CPU cores, providing more control at the application-level for oneMATH developers and job step parallelism in automation.
• Docker files will always provide a deterministic build and test environment due to use of specific versions for each dependency as supported by oneMATH, without needing to manually ensure that.
• If used in CI automation, docker can make the build and test process much more streamlined. Currently, CIs are inside the Intel firewall on Intel owned hardware, so this will mostly affect Intel developers.

Considerations when making a decision

• Use cases: Consider if using docker will fulfill certain use-cases for oneMATH. The use-cases can be specific to you, your application or generic in nature.
• Maintenance: Docker files will need to be updated when a new oneMATH release is made, and tested on a regular basis, possible through CI.

Future Scope

• If we decide to enable docker support and everything works as expected, we can choose to publish images to dockerhub using official channels for intel (or UXL Foundation if there will be one eventually).

Timeline

• This poll will be available till end of March'25.
• The decision will be acted on in Q2'25.

[Rbiessy]

Overall I have no preference whether Docker containers are available or not. I do not think I would be using them in the short term at least.

I think providing pre-built packages of oneMath would be more useful to users and as such a higher priority. We have found this would help users enable oneMath in GROMACS or llama.cpp for instance. We discussed this suggestion in #467 for instance.