At 03:15 08.04.02, you wrote:
>On Sunday 07 April 2002 03:40, MuTECH wrote:
> >
> > Je me suis amuser � faire un petit test avec les fonctions �quivalente en C
> > (j'ai un peu optimalis� l'algorythme). Cela mais environ 13 secondes pour
> > 1000000 op�ration sur pIII � 566 MHz. Ce serai int�ressant de comparer en
> > la transformant en une librarie pouvant �tre appel�e depuis le Perl et
> > comparer.
>
>Oui, il est int�ressant de comparer, mais n'oublions pas que les objectifs
>des langages comme Perl, C, php, *sh et zope sont diff�rents.
>Je laisse volontairement de c�t� Fortran, Cobol, HPL, Lisp, Prolog, Eifel,
>Ada... d'accord ?
>
>Un langage comme le C est un langage compil� dont l'obejctif est avant tout
>la performance. Il dispose de libariries nombreuses mais requiert un peu plus
>de lourdeur pour la mise en oeuvre. le fameux exemple 'printf("hello world
>!\n")' a quand m�me besoin de passer par un compilateur...
>
>Les autres langages cit�s sont des langages "interpr�t�s". C'est � dire dont
>la mise en oeuvre est tr�s rapide. Par exemple, si je veux afficher "hello
>world !" sur mon terminal, il me suffit de taper : echo "hello world !".
>Quand j'ecris un script, c'est parceque je veux faire un truc rapide, essayer
>tout de suite ou par �tape; mais aussi parceque je dispose, en g�n�ral, d'une
>palette d'outils accessibles depuis mon langage. C'est typiquement le cas de
>shelle scripts qui utilisent les commandes du style : sed, cut, sort, tr, etc.
>C'est encore plus vrai pour Perl pour lequel il existe un tr�s grand nombre
>de "librairies" existantes et en perp�tuelle �volution (ce qui est aussi un
>inconv�nient). Zope est aussi un langage des script d�di� et a aussi ses
>limites.je ferai remarquer que Zope inclus d'office la posibilit� d'utiliser des scripts Python et Perl, de plus il offre des fonctionalit� comme le "clustering", "load balancing" et l'encapsulage des donn�e tel que les scripts et le code HTML o� DTML dans une BD, je me vois mal faire ceci facilement avec uniquement du Perl ou du Python. >Tout d�pends donc de ce que l'on veut faire. Mon avis perso est que les >langages de scripts sont tr�s faciles � modifier et � mettre en oeuvre. >Toutefois, � partir d'une certaine taille, il deviennent plus difficiles � >g�rer (~10'000 lignes). C"est aussi en partie d� � un manque d'outils de >debugging de haut niveau. Par opposition, C permettra de faire des >applications plus "lourdes" mais sera peut-�tre moins �vident � manipuler. >A mon avis, benchmarker le C avec des langages de scripts n'apportera pas >grand chose... le r�sultat est connu d'avance. Par contre je peux �crire un >script manipulant des fichiers texte dans tous les sens tr�s rapidement alors >que le faire ne C me prendrait certainement plus longtemps. C'est peut-�tre >aussi un autre genre de benchmark :-) Pour des d�velopements de grande anvergure, l'optique que l'on appliquai dans les bo�tes ou je travaillai avec d'�tre � mon compte �tait de partir avec un o� des languages tr�s strict puis apr�s analyse des perfomances d'optimaliser les parties critiques avec languages mieu adapters. Il c'est avair� que pour des softs comme ceux sur lesquels j'ai travail� (~300 home ann�e) que la phase de controls c'est trouv�e nettement plus courte et la fiabilit� du syst�me bien meilleur qu'un d�velopement sur un language tel que le C. Naturellement ce genre de d�velopement n'est pas le cas habituel sur linux. De plus Internet permet g�n�ralement de partager le temps de debugage avec nettement plus de personnes que le nombre de d�velopeur ce qui fait que le developpement en C devient un solution des plus performante. C'est d'ailleur l'un des caract�ristique du libre, il y a nettement plus de personnes qui sont pr�s � ajouter leur pi�re � l'�difice pour corriger un bug par ci et par l� que de personnes qui participe � de gros projet. De plus d'avoir des aproches tr�s diversent au niveau du debugage permet une couverture bien meilleur des probl�mes possibles. Naturelement c'est toujours le compromis entre le temps de d�veloppement, la fiabilit� et ce que demande le marketing. Martial >Daniel > > >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se d�sabonner aussi. ---------- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
