Differences

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

--- commit:2015:08_12 [2015/08/12 12:03] – [Perfs?] 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.
+**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).
@@ Line 101: / Line 103: @@
-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//