Differences

This shows you the differences between two versions of the page.

--- commit:2015:08_12 [2015/08/12 11:00] – boman
+++ commit:2015:08_12 [2016/03/30 15:23] (current) – external edit 127.0.0.1
@@ Line 3: / Line 3: @@
 ===== Portage MinGW =====
-J'ai modifié le code pour pouvoir le compiler avec [[http://www.mingw.org/|MinGW]] (Minimalist GNU for Windows), c'est-à-dire le compilateur gcc (4.8.1) sous Windows. Ce compilateur se distingue de "gcc sous Cygwin" par le fait que c'est un vrai compilateur POUR Windows. Les bibliothèques utilisables sont donc similaires à celles du Visual Studio (on peut par exemple faire un ''#include <Windows.h>'' et appeler l'API Windows, contrairement à gcc sous Cygwin). MinGW crée des exécutables similaires à Visual Studio (''.exe'', ''.dll'') qui ne dépendent pas d'une couche d'émulation de type Cygwin.
+J'ai modifié le code pour pouvoir le compiler avec [[http://www.mingw.org/|MinGW]] (Minimalist GNU for Windows), c'est-à-dire le compilateur gcc (4.8.1) sous Windows. Ce compilateur se distingue de "gcc sous Cygwin" par le fait que c'est un vrai compilateur POUR Windows. Les bibliothèques utilisables sont donc similaires à celles du Visual Studio (avec ce compilateur, on peut par exemple faire un ''#include <Windows.h>'' et appeler directement l'API Windows, contrairement à gcc sous Cygwin). MinGW crée des exécutables similaires à Visual Studio (''.exe'', ''.dll'') qui ne dépendent pas d'une couche d'émulation de type Cygwin. On peut même s'amuser à mélanger l'output des 2 compilateurs; ce que je n'ai pas fait ici.
 __Quels sont les buts?__
