Retour d'expérience sur le multithreading sous perl

Bonjour à toutes et tous,
Je suis l'application manager d'une application développée en partie sous perl.
Cette application lancée une fois par mois, fait de gros calculs d'agrégation de données de calcul de valeurs attendues (régression linéaire) et de chargement Oracle à la fin.
Ce traitement peut durer 4 à 7 heures. Mon but est de réduire ce temps.
J'ai constaté que durant ces calculs, un des processeurs de mon serveur (sous unix avec perl en 5.8.8) était à pris 100% alors que les autres serveurs se roulaient les pouces.
J'ai lu la documentation : http://perldoc.perl.org/perlthrtut.html
et j'ai vu que je pouvais optimiser en faisant du multithreading.
Avant de demander une étude et éventuellement une telle évolution du code par mon sous-traitant (ce n'est pas moi qui développe) , je voulais savoir si quelqu'un avait utilisé cette fonctionnalité et échanger pour savoir si le gain est intéressant
Merci par avance

Je n'ai pas utilisé les threads Perl pour une vraie application (j'ai juste fait mumuse avec pour voir comment ils fonctionnaient).

Mais j'ai fait auparavant et fais encore occasionnellement du multihreading et du multiprocess dans d'autres environnements que Perl. Cela peut amener des gains notables de performance à condition que l'application se prête bien à un modèle ou un autre de parallélisme.

Par exemple, si l'on peut facilement partager les données en blocs indépendants de données et de donner un bloc à traiter à un thread, alors, c'est très facile.

De même si on peut partager les étapes d'un processus entre des threads avec un modèle de pipeline (un thread effectue un premier traitement sur les données) et les passe progressivement à un second qui fait un autre traitement sur les données modifiées par le premier, alors c'est également facile.

Mais d'autres problèmes sont beaucoup plus difficiles à paralléliser, notamment quand il faut avoir toutes les données en mains pour pouvoir en faire quelque chose d'utile (multiplication de deux très grosses matrices, par exemple), ou quand les données évoluent au cours du temps en fonction de données voisines (similation de processus physique complexe, par exemple prévision météo ou simulation d'explosion nucléaire).

Donc, la principale question n'est pas de savoir si les threads Perl marchent bien (ils existent depuis quelques années, c'est stable, je pense qu'ils marchent bien, à condition de prendre les différentes précautions voulues). La principale question est de savoir si, conceptuellement, tes données et ton application supportent bien un modèle ou un autre de parallélisme.

Je rajouterai également qu'avant de se lancer dans les threads pour optimiser le code, il faudrait voir si le programme en soit est optimisé (codes bien écrit, mise en mémoire de données si nécessaire ou non, expressions régulières bien écrites ou non...).

Merci pour vos deux réponses.
J'ai fait des tests sur un petit périmètre de mon application.
Dans mon cas il semble que se soit intéressant :
Je lis 6 fichiers plats assez gros sur lesquels je fais des calculs puis j'interroge une base Oracle sur 6 différentes tables et enfin je compare les données des fichiers avec les résultats des requêtes. La comparaison est mise en forme dans un fichier Excel.
J'ai créé un thread pour chaque fichier à lire et un thread par requête.
J'attends que les threads se terminent puis j'effectue ma comparaison.

Au final entre l'ancien fonctionnement et le nouveau j'ai un gain de 40% avec une modification de code restreinte.
Remarque : il faut initialiser une connexion Oracle par thread.

Mais je suis d'accord pour dire qu'il faut que le code soit propre et que l'on doit faire attention aux variables que l'on veut partager

Je me suis aidé des liens :
http://perldoc.perl.org/perlthrtut.html
http://perldoc.perl.org/threads.html
Cours et tutoriels PERL : http://perl.developpez.com/cours/

Les fichiers sont ils chargés entièrement en mémoire ?

Chaque thread ouvre son propre fichier et le parcourt ligne par ligne.
Pour chaque ligne je fais des totaux de montants et stocke les totaux dans une table de hachage (variable partagée entre les threads).
Les threads de bases de données quant à eux reçoivent directement des totaux via les requêtes Oracle.
Tout ceci correspond à la partie que j'ai parallélisé et gagné de temps.
Le reste du code est sans optimisation ( initialisation et remplissage d'un fichier Excel).

:ccool: