Discussion :

[Flyable]

Bonjour communauté Developpez !


Suite à l'article sur Pyston que j'ai eu la chance de lire sur ce site, j'ai pensé qu'il pourrait être intéressant de vous présenter le projet sur lequel je travaille!

Je suis heureux de vous présenter Flyable ; un compilateur anticipé (ahead-of-time compiler) qui lit le code Python, et le transforme en code machine ultra performant qui donne des performances qui vont de 10 à 70 fois supérieurs selon nos micro-benchmarks comparé à Python. Flyable permet enfin à Python de compétitionner dans le cercle des languages performants!

J'ai ici un vidéo d'une courte démonstration (1 min) de Flyable à l'oeuvre (désolé pour le vidéo en anglais):
https://www.loom.com/share/ed55eb4bf...d4443bdb130fc3


Nous ouvrons présentement les enregistrements à la beta privée, pour permettre à plusieurs développeurs d'utiliser Flyable dans les prochains jours.


Rendez-vous sur www.flyable.dev pour s'enregister à la bêta et profiter d'un Python performant !

Merci beaucoup !
N'hésitez pas à poser vos questions ici !

[LittleWhite]

Bonjour,

C'est intéressant. Comparé à Cython/pypy ou des trucs du genre, ça donne quoi ?

[Flyable]

Bonjour,

C'est intéressant. Comparé à Cython/pypy ou des trucs du genre, ça donne quoi ?

Comparé à Pypy, les micros-benchmark nous indiquent que nous sommes dans les sphères de 5x plus rapide. Naturellement, Pypy étant plus lourd que l'implémentation officiel, Flyable créent des programmes qui sont largement plus léger à exécuter.

Pour Cython, je vais devoir revalider je n'ai plus les chiffres avec moi (Flyable était plus vite). Il est intéressant de mentionner que Cython nécessite des modifications/ajouts majeurs de code pour vraiment aller chercher de bonnes performances, alors que de son côté Flyable s'occupe de faire ce sale boulot avec différentes validations durant la compilation. La compatibilité d'un code Python existant est donc assez faible avec Cython alors que c'est tout l'inverse pour Flyable. Aussi j'aimerais mentionner que comparativement à Cython, Flyable ne cible pas le C comme cible de compilation. Il génère directement du code machine.

Edit: J'aimerais ajouter:
Pour comparer à Numba, nous sommes entre 1.15x et 2x plus rapide que Numba en micro-benchmarks. Encore une fois, la compatibilité du code est bien plus haute pour Flyable.



J'espère que j'ai répondu à vos questions ! (Je vais tenter de vous revenir avec le chiffre pour Cython)

[LittleWhite]

Merci beaucoup pour ces informations et félicitations pour votre produit. Sur le papier, c'est impressionnant.
Dans la vidéo, on a du mal à voir, comment cela se passe ? Vous générez un exécutable et celui-ci est inévitablement compatible qu'avec un seul système ? Votre processus de compilation permet de détecter les erreurs de types ou autres, dans le code ?

[Flyable]

Merci beaucoup! En effet, je n'ai pas été dans les détails du fonctionnement. Je suis en revanche très content de plonger dans le sujet !

Vous générez un exécutable et celui-ci est inévitablement compatible qu'avec un seul système ?

Exactement. Présentement nous supportons Windows 64 bit (X86). Nous avons avec succès rouler des démos par le passé qui fonctionnait aussi sur Mac et Linux. Nous supporterons bientôt l'architecture ARM.
À savoir que si vous voulez rouler sur plusieurs système, nous avons réussi dans une itération passée à faire en sorte que le compilateur génère du WASM qui s'éxécute sur un navigateur web. Une fonctionnalité dont nous poursuivrons le développement dans un avenir proche.

Votre processus de compilation permet de détecter les erreurs de types ou autres, dans le code

En plein dans le mille ! En fait c'est une sorte d'hybride. Les attributs de classe ainsi que le typage à l'intérieur des tableaux nécessite de se faire assigner typage constant . En cas d'incompatibilité, Flyable montre une pile d'appelle suite à la compilation avec les deux cas incompatibles. Le développeur peut donc alors repérer rapidement lequel des deux cas et erroné et appliquer la correction nécessaire.

À noter que en revanche, les arguments, variables, type de retour vont s'adapter en fonction des appels effectués. Donc une fonction peut être utilisée avec un nombre illimité de types différents sans jamais causer de soucis. Si jamais un typage rend une fonction erroné (à cause d'un attribut inexistant par exemple), alors un erreur apparaîtra avec le call-stack permettant ainsi de re-tracé le problème.


J'espère que ça répond à vos interrogations !
Merci beaucoup !

[LittleWhite]

Merci pour les réponses !