HardShooter a écrit 121 commentaires

En revanche faudrait comparer avec Numpy sur PyPy

Je chipotte mais un JIT a trace ne fusionne pas les traces, les traces sont attachées entre elles.

Aussi si tu veux décrire le JIT faut aussi décrire ce que c'est une Guard car il ne faut pas oublier que le JIT ne compile qu'un seul chemin d'exécution, par exemple si on trace un "if" et que la partie "True" est emprunté, quand on compile il faut un moyen de dire "si le if est Faux, revenir a l'interpréteur", c'est ce qu'on appelle une Guard et c'est assez important.

Non du point de vu utilisateur, a la place de faire "python monscript.py" tu fais "pypy monscript.py" et tu utilise PyPy (sans compiler ton script vers du code natif)

Comme c'est confus pour pas mal de monde je vais faire un explication globale:

PyPy est écrit dans un sous-ensemble de Python (appelé RPython) sur lequel il est possible de réaliser de l'inférence de types, PyPy peut donc être exécuté au dessus d'un interpréteur Python (principalement pour debugger) mais aussi compilé vers du C (ou vers du bytecode Java, ou vers du bytecode CLI).

Les principaux avantages sont :
- Code écrit en (R)Python (avec une vitesse proche du C)
- La mémoire est gérée automatiquement dans l'interpréteur, on peut choisir le Garbage Collector à la compilation.
- Le compilateur juste-à-temps est automatiquement généré a partir de l'interpréteur (ce qui fait que le compilateur couvre toujours 100% du langage)

Le support des extensions C est lent car l'API C est trop proche du modèle objet de CPython et pas assez de celui de PyPy, en plus le compilateur juste-à-temps ne peut pas optimiser du code C.

Parce que Python écrit en Python c'est logique, et en plus la chaîne d'outils permet de faire des choses qui n'ont jamais été fait avant (tu peux implémenter rapidement un langage dynamique, avoir un garbage collector sans avoir a l'écrire, avoir un JIT sans avoir a l'écrire, pouvoir tout tester sans compiler).

LLVM avait déjà été tester et à l'époque les gens en charge du projet on passer plus de temps a debugger LLVM qu'a écrire un JIT pour CPython.

L’implémentation est aussi beaucoup plus flexible, je te renvoie a la doc mais les espaces d'objets sont par exemple quelque chose qu'il serait difficile d'implémenter.

Pour l'instant PyPy utilise un Global Interpreter Lock comme CPython mais il est possible que demain il utilise une STM pour avoir du vrai parallélisme, essaye d'implémenter ca sur CPython.

Essaye de changer le Garbage Collector de CPython...

CPython a été créer en 1990 avec les connaissances de l'époque (si on est gentil), et n'a pas été conçu pour évoluer, l'avantage c'est que c'est un interpréteur très simple mais qu'il est très compliqué de le mettre au goût du jour.

Pourtant, j'ai touché à l'interpréteur et c'était un joli bordel.

J'ai été capable d'implémenter 2 fonctionnalités de Python 3 dans PyPy sans avoir toucher a un interpréteur avant.

Mais quand le build réussit et que l'exécutable produit crashe, c'est le pompon : 30-60 minutes de rebuild par itération

L’exécutable a peu de chances de crasher car on le fait tourner d'abord au dessus d'un interpréteur Python avant le build pour vérifier que tout fonctionne.

il est difficile de rentrer dans le code de PyPy (touffu, très peu documenté ni commenté, y compris RPython lui-même)

C'est vrai pour la chaîne d'outils mais pas pour l’interpréteur (et actuellement les développeurs CPython touchent à l’interpréteur, pas à GCC)

le système de build peut rendre fou (traduire l'interpréteur en code natif prend 30 à 60 minutes, et il n'y a pas de traduction incrémentale)

Il n'y a pas besoin de traduire l’interpréteur la plupart du temps, seulement pour savoir si le code peut être traduit, et le build crash dans les 5-10 premières minutes rarement après

Que CPython (je crois que ça pourrait être améliorer mais que ce n'est pas une priorité pour l'instant)

La chaîne d'outils utilise "l’interpréteur en lui même" pour créer des Control Flow Graphs (à défaut de traduction) à partir du code RPython

Concernant ton premier point, le JIT pourra bientôt être activé sur ARM et PPC. Concernant le 2e, si tu désactive le JIT, PyPy consomme moins de mémoire que CPython et est un peu plus lent.

Ça a existé sous le nom d'Unladen Swallow (un fork de CPython) mais LLVM était trop buggé et limité a l'époque (je sais pas maintenant) et le code était lui aussi assez complexe, le but d'Unladen Swallow était d'être 5x plus rapide que CPython sur leurs benchmarks, PyPy le fait déjà.

PyPy a aussi un garbage collector bien plus performant que CPython et l'implémenter dans CPython serait un bordel monstre.

Certains développeurs de CPython pensent que l'architecture de PyPy est trop complexe et qu'il est difficile d'y contribuer.

Il y a aussi le problème des extensions C.

Sinon, tout le monde pourrait passer sur PyPy et il n'y aurait qu'une branche :D

Ces deux composants sont indépendants

Pas vraiment puisque la chaîne d'outils utilise l’interpréteur

Il y aura surement un autre appel au don pour avoir une Software Transactionnal Memory dans PyPy (ce qui permettra d'avoir du vrai parallélisme en Python)

/boot n'a pas du tout besoin d'etre monté au boot alors avoir une dépendance dessus...

Non je pense à http://llvm.org/docs/SystemLibrary.html je suis pas sur que ca ai été concu pour etre utilisé en dehors de llvm lui meme mais j'ai pas chercher non plus

Pour palier a ce soucis llvm a crée une bibliothèque standard indépendante mais comme thunderbird ne l'utilise pas faudrait tout patcher...

Oui enfin ça n'a pas de rapport LLVM est la pour exécuter du bytecode et l'optimiser avec le JIT, si on ajoute des bibliothèques autour on peut très bien avoir LLVM comme backend.

C'est ce que fait unladen swallow pour python ou même mono pour .NET (c'est expérimental mais ils ont bien un backend LLVM)

Bah c'est toujours possible de construire une VM autour de llvm comme l'a prouvé vmkit faudrait juste un truc indépendant des 2 gros ténors

C'est vrai qu'il manque une plateforme (avec garbage collector toussa toussa) libre (dans le processus de développement) qui pourrait concurrencer .NET et Java

Le futur est peut-être vers une extension de LLVM en lui rajoutant un garbage collector et sûrement d'autre chose que j'oublie (généricité ?)

En Scala tu peux avoir des interfaces a la volée (comme sur la méthode inTheForest)

class Duck {
def quack = println("Quaaaaaack !")
def feathers = println("The duck has white and gray feathers.")
}

class Person {
def quack = println("The person imitates a duck.")
def feathers = println("The person takes a feather from the ground and shows it.")
}

def inTheForest(duck: { def quack; def feathers }) = {
duck.quack
duck.feathers
}

Des interfaces implicites comme go :
type Duck = { def quack; def feathers }

def inTheForest(duck: Duck) = {
duck.quack
duck.feathers
}

Ou des traits explicites (equivalent du duo interface/classe abstraite de Java)

Oui il y a un GIL et il n'est pas prévu de le retirer dans un futur proche

C'est pas breveté par Gnome la suppression de fonctionnalités ?