Hi, I would personally prefer the non-CUDA toolchain to prevent to have a lot of duplicate modules that do not really use CUDA themselves, but are just needed as dependencies for a module that uses CUDA.
An example would be the Tensorflow Python modules. If they are in a separate toolchain, then a lot of other Python packages need also to be in the fosscuda toolchain eventhough they do not in any way use CUDA. They typically live in the foss/intel toolchains rather than in GCC-core, not because they use MPI but because they use blas or other math libraries that are in the MKL on the Intel toolchain - or depend on such packages, SciPy-bundle being the main such dependency. Admittedly, moving Python itself down from foss/intel to GCC-core has significantly reduced the issue. But my opinion should not count for much. My GPU work is done on a cluster that unfortunately does not use EasyBuild. Best regards Jakob -- Jakob Schiøtz, professor, Ph.D. Department of Physics Technical University of Denmark DK-2800 Kongens Lyngby, Denmark http://www.fysik.dtu.dk/~schiotz/ > On 27 Nov 2019, at 12.07, Caspar van Leeuwen <[email protected]> > wrote: > > 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 > >
