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

[Michel Rodriguez]

Encore un mail, avec des precisions sur Parrot

Michel Rodriguez
Perl & XML
http://www.xmltwig.com

---------- Forwarded message ----------
Date: Tue, 29 Jul 2003 21:36:03 +0200
From: "[iso-8859-1] Stéphane Payrard" <stef at payrard.net>
To: Paris.pm <paris-pm-list at pm.org>
Subject: Re: [ppm] YAPC::Europe::2003 (3)

On Tue, Jul 29, 2003 at 04:42:15PM +0200, Sébastien Aperghis-Tramoni wrote:
> Vendredi 25 juillet

Quel corrections et amplifications.

>
> * Dan Sugalski - Parrot in a nutshell
>     Dan présente Parrot en commençant par expliquer en quoi
>     l'interpréteur Perl5 actuel est un vrai merdier. En effet, Perl5
>     est le résultat de 9 ans de patches successifs pour ajouter un
>     ensemble de fonctionnalités qui n'avaient pas été prévues au
>     départ car cela n'existait pas à l'époque : on pense tout
>     particulièrement au support des threads et d'Unicode.
>
>     Des tas de personnes ont donc proposé des patches en disant
>     "cela ne coûte qu'1% du temps d'exécution". Mais les patches
>     étant acceptés, les pourcentages se sont additionnés pour
>     ralentir de manière sensible l'interpréteur Perl. (Raison pour
>     laquelle Nick Clark indiquait qu'un moyen potentiel d'accélérer
>     un programme était d'utiliser une ancienne version de Perl.)
>
>     Perl6 se base sur une machine virtuelle (VM) totalement nouvelle,
>     Parrot. Cette machine virtuelle a été conçue en utilisant les
>     dernières avancées en matière des techniques de VM, de
>     théorie de compilation et de conception des CPUs (ces domaines
>     étant liés). Le projet est ambitieux mais on espère ainsi que
>     cette VM évoluera de manière plus douce sur la décade à venir.

[snip]
>
>
> * Leopold Tötsch - Of Ops and MOps
>     Dans un anglais quelque peu hésitant, Leo nous explique les
>     bases de la programmation en Parrot.
>
>     On peut d'ores et déjà programmer en PASM, ou Parrot
>     Assembler, qui est un assembleur (en fait c'est plutôt un
>     macro-assembleur) dont la syntaxe semble assez facile.
>     Lors de l'exécution, l'assembleur est convertit en PIR,
>     Parrot Intermediate Representation Language, qui est
>     ensuite exécuté.


                                                 --> génération
                                                     exécutable
Langage de haut niveaux --> PIR --> PASM --> PBC --> NRJIT ---->  interprétation/exécution
                                                 -------------->

NRJIT est l'acronyme que j'invente pour Not Really JIT

En fait les formats sont les suivants:

     PIR: Parrot Intermediate Representation Language. C'est un
           assembleur à base de registres typés qui gère aussi
           les espaces de noms. Les registres sont de types:
           entiers, numériques, chaînes et PMC, pour Perl Magic
           Cookie. PIR propose un nombre illimitée de registre
           appelés registres symboliques.

           IMMC (Intermediate Code Compiler for Parrot, maitenant
           une passe de Parrot) transcrit ça en PASM en passant
           de la fiction du nombre illimité de registres à la
           "réalité" de nombre effectif de registre faisant
           l'allocation avec un algorithme à base de couleurs qui
           représentent les registres réels. A un instant donné,
           deux registres symbolique ne peuvet être affecté au
           même registre réel donc ne peuvent pas avoir la même
           couleur. Quand il y a trop de registres symboliques,
           PIR génère des instructions PASM de gestion de
           débordement dans un tableau pointé par un registre à
           cet effet.

     PASM:

          PASM est le vériable macro-assembleur de Parrot au sens
          qu'une fois les macros expansées il y une bijection
          entre les instructions PASM et les instructions
          binaires de bytecode générées. Mais maitenant que IMCC
          est opérationnel, il n'y a aucune raison de travailler
          à ce niveau. Sauf quand on débugge avec pdb, le parrot
          debugger.

    PBC:

         Parrot Bytcode. Format portable. Il est mappé (mmmap() en mémoire
         après quelque retouches (dont l'endianness) et
         génération de code natif pour les opcodes
         supportable/és dans une architecture donné. Différentes
         instances de parrot utilisant le un-core du même type du même PBC
         devraient partager le BPC mappé en mémoire. Je sais pas si c'est vrai
         aujourd'hui.


>
>     Leo présente ensuite quelques points qui permettent à Parrot
>     d'être très rapide :
>
>     - Parrot est une machine à registre, c'est-à-dire que tant la VM
>       que le langage d'assembleur considère qu'on a beaucoup de
>       registres disponibles, ce qui simplifie la vie du programmeur et
>       est facile à optimiser en aval (par aliasing de registres par
>       exemple). La VM ressemble donc à un processeur RISC (genre
>       PowerPC ou Sparc) mais pas à un processeur Intel ou AMD.
>
>     - les PMC (Parrot Magic Cookies) ont une taille de 32 octets
>       (là je dois reconnaître qu'il m'a un peu embrouillé et je ne
>       pas trop compris ses arguments, mais une comparaison avec
>       les vrais CPUs indique qu'une taille fixe égale à un multiple
>       entier de mots machine permet de se simplifier la vie lors des
>       calculs d'adresses (là encore voir l'opposition entre les CPUs
>       RISC et x86)).

Plus que de calcul d'adresses en soi avec les contraintes
d'alignement que cela suposse, il s'agit surtout d'optimisations
pour le DOD et le GC qui n'ont pas encore l'imprimatur de Dan.
DOD et GC acronymes de Garbage Gollection et Dead Object
Detection. Pour les pros du GC, la distinction (que je n'ai pas
comprise) n'est pas celle entre les deux passes "mark" et "sweep"

Passer de la gestion de la mémoire type comptage de référence
(Perl5) à celui d'un véritable ramassage de miettes a l'effet
souhaité une optimisation optimals des caches. Pour ce faire, Leo
casse les PMCs en deux parties. Les premières parties des PMC
sont allouées dans la même zone, ce qui fait que le GC utilise
mieux les caches du processeur (réel). Mais le coût à payer est
une indirection supplémentaire pour accéder les données allouées
par le PMC.

Le choix est délicat (couramment implémenté par un #ifdef) car il
ne faut pas optimiser indûment le collecteur au détriment du
mutateur. Ce dernier étant dans la terminologie GC le programme
de l'utilisateur avec sa sale propension à tout changer dans le
dos du collecteur.

>
>     - DOD (Dead Object Detection)
>
>     - COW (Copy-on-Write) est un mécanisme qui permet de retarder
>       les opérations d'allocations mémoire au pus tard. L'exemple
>       typique est :
>           $foo = "hello world";
>           $bar = $foo;
>       Habituellement, le contenu de $foo est copié dans un nouvel
>       espace mémoire qui sera pointé par $bar. Avec COW, $bar
>       pointe vers l'espace mémoire de $foo, et ce n'est que si on
>       modifie la valeur de l'une ou l'autre des variables qu'une
>       nouvel espace mémoire est créé.

C'est encore plus fort que ça, puisque ça marche aussi pour les
substrings, les tableaux et sous tableaux. Presque tout est à base
de listes de "morceaux" chaînés sujets à COW. Outre le COW, cela
permet de faire des insertions et effacements au milieu d'un
tableau sans avoir à décaler le reste du tableau dans la mémoire.
Je crois que le contenu d'une chaîne est (encore) en un morceau.
Tout est à base de COW dans Parrot.

Le COW est absolument nécessaire pour la gestion des
continuations qui sont des contextes d'exécution. Ils sont amenés
à diverger et l'implémentatin en terme de COW permet de les faire
diverger morceau par morceau au lieu de copier entièrement les
contextes ou gérer la divergence à la main.

Toutes ces optimisations ne sont pas nouvelles mais n'ont guère
été utilisées jusqu'ici que dans les mondes lisp et assimilés.





>       Cette fonctionnalité semblait particulièrement intéresser
>       certaines personnes du public qui avait posé la question à
>       MJD lors de son talk "Tricks of the Wizard". Le mécanisme
>       sera par la suite mis en scène par Nick Clark lors de son
>       lightning talk, comme l'a déjà décrit Mirod.
>
>     Leo expose ensuite quelques uns des différents run cores
>     disponibles dans Parrot. Si j'ai bien compris, les run cores sont
>     les coeur d'exécution de Parrot, mais comme ils n'étaient pas sûr
>     de savoir quel mécanisme serait le plus efficace, ils ont développé
>     plusieurs run cores : Fast Core, Goto Core, Slow Core, et des
>     combinaisons. Leo montre le Fast Core avec du code C :
>         while(PC) {
>             PC = ((INTERP->op_func_table)[*PC])(PC,INTERP);
>         }
>     Je crois que la majeure partie de la salle est restée dubitative
>     face à ça...

Je suis largué sur ce coup là.

>
>     Leo explique ensuite que Parrot dispose d'un sous-système JIT
>     (Just-In-Time) disponible pour plusieurs architectures (x86,
>     PowerPC, Sparc, ARM, Alpha).
>         Pour rappel, un système JIT (aussi dit de recompilation
>         dynamique), permet de transformer le bytecode en code
>         natif pour le CPU de la machine hôte. C'est ce qui permet
>         à Java d'avoir des vitesses d'exécution à peu près acceptables.
>     Leo nous montre le résultat d'un benchmark qu'il avait lancé au
>     cours de son talk; c'est un truc calculatoire écrit en Perl et en
>     Python. Les temps d'exécution sont lamentables, à peine 2 ops
>     par seconde en Perl et 1 op par seconde en Python. "Times are
>     rounded up!" précise Leo. Il exécute le même en Parrot : quelques
>     secondes, soit presque 800 ops par secondes (son PowerBook
>     tourne à 800 MHz..)
>
>     Après cette démonstration, Leo conclut sur le système JIT en
>     indiquant que comme a pu le constater, on peut arriver à exécuter
>     jusqu'à 1 instruction Parrot par cycle CPU ! Évidemment, c'est
>     surtout valable pour les instructions "simples" (ou du moins
>     disponibles dans le CPU), mais c'est néanmoins assez
>     impressionnant.
>
>     Sa présentation terminée, quelqu'un dans le public demande
>     à Leo de montrer qu'est-ce qu'il utilise pour ses "slides" (du
>     texte affiché dans un terminal qui efface l'écran et défile quand
>     il appuie sur une touche) : "Parrot of course!". Il montre le code
>     assembleur Parrot qu'il a utilisé pour son talk, qui doit faire
>     moins d'une cinquantaine de lignes. Nouvelle salve
>     d'applaudissements.

A propos du JIT et comme indiqué sur un des slides de Dan par un
TLA (Three Letter Acronym) que j'ai oublié : ce n'est pas
vraiment du JIT (Just In Time) puisque la génération du code
natif est faite avant l'exécution.

Et pour finir, news encore chaude, il est maintenant possible de
générer un exécutable (qui doit probablement contenir tout le
run-time).


Note: le rapport hebdomadaire de pdcauley commence par les enchères
YAPC.

   Welcome to another in the ongoing series of Perl 6 summaries in which
    your faintly frazzled summarizer attempts to find a native speaker of
    Esperanto to translate this opening paragraph in honour of the huge
    amount of money (1371 Euros) raised for TPF during the YAPC::Europe
    auction, when the official language of both London.pm and Paris.pm's
    websites were auctioned off as one lot. Somewhat to the surprise of
    everyone, the winning bid was for Esperanto. As Jouke Visser just
    commented on IRC, the price was well worth paying just to see the looks
    of panic on the faces of Mark Fowler, Leon Brocard and other London.pm
    worthies as the price of keeping the website English (and changing
    Paris.pm's website to English in the process) shot up beyond the reach
    of their collective pocket.

pdcauley était à YAPC. Quelqu'un peut me le décrire que je
mette une tête sur son nom?

Dans le BOF parrot, je me suis rencu compte que la communication
entre Dan et Leo etait quelquefois difficile. pdcauley se
souvient de l'échange de parole le plus significatif:

 Dan: I'm really bad at reading my mails Leo: You should at least read
    *my* mails Everyone: Hear! Hear! (or words to that effect)

Leo codant plus vite que son ombre, Dan ne suis pas toujours et la
chose codée n'est pas toujours congruente avec ses cogitations présentes
c'est à dire ses spécifications à venir.

( $a = "Il y a-t'il vraiment un seul Leon" ) =~ s/n$//  ; print "$a\n"

En tout cas, c'est la première fois (je crois) que Dan rencontre Leo
et on a tous constaté Leo existe réellement.

>
>
> Sébastien Aperghis-Tramoni

--
 stef
-
Paris Perl Mongueu(r|se)s  => http://paris.mongueurs.net/mail.html