Bonjour merci pour ces bonnes nouvelles et toutes tes explications. J'ai des commentaires, question et suggestions ci-dessous. Benjamin POUSSIN a écrit:
Bonjour,
Une nouvelle version d'isis-fish vient d'être mise en place.
http://isis-fish.labs.libre-entreprise.org/download/version2/ifremer-simulat...
* passage de toutes les matrices en float pour prendre 2 fois moins de place * amelioration de la liberation du cache de calcul * ajout d'une condition pour les logs de SiMatrice2 * ajout de l'exception lors de log de probleme grave dans ifremerdb.xml
J'ai reussi a faire tourner la pecherie de stephanie, mais c impossible de voir les resultats (ils sont trop gros pour passer en memoire, donc la solution a priori est de faire des exports automatique pour avoir les resultats que l'on souhaite directement en fichier texte
22 strategies 24 metiers 70 zones 70 mailles 2 populations
Il y a une erreur dans la migration 1 zone qui n'existe plus mais qui est utilisé pour la migration des crevettes il me semble (donc migration impossible) mais la simulation tourne tout de meme
quel impact cela a vraiment? Est-ce une erreur de mon cote (pb de saisie) que je peux corriger (car je ne vois aucune migration)?
La simulation a utilisé 1,3 Go de mémoire, j'ai utilisé ShiftOne avec 300000 objets (je pense que mettre moins de 250000 voir 200000 n'est pas jouable, car ca prendrait trop de temps)
les temps pour 10 ans de simulation 30 min de simulation (initialisation comprise) (donc ~15 secondes par mois) 7 min d'export 44 min de sauvegarde
Donc pour faire tourner une simu il me faut une machine qui a plus de 1.3 Go de memoire. Est-il possible de faire tourner la simu sans sauvegarde, uniquement avec des exports?
Pour arriver a faire tourner la simulation j'ai du me battre pas mal avec les matrices et les scripts. J'ai passé les matrices en float (on perd donc en précision). Et du coup les scripts ne fonctionnait plus :(
Mais il va forcement falloir faire des choix, car au depart on m'avait dit qu'au dela de quelques metiers/strategies (c-a-d inferieur 10) les simulations ne servait plus a rien car on ne pouvait pas savoir ce qui impactait sur quoi.
Ici il y 22 stratégies pour moi c 3 fois trop. Lorsque je dis pour moi je parle pour le simulation, car en calculant un peu la place d'une seul matrice de résultat on obtenait tout de même 75Mo pour elle, or elle n'est pas toutes seules il y en a beaucoup d'autre (17 exactement). Et la taille d'une matrice quelque soit le langage c la meme chose (Java/C/C++/...). (avec une moyenne de 40Mo/matrice 17*40=680Mo il ne reste pas grand place pour le reste de la simulation et de l'application :()
c'est tres important d'avoir ce type d'ordre de grandeur. Notre strategie n'est pas de se limiter dans le nombre d'objets car pour des besoins de modelisation on peut souhaiter regarder la sensibilite a des definitions plus fines (+ d'objets) de la pecherie. Meme s'il est toujours souhaitable de travailler avec un nombre le plus faible possible de metiers/strategies. Serait-il possible d'avoir des sauvegardes a la carte? laisser l'utilisateur choisir entre aucune sauvegarde et que des exports selectionner dans les objets possibles
Donc soit il faut modifier la representation des matrices, mais cela va faire perdre en performance, soit il faut restraindre les possibilités (nombre de strategies simultanément utilisé moins grand).
De plus modifier la représentation des matrices n'est pas forcement très simple. En me creusant beaucoup la tête je pense en avoir trouvé une mais, je ne sais pas ce que cela peut donner tant que je ne l'ai pas implantée.
Ok on ne prend pas ce risque pour l'instant.
En résumé, le réelle problème que l'on a c la place mémoire. - Il faut que la simulation fonctionne uniquement en RAM, sinon elle met trop de temps. - La taille des calculs intermédiare est proportionnelle au nombre d'objet et il faut au maximum essayer de conserver ces calculs pour gagner du temps - La taille des résultats est proportionnelle au nombre d'objet et il faut au maximum essayer de conserver les résultats pour gagner du temps lorsque les règles de gestion en ont besoin
avoir une selection des objets a conserver pour decrire le comportements des pecheurs: aujourd'hui: captures et debarquements par unite d'effort en poids et valeurs de toute la simu demain : en plus l'ensemble des indicateurs economiques
Toutes réductions de ce que l'on conserve en RAM, est pénalisant pour les performances.
Si on conserve trop de chose en RAM, soit la simulation met trop de temps (SWAP) soit la simulation échoue car pas assez de mémoire,
Dans la version 3 j'ai prevu de sauver les resultats dans la base au fur et a mesure de la simulation, cela a l'avantage de gagné de la place en RAM, car on peut les enlever de la RAM si on ne les utilise pas, mais forcement l'inconvéniant est l'acces au disque dur qui fait perdre du temps.
De meme a priori il n'y aura pas de probleme de chargement de simulation pour le rendu, car les resultats seront chargé pour le rendu que l'on demande, alors que maintenant on charge tous les resultats avant de savoir lesquels l'utilisateur va utiliser.
Donc la reflexion sera a faire porter sur les objets a garder pour la reaction des pecheurs (gravite et mesures de gestion), sachant que la rien n'est statique et tout depend de ce que l'on code. On peut deja dire que pour les modeles de gravite CPUE, LPUE et VPUE codes, on a besoin que de l'info captures et debarquements par unite d'effort sur toute la simu mais que en general uniquement la derniere annee est utilisee. Donc peut etre, pour les cas ou il faut aller chercher plus loin dans le temps on pourrait envisager un acces disque dur.
La seule autre optimisation de place est la modification d'implantation des matrices, mais comme je l'ai dit a priori cela fera aussi perdre un peu de temps (mais qui je pense peu etre acceptable)
La liberation des calculs intermediaire est deja mis en place au travers du cache.
ce soir je teste une simu 2 ans avec gravite, 10 ans avec gravite, 10 avec fermeture de zone. a demain pour les resultats stephanie
------------------------------------------------------------------------
_______________________________________________ Isis-fish-user mailing list Isis-fish-user@lists.labs.libre-entreprise.org http://lists.labs.libre-entreprise.org/mailman/listinfo/isis-fish-user
-- ...................................................................... Stephanie MAHEVAS (Stephanie.Mahevas@ifremer.fr) IFREMER/EMH (Ecologie et Modèles pour l'Halieutique) Tel: 02 40 37 41 81 Fax: 02 40 37 40 75 o \ o / _ o __| \ / |__ o _ \ o / o /|\ | /\ ___\o \o | o/ o/__ /\ | /|\ / \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \ ......................................................................