-  * Obtenir un **exécutable 32 bits**: c'est important pour pouvoir fournir Metafor aux étudiants ou aux industriels qui possèdent des vieilles machines sous XP, Vista ou Win7-x86. Depuis que Metafor utilise des fonctionnalités du C++11, c'est devenu un problème puisque la compilation de Metafor requiert un compilateur relativement récent tel que Visual Studio 2012, qui est impossible à installer sous XP - Windows XP étant le plus vieux système auquel on est toujours confronté). On a donc un problème pour générer une version 32 bits qui tourne partout! (les exe's Visual Studio générés sous Windows7-x86 ne sont pas totalement compatibles avec Vista et XP).
+  * Obtenir un **exécutable 32 bits**: c'est important pour pouvoir fournir Metafor aux étudiants ou aux industriels qui possèdent des vieilles machines sous XP, Vista ou Win7-x86. Depuis que Metafor utilise des fonctionnalités du C++11, c'est devenu un réel problème puisque la compilation de Metafor requiert un compilateur relativement récent tel que Visual Studio 2012, qui est impossible à installer sous XP (Windows XP étant le plus vieux système auquel on est toujours confronté). On a donc un problème pour générer une version 32 bits qui tourne partout! (les exe's Visual Studio générés sous Windows7-x86 ne sont pas totalement compatibles avec Vista et XP). Précédemment, on s'en sortait en installant un vieux Intel Parallel Studio tombé du camion...
-  * Ca permet de compiler le code avec un **compilateur supplémentaire** (et donc de trouver des bugs et rendre le code plus générique). La maintenance à long terme ne devrait pas être trop difficile puisqu'il s'agit tout de même de gcc à la base.
+  * Ca permet de compiler le code avec un **compilateur supplémentaire** (et donc de trouver potentiellement de nouveaux bugs et rendre le code plus générique). La maintenance à long terme ne devrait pas être trop difficile puisqu'il s'agit tout de même de gcc qu'on utilise sous Linux, à la base.
   * MinGW étant **gratuit**, ça permet de fournir une version de développement de Metafor qui ne demande aucune licence payante telle que celle du Visual Studio (pour autant qu'il soit possible de compiler sans la bibliothèque MKL d'Intel, voir plus bas). Le but à long terme étant d'avoir une partie de Metafor qui serait rendue open source.
-Ci dessous, je liste les différents problèmes que j'ai dû résoudre pour ce portage.
+Ci-dessous, je liste les différents problèmes que j'ai dû résoudre pour ce portage.
 ===== Compilation des libs =====
@@ Line 18: / Line 18: @@
 Le compilateur est [[http://sourceforge.net/projects/mingw/|MinGW]]. J'ai installé cette version (et pas [[http://sourceforge.net/projects/mingw-w64/|celle-ci]] qui est plus récente et disponible en 64bits aussi) car elle possède un [[http://sourceforge.net/projects/mingw/files/Installer/|installeur]] très bien foutu qui ressemble à synaptic. Cette version est également fournie avec MSYS qui est un ensemble d'outils GNU compilés pour Windows qui permettent d'avoir éventuellement des Makefiles de type Unix.
-En effet, c'est un peu déroutant au début: avec MinGW, on peut utiliser soit des "MinGW Makefiles" ou des "MSYS Makefiles" (ce sont les 2 choix que propose CMake).
+C'est un peu déroutant au début: avec MinGW, on peut utiliser soit des "MinGW Makefiles" ou des "MSYS Makefiles" (ce sont les 2 choix que propose CMake).
-  * Les premiers ("MinGW Makefiles") sont indépendants de MSYS et utilisent les outils DOS (''copy'' par exemple). On utilise alors ''mingw32-make'' pour lancer la compilation à partir d'une console Windows (ou [[https://wiki.qt.io/Jom|jom]] pour compiler en parallèle - le ''-j'' n'est pas supporté).
+  * Les premiers ("MinGW Makefiles") sont indépendants de MSYS et utilisent les outils traditionnels du DOS (''copy'' par exemple). On utilise alors ''mingw32-make'' pour lancer la compilation à partir d'une console Windows (ou [[https://wiki.qt.io/Jom|jom]] pour compiler en parallèle - le ''-j'' n'est pas supporté).
-  * Les seconds ("MSYS Makefiles") utilisent les outils MSYS de type Unix (''cp'' au lieu de ''copy''). On utilise alors ''make'' (à partir d'une ligne de commande DOS et ''make'' se charge alors de lancer des subshells avec le ''sh.exe'' de MSYS). C'est intéressant pour les programmes Unix qui n'ont pas été portés sous Windows et mais qui ont tout de même un système de Makefiles qui fonctionne sous Unix.
+  * Les seconds ("MSYS Makefiles") utilisent uniquement les outils MSYS de type Unix (''cp'' au lieu de ''copy''). On utilise alors ''make'' (à partir d'une ligne de commande DOS et ''make'' se charge alors de lancer des subshells bash avec le ''sh.exe'' de MSYS). C'est intéressant pour les programmes Unix qui n'ont pas été portés sous Windows et mais qui ont tout de même un système de Makefiles qui fonctionne sous Unix.
-En pratique, il faut malheureusement jongler avec les 2 systèmes, du moins quand on veut compiler les libs. Une lib peut utiliser des "MinGW Makefiles" alors que la suivante utilisera plutôt des "MSYS Makefiles". Il faut donc que MinGW et MSYS soient tous les 2 dans le PATH... sauf que ''mingw32-make'' ne fonctionne pas si ''sh.exe'' de MSYS est dans le PATH. Au lieu de jongler avec des changements de PATH, j'ai renommé ''sh.exe'' en ''sh.exe_'' quand j'en avais pas besoin. Ca permet d'avoir accès aux programmes de MSYS tels que bison et flex tout en utilisant ''mingw32-make''.
+En pratique, il faut malheureusement jongler avec les 2 systèmes, du moins quand on veut compiler les libs. En effet, une lib peut utiliser des "MinGW Makefiles" alors que la suivante utilisera plutôt des "MSYS Makefiles". Il faut donc que MinGW et MSYS soient tous les 2 dans le PATH... sauf que ''mingw32-make'' ne fonctionne pas si ''sh.exe'' de MSYS est dans le PATH. Au lieu de jongler avec des changements de PATH, j'ai renommé ''sh.exe'' en ''sh.exe_'' quand j'en avais pas besoin. Ca permet d'avoir accès aux programmes de MSYS tels que bison et flex tout en utilisant ''mingw32-make''.
 Cette subtilité comprise, j'ai essayé de ne compiler que ce qui était vraiment nécessaire pour Metafor en partant de l'hypothèse que je ne vais pas me casser la tête à faire une version Debug, du moins pour le moment.
@@ Line 37: / Line 37: @@
   * bison/flex: installé via le synaptic de MSYS.
-Pour la batterie, il me manque triangle, tetgen et numpy. Mais comme je ne compte pas passer de batterie avec une version 32 bits, je ferai ça plus tard.
+Pour la batterie, il ne me manque que triangle, tetgen et numpy. Mais comme je ne compte pas passer de batterie avec cette version 32 bits, je ferai ça plus tard.
 Petite remarque: les fichiers ''.lib'' n'existent pas avec MinGW. Les libs statiques sont des ''.a'' et les DLLs sont des fichiers ''.dll'' qu'on peut référencer directement dans la commande de link (au lieu du traditionnel ''.lib'').
@@ Line 85: / Line 85: @@
 ====== Perfs? ======
-Quelles sont les perfs de cette nouvelle version?
+Quelles sont les perfs de cette nouvelle version? m'a demandé Luc.
-Voilà ce que ça donne sur le cas test du tube. Pour cette première série de tests, je compare "tube" en séquentiel avec le solveur skyline sur 3 machines:
+Voilà ce que ça donne sur le cas test du tube.
-  * win7-msvc-x64: une virtual box Windows 7 (x64) installée sur garfield. Metafor compilé avec le Visual Studio, comme d'habitude, les MKL.
+**Pour cette première série de tests**, je compare "tube" en séquentiel avec le solveur skyline sur 3 machines:
+  * win7-msvc-x64: une virtual box Windows 7 (x64) installée sur garfield. Metafor compilé avec le Visual Studio, comme d'habitude, et les MKL.
   * winxp-mingw32: une virtual box Windows XP (x86) installée sur garfield. Metafor compilé avec MinGW et OpenBLAS (cfr ci-dessus).
   * ubuntu-gcc-x64: l'OS de garfield. Ubuntu installé comme OS principal, SSD, bcp de RAM, etc. Metafor compilé avec gcc et MKL.
@@ Line 96: / Line 98: @@
 La version ubuntu est la plus rapide (67s), talonnée par la virtualbox win7-visual (71s) et loin derrière, on retrouve la nouvelle version 32 bits (102s). Petit détail amusant: le skyline est plus rapide dans la virtualbox win7 que sous ubuntu. Par contre toutes les autres routines sont plus efficaces sous ubuntu.
-En ce qui concerne la nouvelle version MinGW, le code est plus lent dans toutes les phases de résolution et principalement dans l'assemblage de la matrice de raideur (buildK). Les accès mémoire ne seraient donc pas terribles? Le test consomme pourtant uniquement quelques centaines de Mo (200Mo alloué et une virtual size totale de 600Mo). J'ai également vérifié qu'il n'y avait qu'un seul thread utilisé. Je n'ai pas l'impression que le système ne swappe pas lors du calcul. Est ce donc un problème de Win XP?
+En ce qui concerne la nouvelle version MinGW, le code est plus lent dans toutes les phases de résolution et principalement dans l'assemblage de la matrice de raideur (buildK). Les accès mémoire ne seraient donc pas terribles? Le test consomme pourtant uniquement quelques centaines de Mo (200Mo alloué et une virtual size totale de 600Mo). J'ai également vérifié qu'il n'y avait qu'un seul thread utilisé. Je n'ai pas l'impression que le système swappe lors du calcul. Est ce donc un problème de Win XP?
 Il faudra donc tester cette version sur un système récent (win7 x64 p expl). Il faudra également faire des tests de comparaison MKL/OpenBLAS sur la version win7-x64.
-Dans un second temps, je me suis demandé si le solveur MUMPS était utilisable avec MinGW puisqu'on n'a plus le DSS avec cette version de Metafor, tout en sachant bien que les perfs du code compilé ainsi sont globales mauvaises (du moins dans ma virtualbox XP). Je me suis alors rendu compte que l'utilisation du solveur MUMPS augmentait le temps CPU! (+5s!)
+**Dans un second temps**, je me suis demandé si le solveur MUMPS était utilisable avec MinGW puisqu'on n'a plus le DSS avec cette version de Metafor, tout en sachant bien que les perfs du code compilé ainsi sont globalement mauvaises (du moins dans ma virtualbox XP). Je me suis alors rendu compte que l'utilisation du solveur MUMPS augmentait le temps CPU! (+5s!)
 La série de tests suivante consiste à tester les différents solveurs sur la même machine. Par simplicité, j'ai choisi ma virtualbox win7-x64. Voilà ce que ça donne. C'est très instructif:
@@ Line 107: / Line 109: @@
 {{ :commit:2015:mingw-image2.png |}}
-Il y a visiblement un (gros) problème... On voit bien que la plupart des phases qui n'impliquent pas le solveur fournissent un temps CPU +/- identique (contact, Fint, Fext, etc), Les temps varient donc uniquement dans buildK (l'assemblage) et solveK (la résolution).
+Il y a visiblement un (gros) problème... On voit bien que la plupart des phases qui n'impliquent pas le solveur fournissent un temps CPU +/- identique (contact, Fint, Fext, etc), Les temps varient donc uniquement dans buildK (l'assemblage) et solveK (la résolution). Logique...
-Si on regarde la résolution, le DSS est incontestablement le plus rapide, mais MUMPS n'est pas si mauvais que ça (5% plus lent que DSS à peine!) et MUMPS est largement devant le skyline!
+Si on regarde la résolution (solve K), le DSS est incontestablement le plus rapide, mais MUMPS n'est pas si mauvais que ça (5% plus lent que DSS à peine!) et MUMPS est largement devant le skyline!
+Par contre, l'assemblage MUMPS (build K) pose un gros problème! Il y a donc du boulot pour Lilia: il faut clairement optimiser cette partie du code avant toute chose, au lieu d'essayer d'optimiser la phase de résolution qui elle semble OK (du moins en séquentiel).
+====== samcef.py ======
+Je me suis rendu compte que la licence actuelle de SAMCEF **ne donne plus accès à GHS3D**. Ca a peut être été dit, mais j'avais oublié.
+Conséquence: le fichier ''contactTetra.fdb'', que j'avais commité au départ pour pouvoir lancer la batterie avec la version russe de Samcef qui ne possède pas non plus GHS3D, est donc maintenant impossible à régénérer.
+Le problème c'est que la manière dont j'avais écrit ''samcef.py'' pour gérer les ''.fdb'' commités (à coté du ''.dat'' correspondant) était mal écrite. En effet, si par hasard le ''.dat'' est plus récent que le ''.fdb'', BACON est relancé pour régénégerle ''.fdb''. C'est très ennuyeux parce qu'en pratique, même lors d'un simple checkout, le ''.dat'' peut être plus vieux que le ''.fdb'' simplement parce que le ''svn checkout'' de Metafor a écrit le ''.fdb'' avant le ''.dat'' (c'est systématique avec ma virtualbox). Donc on subit une rebaconnade et paf, ca plante.
+<note>J'ai donc modifié ''samcef.py'' pour ne jamais rebaconner quand un ''.fdb'' est copié à côté du ''.dat''. Pour rebaconner, il faudrait supprimer le ''.fdb''.</note>
+Remarque: il n'y a aucune raison de copier un ''.fdb'' à côté du ''.dat'' en dehors du cadre de la batterie. De plus, le système reste intelligent: la rebaconnerie n'est jamais relancée si le ''.fdb'' du workspace est plus ancien que le ''.dat''. Donc en pratique, le système reste flexible. Si on veut encore plus de flexibilité, il faudra utiliser des checksums MD5 comme on l'a fait pour les maillages ''gen4''.
-Par contre, l'assemblage MUMPS pose un gros problème! Il y a donc du boulot pour Lilia: il faut clairement optimiser cette partie du code avant toute chose, au lieu d'essayer d'optimiser la phase de résolution qui elle semble OK (du moins en séquentiel).
 ====== Remarques finales ======
-Cette version a du mal à démarrer (il faut compter entre 5 à 10 secondes pour voir apparaitre le splash screen de Metafor. Meme en ''-nogui'' c'est lent au démarrage.
+La version MinGW a du mal à démarrer dans ma virtualbox (il faut compter entre 5 à 10 secondes pour voir apparaitre le splash screen de Metafor. Même en ''-nogui'' c'est lent au démarrage.
+Ci-dessous, un aperçu d'un run du "tube" avec le Process Explorer:
 {{ :commit:2015:mingw-process.png |}}
-On voit ci-dessus qu'il y a un gros travail de la part du système pour démarrer le code (la phase rouge au niveau du CPU). Est ce dû au 32bits? à XP? à la virtualbox? Il faut que je tire ça au clair.
+On voit qu'il y a un gros travail de la part du système pour démarrer le code (la phase rouge au niveau du CPU). Est-ce dû au 32bits? à XP? à la virtualbox? Il faut que je tire ça au clair.
-Pour info, voici le même graphe avec MUMPS:
+Pour info, voici le même graphe du même test avec MUMPS:
 {{ :commit:2015:mingw-mumps-lila.png |}}
+On voit bien que Lilia a ajouté une belle chevelure au graphe de CPU, ainsi qu'un tapis rouge tout le long du calcul. A vue de nez (je n'ai pas ouvert les routines), il y a trop d'allocations/désallocations lors du calcul.
  --- //[[romain.boman@gmail.com|Romain BOMAN]] 2015/08/12//