ralentissement d'un calcul itéré sous EDI Delphi 2009, mais pas sous DOS

Question

J'utilise Delphi 2009 avec lequel j'ai rédigé un programme en mode console dans lequel je répète 100 fois le même calcul. Ce calcul utilise à un moment 7 threads en complément du thread principal. Le programme utilise des tableaux dynamiques, mais tous sont déclarés en dehors des threads secondaires afin de ne pas produire de ralentissement du fait de leur allocation. Quand ce programme est exécuté dans une fenêtre DOS, chacune des 100 itérations dure le même temps (de l'ordre de 3 secondes chacune). Par contre, quand il est lancé sous l'EDI Delphi 2009, la durée de chaque itération s'allonge progressivement, la centième durant à peu près le double de temps de la première. J'ai vérifié que la charge en mémoire ainsi que le mémoire physique disponible ne bougeait pas pendant les 100 itérations que le programme soit lancé sous DOS ou sous l'EDI. Est-il donc normal que sous l'EDI, la durée du calcul s'allonge ?
Merci.
JM  
P.S. Si vous vous demandez pourquoi je répète le même calcul 100 fois, c'est parce qu'il s'agit d'une simulation stochastique (aléatoire) et que je suis intéressé à connaître la stabilité des résultats.

Caribensila · Answer

Bonjour,

Libères-tu bien (Finalize) les tableaux dynamiques entre chaque itération?

jcornuet · Answer

Merci de me répondre.
Non, les tableaux dynamiques sont alloués une fois pour toutes au début du programme. De plus pour éviter des conflits de lecture entre threads, les tableaux sont démultipliés (dès le début) un nombre de fois égal au nombre de threads, de telle sorte que chaque thread lit et écrit dans ses propres tableaux.
Si les tableaux dynamiques étaient réalloués à chaque itération, est-ce que cela ne devrait pas affecter également l'exécution sous DOS et sous EDI ?

jcornuet · Answer

Merci pour ta réponse. 
Es-tu sûr de ton lien car je n'ai trouvé les commentaires que de Nicolas, WhiteHippo et Bacterius.

Caribensila · Answer

Oui, le lien est valide.
Mais il y a 4 pages de commentaires. Regarde les autres pages (en cliquant sur page2,3,etc..., en bas)...

Francky23012301 · Answer

Salut,

Il y a deux choses qui me font tilter :
*3 Secondes pour un calcul : c'est énorme! Ca sent le truc pas optimisé du tout.
*7 Threads : C'est énorme! Attention les threads ne s'executent pas en même temps, ils se partagent du temps. Donc ce n'est pas en utilisant 7 threads, ca ne vas pour autant plus vite, au contraire ca peut ralentir ton calcul

jcornuet · Answer

Désolé Caribensila,

J'ai effectivement été très intéressé par les commentaires. J' utilise moi-même FastMM dans un programme en Delphi6 parce que c'est le seul moyen que j'ai trouvé pour charger un très gros fichier (>1Gb) en mémoire (->TmemoryStream). En effet, pour charger 1Gb en mémoire, il ne suffit pas d'avaoir 1Gb de disponible dans la mémoire physique, encore faut-il qu'elle soit en un seul bloc. Il faut donc trouver le bloc adéquat, ce qui était possible avec les fonctions de FastMM4.
Par contre, dans le problème présent, je me demande si le débugger de Delphi n'a pas à effectuer un travail de suivi (???) qui se complexifierait avec le temps et qui progressivement retarderait le programme.
En tout cas, merci encore.

Caribensila · Answer

@Francky
Si la simulation de jcornuet emploi la méthode de Monte-Carlo par exemple, 3 secondes pour un calcul n'est pas étonnant.

Quand aux Threads, je suis de ton avis. 7 threads me paraît aussi beaucoup. 
A moins que notre ami possède un 8-Core. Auquel cas ça peut bcp augmenter la vitesse de traitement (1 Thread par core + le tread principal).

jcornuet · Answer

En effet j'ai choisi 7 threads parce que j'utilise un bi-pro quad-core (8 "processeurs" vus par Windows). Au début, j'avais programmé avec 8 threads, mais c'était légèrement plus lent (question d'équilibrage entre thread principal et threads secondaires). En monothread, ça prend 5 à 6 fois plus de temps.
Quant aux 3 secondes pour un calcul, ce n'est pas si long que cela si on considère qu'à chaque itération, le programme simule 12 fois 5000 arbres généalogiques de 75 gènes, selon un algorithme impliquant pour chaque arbre des calculs assez lourds.

Caribensila · Answer

@jcornuet
- De la génétique évolutionniste?
Il y a longtemps que le sujet me tente. 
J'espère que tu nous montreras le résultat en postant ton application ici, si c'est possible. 

Pour le multi-threading, tu laisses faire le système ou tu emploies SetProcessAffinityMask et SetThreadAffinityMask ?

Quant au sujet principal de ce topic, tiens-nous au courant, stp. J'ai en effet l'habitude de tester les performances de mes applis sous l'EDI de Delphi sans me poser de question. Mais c'est peut-être une connerie.

Caribensila · Answer

@jcornuet

Sans être indiscret... Tu ne ferais pas dans l'Apis mellifica ?

jcornuet · Answer

"Il y a longtemps que le sujet me tente. 
J'espère que tu nous montreras le résultat en postant ton application ici, si c'est possible."

Va sur www1.montpellier.inra.fr/CBGP/diyabc/ 
Ce n'est pas l'application en question, mais une autre  du même genre (celle justement où j'utilise FastMM4)

Pour ton autre question, Apis mellifera a longtemps été mon sujet principal.

Caribensila · Answer

Merci pour le lien.
Et c'est la 1ère fois que je rencontre un scientifique qui n'utilise pas Java. C'est peut-être la biologie qui veut ça...  lol

jcornuet · Answer

La plupart de mes collègues en France et à l'étranger programment en C/C++. Moi-même, j'ai écrit quelques DLL en C/C++ pour accélérer mon programme en Delphi (avant que je ne me lance dans les threads Delphi). J'ai eu fait du basic et du fortran il y a bien longtemps, mais je n'ai jamais touché à Java et je ne connais pas de collègues dans mon secteur qui y aient touché. Vu la longueur de nos runs, il nous faut un langage "rapide" et Java n'avait pas cette réputation.

Ralentissement d'un calcul itéré sous EDI Delphi 2009, mais pas sous DOS

13 réponses

Votre réponse

Discussions similaires