salut, merci pour vos réponses concernant les différences de vitesse de simulation sur 2 ordis équivalents. Il se trouve en fait que je faisais tourner la même base mais pas les mêmes espèces et l'une d'elles (la sole) est bcp plus lente. Pourtant elle a seulement 5 zones pop contre 3 pour l autre espèce plus rapide... mystere. Le check de la pecherie ne révèle pas d erreur. j ai aussi eu, tjs pour la sole (pas de pb avec les autres sp), un plan d exp sequentiel stoppé a 15 simus pour "out of memory" (cf log ci dessous). je suis en 32 bits comme suggere par Benjamin et J'avais modifié les options pour utiliser BigMappedVector comme suggeré par Eric mais je ne suis pas sure que ca ait ete pris en compte étant donné le log: "at org.nuiton.math.matrix.DoubleBigVector.<init>(DoubleBigVector.java:46)". Je joints la base au cas ou l'un de vous voudrait s'y pencher. Merci d'avance de vos pistes d amélioration. at scripts.SiMatrix_1__868283490_809066700___AW_JoinPoint.invoke(Unknown Source) at scripts.SiMatrix.matrixCatchPerStrategyMetPerCell(SiMatrix.java) at scripts.SiMatrix.aw$original$_AW_$matrixCatchPerStrategyMetPerZonePop$_AW_$scripts_SiMatrix(SiMatrix.java:330) at scripts.SiMatrix_1__594510243_443471776___AW_JoinPoint.proceed(Unknown Source) at fr.ifremer.isisfish.util.Cache.realCall(Cache.java:204) at fr.ifremer.isisfish.util.Cache.get(Cache.java:129) at fr.ifremer.isisfish.aspect.CacheAspect.call(CacheAspect.java:82) at scripts.SiMatrix_1__594510243_443471776___AW_JoinPoint.proceed(Unknown Source) at scripts.SiMatrix_1__594510243_443471776___AW_JoinPoint.invoke(Unknown Source) at scripts.SiMatrix.matrixCatchPerStrategyMetPerZonePop(SiMatrix.java) at simulators.DefaultSimulator.computeMonth(DefaultSimulator.java:452) at simulators.DefaultSimulator.simulate(DefaultSimulator.java:216) at simulators.SimulatorEffortByCell.simulate(SimulatorEffortByCell.java:51) at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:391) at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:265) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedConstructorAccessor155.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at org.nuiton.math.matrix.MatrixFactory.createVector(MatrixFactory.java:240) ... 25 more Caused by: java.lang.OutOfMemoryError: Java heap space at org.nuiton.math.matrix.DoubleBigVector.<init>(DoubleBigVector.java:46) ... 29 more INFO|20:29:08,788|InProcessSimulatorLauncher.java|464|localSimulateSameThread|Simulation time: 6148.380 -- Sigrid LEHUTA ~ ><> ~ Post-doctoral research associate Laboratoire Ressources Halieutiques IFREMER Boulogne sur Mer 150 quai Gambetta, 62200 Boulogne-sur-Mer, France Tél : 03 21 99 50 61 (N° interne : 5061) Fax : 03 21 99 56 01 Membre de l'Association Française d'Halieutique http://sirs.agrocampus-ouest.fr/AFH/index.php/en "Like all creative activities, modelling gives joy to its maker." A. Saltelli.
salut,
merci pour vos réponses concernant les différences de vitesse de simulation sur 2 ordis équivalents. Il se trouve en fait que je faisais tourner la même base mais pas les mêmes espèces et l'une d'elles (la sole) est bcp plus lente. Pourtant elle a seulement 5 zones pop contre 3 pour l autre espèce plus rapide... mystere.
Le check de la pecherie ne révèle pas d erreur.
j ai aussi eu, tjs pour la sole (pas de pb avec les autres sp), un plan d exp sequentiel stoppé a 15 simus pour "out of memory" (cf log ci dessous). je suis en 32 bits comme suggere par Benjamin et J'avais modifié les options pour utiliser BigMappedVector comme suggeré par Eric mais je ne suis pas sure que ca ait ete pris en compte étant donné le log: "at org.nuiton.math.matrix.DoubleBigVector.<init>(DoubleBigVector.java:46)". C'est pour le stockage des résultats en fait, mais ca n'a pas l'air d'être le
Le 22/08/2013 09:53, Sigrid LEHUTA a écrit : problème actuel. J'ai regardé rapidement la base de donnés, il y a quelques quantité de données (metier, population, strategies...) et le tout croisés doit faire des matrices assez lourdes en mémoire. Ici tes simulations doivent tourner en sous processus ? Si c'est bien le cas, le sous processus doit être limite en mémoire, et tu dois pouvoir lui augmenter sa mémoire: dans la configuration : simulation.sub.max.memory (qui est a 1024M) par défaut. Tu dois pouvoir monter à 1500M (au max à 1700M en 32bits sous windows). Ca devrait déjà aider un peu. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
C'est bien en sous processus, j essaie d augmenter la memoire. Quand on lance un plan sequentiel sur caparmor, est ce la memoire locale ou celle de caparmor qui est utilisee ? car je crois avoir eu le pb sur caparmor aussi. Pour info, j ai fait un test et en effet en limitant le nombres de zone de la pop a 3 au lieu de 8 la vitesse est multipliee par 4! J essai aussi d optimiser mon equation de migration qui est lourde mais pour le moment ca n aide pas... voici le plus efficace que j ai trouvé: if(group.getAge() > 2 && "Sole_spawning".equals(departureZone.getName())){ if(N.sumAll() < 70000000 && "Sole_low1".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 70000000 && N.sumAll() < 125000000 && "Sole_low2".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 125000000 && N.sumAll() < 145000000 && "Sole_med3".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 145000000 && N.sumAll() < 160000000 && "Sole_high4".equals(arrivalZone.getName())){return 1; }else if(N.sumAll() > 160000000 && "Sole_high5".equals(arrivalZone.getName())){ return 1; }else return 0; } else return 0; y'a t il une ecriture plus efficace pour les tests? Merci Le 22 août 2013 11:31, Eric Chatellier <chatellier@codelutin.com> a écrit :
salut,
merci pour vos réponses concernant les différences de vitesse de simulation sur 2 ordis équivalents. Il se trouve en fait que je faisais tourner la même base mais pas les mêmes espèces et l'une d'elles (la sole) est bcp plus lente. Pourtant elle a seulement 5 zones pop contre 3 pour l autre espèce plus rapide... mystere.
Le check de la pecherie ne révèle pas d erreur.
j ai aussi eu, tjs pour la sole (pas de pb avec les autres sp), un plan d exp sequentiel stoppé a 15 simus pour "out of memory" (cf log ci dessous). je suis en 32 bits comme suggere par Benjamin et J'avais modifié les options pour utiliser BigMappedVector comme suggeré par Eric mais je ne suis pas sure que ca ait ete pris en compte étant donné le log: "at org.nuiton.math.matrix.DoubleBigVector.<init>(DoubleBigVector.java:46)". C'est pour le stockage des résultats en fait, mais ca n'a pas l'air d'être le
Le 22/08/2013 09:53, Sigrid LEHUTA a écrit : problème actuel.
J'ai regardé rapidement la base de donnés, il y a quelques quantité de données (metier, population, strategies...) et le tout croisés doit faire des matrices assez lourdes en mémoire.
Ici tes simulations doivent tourner en sous processus ? Si c'est bien le cas, le sous processus doit être limite en mémoire, et tu dois pouvoir lui augmenter sa mémoire: dans la configuration : simulation.sub.max.memory (qui est a 1024M) par défaut. Tu dois pouvoir monter à 1500M (au max à 1700M en 32bits sous windows). Ca devrait déjà aider un peu.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 22/08/2013 11:48, Sigrid Lehuta a écrit :
C'est bien en sous processus, j essaie d augmenter la memoire.
Quand on lance un plan sequentiel sur caparmor, est ce la memoire locale ou celle de caparmor qui est utilisee ? car je crois avoir eu le pb sur caparmor aussi. Pour caparmor, il y a une autre configuration dans l'interface de configuration dédiée. Pour info, j ai fait un test et en effet en limitant le nombres de zone de la pop a 3 au lieu de 8 la vitesse est multipliee par 4! J essai aussi d optimiser mon equation de migration qui est lourde mais pour le moment ca n aide pas... voici le plus efficace que j ai trouvé: if(group.getAge() > 2 && "Sole_spawning".equals(departureZone.getName())){ if(N.sumAll() < 70000000 && "Sole_low1".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 70000000 && N.sumAll() < 125000000 && "Sole_low2".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 125000000 && N.sumAll() < 145000000 && "Sole_med3".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 145000000 && N.sumAll() < 160000000 && "Sole_high4".equals(arrivalZone.getName())){return 1; }else if(N.sumAll() > 160000000 && "Sole_high5".equals(arrivalZone.getName())){ return 1; }else return 0; } else return 0;
y'a t il une ecriture plus efficace pour les tests? Merci Même si l’équation était mal écrite, elle renvoi juste un double suivant les paramètres d'entrée et son code n'a pas d'incidence sur la taille des matrices.
Au pire, ca pourrait en avoir sur le temps d’exécution, mais pour ce qui est fait actuellement, je pense que c'est négligeable. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Le 22/08/2013 11:48, Sigrid Lehuta a écrit :
C'est bien en sous processus, j essaie d augmenter la memoire.
Quand on lance un plan sequentiel sur caparmor, est ce la memoire locale ou celle de caparmor qui est utilisee ? car je crois avoir eu le pb sur caparmor aussi.
Pour info, j ai fait un test et en effet en limitant le nombres de zone de la pop a 3 au lieu de 8 la vitesse est multipliee par 4! J essai aussi d optimiser mon equation de migration qui est lourde mais pour le moment ca n aide pas... voici le plus efficace que j ai trouvé: if(group.getAge() > 2 && "Sole_spawning".equals(departureZone.getName())){ if(N.sumAll() < 70000000 && "Sole_low1".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 70000000 && N.sumAll() < 125000000 && "Sole_low2".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 125000000 && N.sumAll() < 145000000 && "Sole_med3".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 145000000 && N.sumAll() < 160000000 && "Sole_high4".equals(arrivalZone.getName())){return 1; }else if(N.sumAll() > 160000000 && "Sole_high5".equals(arrivalZone.getName())){ return 1; }else return 0; } else return 0; En fait, Jean viens de me faire part d'une bonne remarque.
N.sumAll() est en fait problématique car cela parcours toute la matrice d'abondance. Il vaut mieux mettre le calcul une seule fois en début d'equation: double NsumAll = N.sumAll(); et utiliser la variable NsumAll ensuite. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Super ça fait gagner presque 2 min! MERCI! Le 22 août 2013 12:26, Eric Chatellier <chatellier@codelutin.com> a écrit :
C'est bien en sous processus, j essaie d augmenter la memoire.
Quand on lance un plan sequentiel sur caparmor, est ce la memoire locale ou celle de caparmor qui est utilisee ? car je crois avoir eu le pb sur caparmor aussi.
Pour info, j ai fait un test et en effet en limitant le nombres de zone de la pop a 3 au lieu de 8 la vitesse est multipliee par 4! J essai aussi d optimiser mon equation de migration qui est lourde mais
Le 22/08/2013 11:48, Sigrid Lehuta a écrit : pour
le moment ca n aide pas... voici le plus efficace que j ai trouvé: if(group.getAge() > 2 && "Sole_spawning".equals(departureZone.getName())){ if(N.sumAll() < 70000000 && "Sole_low1".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 70000000 && N.sumAll() < 125000000 && "Sole_low2".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 125000000 && N.sumAll() < 145000000 && "Sole_med3".equals(arrivalZone.getName())){ return 1; }else if (N.sumAll() > 145000000 && N.sumAll() < 160000000 && "Sole_high4".equals(arrivalZone.getName())){return 1; }else if(N.sumAll() > 160000000 && "Sole_high5".equals(arrivalZone.getName())){ return 1; }else return 0; } else return 0; En fait, Jean viens de me faire part d'une bonne remarque.
N.sumAll() est en fait problématique car cela parcours toute la matrice d'abondance.
Il vaut mieux mettre le calcul une seule fois en début d'equation: double NsumAll = N.sumAll();
et utiliser la variable NsumAll ensuite.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 22/08/2013 09:53, Sigrid LEHUTA a écrit :
salut,
merci pour vos réponses concernant les différences de vitesse de simulation sur 2 ordis équivalents. Il se trouve en fait que je faisais tourner la même base mais pas les mêmes espèces et l'une d'elles (la sole) est bcp plus lente. Pourtant elle a seulement 5 zones pop contre 3 pour l autre espèce plus rapide... mystere. En fait, un des PC avait Java 7 (rapide) et l'autre Java 6 (lent). Java 7 ayant fait des progrès sur les architectures 64 bits, en installant Java 7 sur le second PC, cela a solutionné le problème.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
participants (3)
-
Eric Chatellier -
Sigrid LEHUTA -
Sigrid Lehuta