Le 18/03/2014 11:54, Stephanie MAHEVAS a écrit :

Bonjour Bonjour, Il faudrait aussi que l'on rediscute des pb mémoire et temps de simulation qui nous empeche toujours de faire tourner de grosses AS pour le modèle Manche et bloque le couplage avec Marxan. Comment vois-tu les choses sur ce sujet? C'est vrai qu'il y a ça aussi. Mais il y a beaucoup de choses en cours et à faire qu'il faut les prioriser. Qu'en penses-tu ? Ce point est-il plus prioritaire que la calibration ?

Benjamin devrait également pouvoir travailler sur les points des performances d'ici quelques temps, mais pas pour le moment. Cordialement, Eric. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

On Tue, 18 Mar 2014 18:46:48 +0100 Stephanie.Mahevas@ifremer.fr wrote: Salut,

Il est codé en C++. On peut aussi demander à Raphael le doctorant qui travaille avec Atlantis de nous presenter le côte technique informatique du modèle.

Je suis pour, s'il veut bien et qu'il a un peu de temps. Question: - travaille-t-il en matriciel ou en fonctionnel - si en matrice: - quelle taille de matrice (nombre de dimension, taille des dimensions) - quelle librairie (pour voir leur choix d'implantation) - Modifie-t-il les données durant la simulation ? Pour moi, le langage (s'il est le problème) n'est pas le seul problème. Il y a surement quelque chose qui bloque quelque part :(. Mais on a pas encore mis la main dessus. Pour les énormes matrices, il faut peut-être tester avec d'autres types d'implantations que celle par défaut. On a aussi: - DoubleSparseVector.java qui est toujours en double, mais ne conserve que les valeurs différente de la valeur par defaut (0). Donc si nos matrices contiennent que peut de valeur différente de 0. C'est peut-être mieux, mais si ce n'est pas le cas, c'est pire, car en plus on ne peut pas utiliser les optimisations de calcule sur les matrices. - FloatBigVector.java (identique au matrice par defaut, mais en Float (2 fois moins de place mémoire) - FloatVector.java (identique au DoubleSparseVector, mais en Float) L'utilisation des matrices est très pratique car elle permet d'uniformiser beaucoup de chose, de simplifier l'utilisation dans les scripts, de simplifier le stockage, et de simplifier l'affichage des résultats. Mais en même temps elle est pénalisante car on conserve des données non utiles. Mais je ne suis pas sur que de faire du fonctionnel soit mieux car nous devrons résoudre plusieurs problèmes que nous n'avons pas avec les matrices (et la solution à ces problèmes risque d'être moins optimum que d'utiliser des matrices). Ce qui est troublant avec les simulations de Loïc est que sur ma machine (4ans d'age et qui n'est pas très performante car de petit taille (processeur non gourmant et donc peu performant). 10 ans de simulation mettent 50 minutes (sans règle mais avec toutes les strategies (18), toutes les populations (14)). A priori les simulations de Loic prennent 5h. Ca veut dire que l'ajout des règles ajoute plus de 4 heures à la simulation ? Sachant qu'avec ou sans règle le simulateur fait la même chose (pas d'optimisation particulière s'il n'y a pas de règle). Ce qui voudrait dire que le code de règle prend 4 heures :(. Eric me souffle dans l'oreille qu'il y a peut-être une autre piste. Les équations durant la simulation peuvent être modifié, donc on regarde si c'est le cas ou non, et il y a un accès disque à chaque fois. Vu que sur CapArmor tous les disques sont réseaux, on se prend le problème d'avoir des fichiers isis sur le réseau. (ce qui collerait bien avec les 80% de temps perdu relevé par Tina). Je vais essayer de regarder ce qui peut-être fait pour supprimer ça. Il y a d'autres choses qui pourraient être regardées, mais il faut le faire ensemble. Par exemple SiMatrix.effortPerZonePop est appelé 25 millions de fois. Ce qui est tout de même énorme. Il faudrait peut-être revoir les calculs pour voir s'il n'est pas possible de faire autrement pour minimiser certains calculs. Car même s'il y a le cache qui joue convenablement sont rôle. Moins on l'utilise, mieux on se porte. (cette méthode représente tout de même 1/4 du temps de simulation, même si en moyenne un appel prend moins de 7 microseconde) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com