Differences

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

--- commit:2015:08_12 [2015/08/12 11:48] – boman
+++ commit:2015:08_12 [2016/03/30 15:23] (current) – external edit 127.0.0.1
@@ Line 87: / Line 87: @@
 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 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).
+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 ======
@@ Line 128: / Line 130: @@
 ====== 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.
+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//