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 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 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 :() 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. 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 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. 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. -- Benjamin -------------------- email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii