[Toulouse-pm] [ppm] YAPC::Europe::2003 (1) (fwd)

[Michel Rodriguez]

Salut,

Je vous transmet quelques compte-rendus de YAPC, si vous avez des
problemes d'encodages dites le moi, ca se melange alegrement chez moi.


---------- Forwarded message ----------
Date: Mon, 28 Jul 2003 18:08:58 +0200
From: "[ISO-8859-1] Sébastien Aperghis-Tramoni" <maddingue at free.fr>
To: Paris.pm <paris-pm-list at pm.org>
Subject: [ppm] YAPC::Europe::2003 (1)

Mercredi 23 juillet

* Nicholas Clark - When Perl is not quite fast enought
     Nicholas Clark est un type très marrant : il arrive avec un sourire
     jusqu'au oreilles et un sombrero mexicain et ne départira pas
     ni de l'un ni de l'autre durant les trois jours de YAPC.

     Son talk est consacré aux techniques d'optimisations de Perl.
     Les premières méthodes sont évidemment d'utiliser XS et/ou Inline.
     Il conseille aussi de recompiler son Perl avec plus de flags
d'optimisation
     (genre -O2 ou -Os, ainsi que les flags d'archi -march=YOURCPU) et
     moins de flags de debug (-g et les defines de debug). Autre
possibilité,
     utiliser une autre version de Perl, plus ancienne ou plus récente
suivant
     les fonctionnalités dont on a besoin et la vitesse constatée.

     Il rappelle que l'ajout d'optimisations ne doit évidemment pas
casser
     le code existant ou introduire de nouveaux bugs, donc use Test, et
     mettre en place des tests de régression avancés.

     Il parle ensuite de techniques d'optimisations : comment trouver
*quoi*
     optimiser. Il conseille pour cela Devel::DProf et Devel::SmallProf
qui
     permettent respectivement de faire du profiling de manière globale
ou
     ligne par ligne. Il conseille de tricher avec Devell::DProf en
découpant
     une grosse fonction comportant plusieurs boucles imbriquées en
autant
     de sous-fonctions (en partant des boucles extérieures vers les
boucles
     intérieures).

     Il conseille ensuite d'utiliser Benchmark pour tester les
différentes versions
     d'un même code pour vérifier de manière expérimentale laquelle est
la
     plus rapide car l'intuition peut souvent s'avérer trompeuse (tr///
est souvent
     plus rapide qu'on ne le croit par exemple).

     Il montre ensuite comment on peut voir l'arbre des instructions
généré par
     Perl (-MO=Terse) et fait remarquer le coût des boucles. "Loops are
bad".
     Il montre sur un exemple comment remplacer une boucle basée sur un
     while et des regexp par pack().

     Quelques trucs en vrac :
      - il montre Devel::Size pour voir la taille mémoire des objets
      - il conseille d'utiliser des constructions comme /\G.../gc pour
les regexps
      - il rappelle l'emploi d'AutoLoader et d'AutoSplit

     Il parle maintenant de l'importation et rappelle que c'est un
mécanisme
     intrinsèquement lent puisque Exporter est écrit en Perl et utilise
eval "".
     Il conseille donc (côté module) de ne pas coder de grosses listes
@EXPORT
     et (côté utilisation d'un module) de n'importer que ce qu'on
utilise. Il donne un
     exemple avec POSIX.

     Conseil intéressant : il montre comment utiliser Memoize pour
stocker le
     résultat d'une fonction. Évidemment, c'est à réserver pour les
fonctions
     dont le calcul et non-trivial (et plutôt du type calculatoire; de
fait il donne un
     exemple avec une fonction de Fibonacci). Il indique que le cache
peut même
     être stockée sur disque.

     Quelques techniques générales d'optimisations :
      - éviter les constructions de chaînes de caractères
      - mettre le maximum de choses en dehors des boucles
      - écrire les petites fonctions en ligne
      - l'utilisation de sentinelles permet d'économiser certains tests
(grand classique)
      - trier moins de données; il donne un exemple où il transforme
grep /machin/ sort @list
        en sort grep /machin/ @list

     Sur l'utilisation des hashes, il conseille de vérifier la qualité
des clés de
     hashes, et éventuellement de les rendre plus courtes avec pack().

     Pour la transmission de données entre processus Perl il rappelle
qu'il est idiot
     de parser les données en Perl et conseille d'utiliser Data::Dumper
et eval ou
     Storable.

     Je crois qu'il y a eu une référence à Acme::Buffy pendant ce talk
:-)


* Mark-Jason Dominus - Tricks of the Wizards
     Je ne vais pas détailler son talk puisqu'il est disponible sur son
site web
         <http://perl.plover.com/class/YAPC-EU/>
     et que de plus il l'a écourté pour faire son talk Twelve Views,
qu'il avait fait
     à YAPC::Israel.


* Mark-Jason Dominus - Twelve Views
     Les slides de ce talk étaient aussi sur son site web mais je
n'arrive pas à
     retrouver où. Comme je les avais déjà lus je n'ai pas pris de notes.

     Dans ce talk, MJD nous parle de 12 points divers et variés sans
rapport
     particulier entre eux voire même sans rapport direct avec Perl.

     1. The coolest Perl project I ever did
         MJD nous explique comment pour un projet il a écrit un programme
         qui générait toutes les permutations possibles d'un objet
composé de
         triangles. Il avait obtenu 63 configurations différentes. Il
nous montre
         le résultat et nous met au défi de trouver lequel est en
double. Il explique
         ensuite comment il a conquis le coeur de sa bien-aimée grâce à
ça.

     2.  On forking and 'unnecessary' shell calls
         MJD décide maintenant de râler un peu contre les gens qui disent
         qu'utiliser system() ou les backtips c'est mal parce que ça
prendrait
         trop d'instructions. Il fait remarquer que certaines choses
sont plus
         compliquées à programmer en pur Perl qu'avec quelques commandes
         shell bien utilisées. Il rappelle que Perl est un langage de
glu et qu'un
         programme simple et lisible est préférable (et moins sujet à
erreur).

     3.  Should I release a new version every month?
         MJD décide maintenant de râler contre ceux qui lui écrivent en
lui
         demandant s'il a abandonné Text::Template parce qu'il n'y a pas
eu
         de version dans les N derniers mois. Il se demande pourquoi les
         gens ne semblent pas comprendre qu'il ne fait pas de nouvelle
         version parce que ce module est parfait. Il indique le coupable
de
         ce lamentable état d'esprit : Microsoft (le public est en
délire).

     4.  The failure of subclassing on CPAN
         Il s'interroge sur la raison qui expliquerait la répugnance des
         programmeurs à créer des sous-classes des modules disponibles
         sur le CPAN. Il prend là encore comme exemple Text::Template.
         Beaucoup de personnes lui demande de rajouter telle ou telle
         fonctionnalité et lui répond que ce serait tout aussi simple
pour
         eux de créer une sous-classe de T::T et d'ajouter la ou les
         fonctionnalités qu'ils veulent.
         Il suppose que cette répugnance provient d'une lacune dans la
         documentation : il faudrait que les auteurs de modules/classes
         indiquent une API qui devrait rester stable au fil des
versions, afin
         d'établir un genre de contrat moral avec les programmeurs.

     5.  Why I Hate strict
         MJD râle maintenant (il râle beaucoup dans ce talk ;-) contre
les
         gens qui disent aux newbies de mettre use strict sans leur
expliquer
         ce que cela signifie.

     6.  How not to ask for help from strangers
         Il explique comment il a reçu des mails curieux, comme un
étudiant
         allemand devant écrire un mémoire et lui envoyant un mail du
genre
         "pourriez-vous m'envoyer des informations sur votre système
légal aux
         USA. C'est très pressé car je dois terminer pour dans 2 moins.
Merci".
         Il se contient avec peine tellement c'est burlesque.

         Une note amusante : il se rend compte au milieu de sa
présentation
         qu'il a oublié de copier certains des fichiers et se prend des
404. Il
         cherche un peu, puis réclame un portable avec la connexion
réseau
         qui marche. Un type avec un portable sous Win se propose, mais
son
         réseau ne marche pas. MJD déclare forfait et passe au point
suivant.

     7.  How to progress
         Le conseil de MJD pour devenir meilleur (que les autres bien
sûr) : lire
         les livres que les autres ne lisent pas, et lire les sources.
ce dernier terme
         doit se prendre au sens général car ce conseil s'applique dans
tous les
         domaines, tant littéraire que philosophique, religieux, ou
éventuellement
         informatique. Dans ses slides je me souviens qu'il donnait
comme exemple
         qu'au lieu de lire les commentaires d'un type qui parle
d'Einstein, il vaut
         mieux lire Einstein directement.

     8.  Don't give up just because it's NP-complete
         MJD explique la théorie de la complexité. J'ai pas trop suivi
car j'ai déjà
         bouffé pas mal d'articles sur P/NP/coNP/RP/coRP et autres dans
le TGV.

     9.  On giving a man a fish
         Il explique en quoi il trouve que l'attitude des gens qui
répondent aux
         questions des newbies par un RTFM (ou par la version à peine
déguisée
         "perldoc perlfunc") est négative. Son conseil : donner la
réponse et
         indiquer où trouver des informations complémentaires.

     10.  Why Lisp will never win
         Heu, je confesse : je ne me souviens plus de ce qu'il a dit
contre Lisp.
         (Ou alors c'est qu'il avait sauté cette partie.)

     11.  A message for the Aliens
         MJD veut nous montrer un truc amusant qu'il a trouvé sur le web
: un
         type qui a réalisé plusieurs parodies du message envoyé en 1974
         vers l'amas globulaire M13 depuis le radio-téléscope d'Arecibo.
         (On peut trouver une version expliquée du message originel à
cette
         URL <http://amo.net/Contact/>, où il y a aussi une "réponse" ;-)
         Il montre plusieurs des dessins (qui sont très drôles) et
commence à
         discuter le plus sérieusement du monde des fautes d'orthographes
         et de représentation des dessins. Le public est mort de rire.

         Là encore lorsqu'il veut cliquer sur un des dessins MJD se rend
compte
         qu'il ne l'a lui non plus pas copié. Il réclame encore une fois
un portable.
         Quelqu'un lui donne un portable sous GNU/Linux. Ca marche !
Tonnerre
         d'applaudissements !
         MJD se connecte sur site et après avoir tapé un mot de passe
trouve enfin
         les fichiers qui lui faisaient défaut. Il affiche l'image qu'il
propose d'envoyer
         aux extraterrestres. Re-tonnerre d'applaudissements.

     12.  What are "strongly typed" languages?
         MJD se demande ce qu'est un langage "fortement typé". Il montre
les
         résultats de ses recherches sur le net qui donnent à peu près
ça :
           - "Ada est fortement typé, C ne l'est pas"
           - "C et Pascal sont fortement typés"
           - "les langages fortement typés comme C ..."
           - etc
         En bref, personne ne sait ce que c'est mais beaucoup de monde
croit dur
         comme fer à sa propre définition.


Sébastien Aperghis-Tramoni
  -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
-
Paris Perl Mongueu(r|se)s  => http://paris.mongueurs.net/mail.html