[Vitesse d'execution] Perl vs C

[The Lootrophile]

Coucou tout le monde,

Je travaille pour une grosse boîte de télécom outre-manche, et je bosse actuellement sur les serveurs qui font les statistiques des routeurs.. Ça se décompose en plusieurs serveurs : un collecteur, vers lequel convergent les données de milliers de routeurs, un processeur (un serveur qui pédale vite) qui récupère les données sur le collecteur, et qui les traite pour être mises dans une BDD RRD, et affichées dans l'espace utilisateur des clients.

Le problème est qu'il y a de plus en plus de données à traiter, et que le processeur commence à être à la bourre (cinq semaines de retard, 68 Go de données à traiter, les clients qui râlent, toussa.. Pour des statistiques censées être temps réel, ça fait mauvais genre. ) En gros le processeur met quatre minutes à traiter deux minutes de statistiques, donc vous voyez l'embrouille..

J'hésite entre deux solutions :

- Mettre le script de mon processeur, écrit en Perl, sur un nouveau serveur plus rapide

- Réécrire la bestiole en C, ce qui ne va pas être une mince affaire, mais si ça vaut le coup..

- ... et enfin la solution qui consistera à utiliser plusieurs serveurs, mais ça sera envisagé une autre fois

J'ai demandé à l'ami Google ce qu'il en pensait, et il m'a trouvé à boire et à manger, mais pas vraiment de statistiques, comme j'en cherchais.. Alors peut-être que les INpactiens Avez vous une idée du gain de temps pour l'execution d'un programme écrit en Perl par rapport au C ? (c'est du traitement de données brut + de la lecture/écriture de fichiers)

Merci d'avance,

The Lootrophile

[sarx]

Je ne me suis jamais vraiment posé la question du gain de performance que pourrait procurer la réécriture d'un script Perl en C, les scripts Perl que j'ai eu l'occasion de toucher ne souffrait pas vraiment de problème de performance. D'ailleurs j'ai rarement vu un programme Perl utilisé dans un contexte ou les performances sont une contrainte.

Un début de réponse peut tout de même ressortir en regardant le mécanisme d'execution de perl.

Avec le langage Perl, il n'y a pas de compilation en amont (comme en C ou en Java).

A chaque execution, une compilation a la volée est réalisée.

Cette compilation genère un AST (arbre syntaxique, pas de bytecode, du moins pour Perl 5).

L'AST est ensuite optimisée puis interpreté.

En C la phase de compilation/optimisation est réalisée de façon unique en amont, et donc la durée d'execution en est réduite d'autant comparativement au Perl.

Du coup en tout logique tu gagneras forcement en temps d'execution rien qu'en retranscrivant en C ton programme Perl.

Apres sur la durée d'execution (hors phase de compilation), perl est très performant, mais je ne suis pas sur qu'il puisse rivaliser avec le C, langage généralement cité comme exemple de Performance...

Enfin tu peux toujours programmer un script perl (tout bete) de lecture/traitement d'un fichier et faire son equivalent en C, pour juger de la difference de perf.

Sinon tu peux essayer de regarder le module B::CC, module experimentale et surement bien buggé, si t'as de la chance ca peut marcher dans ton cas

[Shtong]

En complément de la réponse de Sarx, je donnerais aussi les pistes de la parallèlisation (si tu maîtrise pour pouvoir utiliser ce genre de mécanisme).

Autre piste à explorer, la réécriture du programme, en mieux. Au boulot j'ai déjà vu des programmes qui mettaient une demi-heure à s'exécuter, et qui une fois réécris plus intelligement prenaneit une ou deux minutes .

[Sentinel]

C'est le genre de trucs qui peut se faire en Java aussi, ce langage est taillé pour le parallélisme et la répartition de charge.

[lorinc]

Le gros avantage de le refaire en C, c'est que tu peux toucher à la mémoire comme tu veux, et c'est généralement LE truc qui tue les optimisations de compilo. Si tu regardes attentivement, tu peux minimiser le nombre d'allocation, bien vérifier l'alignement de tes données, faire des parcours malins, etc. Bref faire plein de chose qu'une programmation simili-objets empêche (par design) de faire rapidement.