Dear all, Mid 2018 there was a discussion on the mailing list (subject 'Cuda supporting toolchains') on CUDA-supporting toolchains (gcccuda, fosscuda, intelcuda) vs using CUDA as a 'normal' dependency (and adding its version as a suffix).
Advantage of a CUDA based toolchain is - at least in the case of fosscuda - an MPI built with CUDA support. One disadvantage in using CUDA-based toolchains is that if a high-level package requires e.g. fosscuda, we often need to create easyconfigs for a lot of the deps (because they only exist with foss or intel), because the foss toolchain is not a subtoolchain of fosscuda. Sure, we should probably push the community to not use 'higher' toolchains than needed for the package (i.e. don't use foss for non-mpi software), but in practice this still happens quite often. Another disadvantage is that we may want to update CUDA versions independently from toolchains (namely: more often) because of the relatively fast development. At the time of the previous discussion, there did not really seem to be consensus: some people preferred the CUDA-supporting toolchains (in conjunction with a policy to build things with the lowest possible toolchains, to maximize sharing deps with non-CUDA toolchains). Others seemed to favour the CUDA-as-dep approach for its flexibility (us at SURFsara included). However, if I check the repo for foss-2018b and fosscuda-2018b based EasyConfigs, I find only 3 EasyConfigs that use foss + CUDA-as-dep. On the other hand, there are 93 EasyConfigs for fosscuda. Have we as a community converged to CUDA-toolchains as a solution? And does that mean we will also keep pushing for EasyConfigs to be created at the lowest possible toolchains? What are the opinions/practices in other centers? Regards, Caspar van Leeuwen
