Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2015:08_12

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
commit:2015:08_12 [2015/08/12 12:05] – [Perfs?] bomancommit:2015:08_12 [2016/03/30 15:23] (current) – external edit 127.0.0.1
Line 109: Line 109:
 {{ :commit:2015:mingw-image2.png |}} {{ :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 ====== ====== samcef.py ======
Line 130: Line 130:
 ====== Remarques finales ====== ====== 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 |}} {{ :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 |}} {{ :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//  --- //[[romain.boman@gmail.com|Romain BOMAN]] 2015/08/12//
commit/2015/08_12.1439373903.txt.gz · Last modified: 2016/03/30 15:22 (external edit)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki