Standard software environments/fr: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(Created page with "===Amélioration de la performance=== Les binaires générés avec le compilateur Intel supportent automatiquement les jeux d’instructions AVX2 et AVX512. Techniquement, ce...")
(Created page with "Certains paquets logiciels installés auparavant avec GCC ou Intel se trouvent maintenant à un niveau plus bas de la hiérarchie, ce qui fait que le même module est visible...")
Line 34: Line 34:
Les binaires générés avec le compilateur Intel supportent automatiquement les jeux d’instructions AVX2 et AVX512. Techniquement, ce sont des binaires multi-architecture, aussi appelés [https://en.wikipedia.org/wiki/Fat_binary fat binaries]. Ceci signifie que quand vous utilisez une grappe comme Cedar ou Graham qui ont connu plusieurs générations de processeurs, vous n’avez plus besoin de charger manuellement un des modules <tt>arch</tt> si vous utilisez des paquets logiciels générés avec le compilateur Intel.  
Les binaires générés avec le compilateur Intel supportent automatiquement les jeux d’instructions AVX2 et AVX512. Techniquement, ce sont des binaires multi-architecture, aussi appelés [https://en.wikipedia.org/wiki/Fat_binary fat binaries]. Ceci signifie que quand vous utilisez une grappe comme Cedar ou Graham qui ont connu plusieurs générations de processeurs, vous n’avez plus besoin de charger manuellement un des modules <tt>arch</tt> si vous utilisez des paquets logiciels générés avec le compilateur Intel.  


Many software packages which were previously installed either with GCC or with Intel are now installed at a lower level of the software hierarchy, which makes the same module visible, irrespective of which compiler is loaded.  For example, this is the case for many bioinformatics software packages as well as the [[R]] modules, which previously required loading the <code>gcc</code> module. This could be done because we introduced optimizations specific to CPU architectures at a level of the software hierarchy lower than the compiler level.  
Certains paquets logiciels installés auparavant avec GCC ou Intel se trouvent maintenant à un niveau plus bas de la hiérarchie, ce qui fait que le même module est visible peu importe le compilateur qui est chargé; c’est le cas par exemple pour les modules [R/fr|R] et pour plusieurs paquets en bio-informatique pour lesquels le module <code>gcc</code> devait auparavant être chargé. Ceci a été rendu possible pas des optimisations spécifiques aux architectures CPU que nous avons effectuées sous le niveau du compilateur.  


We also installed a more recent version of the [https://en.wikipedia.org/wiki/GNU_C_Library GNU C Library], which introduces optimizations in some mathematical functions. This has increased the requirement on the version of the Linux Kernel (see below).  
We also installed a more recent version of the [https://en.wikipedia.org/wiki/GNU_C_Library GNU C Library], which introduces optimizations in some mathematical functions. This has increased the requirement on the version of the Linux Kernel (see below).  

Revision as of 19:33, 16 November 2020

Other languages:


Description

Nos environnements logiciels sont rendus disponibles par un ensemble de modules qui vous permettent d'alterner entre différentes versions d'un paquet logiciel. Ces modules sont organisés selon une structure en arbre dont le tronc est composé des mêmes utilitaires que ceux offerts par les environnements Linux. Les branches principales de ce tronc sont les versions des compilateurs auxquelles sont rattachées des sous-branches pour chaque version de MPI ou CUDA.

Un environnement logiciel standard est composé d’une combinaison particulière de modules de compilation et de modules MPI groupés dans un module appelé StdEnv. Ces environnements sont communément utilisés par notre équipe technique pour construire d’autres logiciels.

En date d’octobre 2020, les trois versions des environnements standards étaient 2016.4, 2018.3, et 2020 avec chaque version comportant des améliorations importantes.

Nous décrivons ici les différences entre les versions et expliquons pourquoi il est préférable d’installer la plus récente.

Les plus récentes versions des paquets logiciels sont habituellement installées dans le plus récent environnement logiciel.

StdEnv/2016.4

Cette première version de notre environnement logiciel a été installée en 2016 avec la mise en service des grappes [Cedar/fr|Cedar] et [Graham/fr|Graham]. Les compilateurs par défaut sont GCC 5.4.0 et Intel 2016.4. L’implémentation MPI par défaut est Open MPI 2.1.1. La plupart des logiciels compilés dans cet environnement ne supportent pas les instructions AVX512, contrairement aux processeurs Skylake de Béluga, [Niagara/fr|Niagara] et aux récents ajouts à Cedar et Graham.

Activez cet environnement avec la commande

Question.png
[name@server ~]$ module load StdEnv/2016.4

StdEnv/2018.3

Cette deuxième version de notre environnement logiciel a été installée en 2018, avec la mise en service de la grappe Béluga, peu après le déploiement de [Niagara/fr|Niagara]. Les compilateurs par défaut sont passés à GCC 7.3.0 et Intel 2018.3. L’implémentation MPI par défaut est passée à Open MPI 3.1.2. Il s’agit de la première version à offrir le support des instructions AVX512.

Activez cet environnement avec la commande

Question.png
[name@server ~]$ module load StdEnv/2018.3

StdEnv/2020

Cette plus récente version de notre environnement logiciel est celle qui a connu le plus de modifications. Les compilateurs par défaut sont passés à GCC 9.3.0 et Intel 2020.1. MPI par défaut est passée à Open MPI 4.0.3. Beaucoup des changements apportés ont résulté en une amélioration de la performance.

Activez cet environnement avec la commande

Question.png
[name@server ~]$ module load StdEnv/2020

Amélioration de la performance

Les binaires générés avec le compilateur Intel supportent automatiquement les jeux d’instructions AVX2 et AVX512. Techniquement, ce sont des binaires multi-architecture, aussi appelés fat binaries. Ceci signifie que quand vous utilisez une grappe comme Cedar ou Graham qui ont connu plusieurs générations de processeurs, vous n’avez plus besoin de charger manuellement un des modules arch si vous utilisez des paquets logiciels générés avec le compilateur Intel.

Certains paquets logiciels installés auparavant avec GCC ou Intel se trouvent maintenant à un niveau plus bas de la hiérarchie, ce qui fait que le même module est visible peu importe le compilateur qui est chargé; c’est le cas par exemple pour les modules [R/fr|R] et pour plusieurs paquets en bio-informatique pour lesquels le module gcc devait auparavant être chargé. Ceci a été rendu possible pas des optimisations spécifiques aux architectures CPU que nous avons effectuées sous le niveau du compilateur.

We also installed a more recent version of the GNU C Library, which introduces optimizations in some mathematical functions. This has increased the requirement on the version of the Linux Kernel (see below).

Change in the compatibility layer

Another enhancement for the 2020 release was a change in tools for our compatibility layer. The compatibility layer is between the operating system and all other software packages. This layer is designed to ensure that compilers and scientific applications will work whether they run on CentOS, Ubuntu, or Fedora. For the 2016.4 and 2018.3 versions, we used the Nix package manager, while for the 2020 version, we used Gentoo Prefix.

Change in kernel requirement

Versions 2016.4 and 2018.3 required a Linux kernel version 2.6.32 or more recent. This supported CentOS versions starting at CentOS 6. With the 2020 version, we require a Linux kernel 3.10 or better. This means it no longer supports CentOS 6, but requires CentOS 7 instead. Other distributions usually have kernels which are much more recent, so you probably don't need to change your distribution if you are using this standard environment on something other than CentOS.

How can I change which version of StdEnv is my default?

Our clusters use different versions of StdEnv as their default version. As of August 2020, Cedar and Graham use StdEnv/2016.4, while Béluga uses StdEnv/2018.3. Niagara also defaults to StdEnv/2018.3 if you module load CCEnv StdEnv. In the future, we will probably switch all of them to use StdEnv/2020. However, users can specify their own default by running the following command (example provided for the 2020 version)

Question.png
[name@server ~]$ echo "module-version StdEnv/2020 default" >> $HOME/.modulerc

Do I need to reinstall/recompile my code if the StdEnv version changes?

Yes. If you compile your own code, or install R or Python packages, you should recompile or reinstall the packages you need using the newest version of the standard environment.