Le langage Ruby disponible en version 3.0.0
Le 06 janvier 2021 à 09h10
2 min
Logiciel
Logiciel
Nouvelle version majeure pour le langage de développement libre, créé dans les années 90 par Yukihiro Matsumoto avec une très forte orientation objet (toute donnée est un objet, même les types primitifs).
Depuis la sortie de Ruby 2.0 en 2015, le développement de la branche 3.0 avait commencé, avec un accent spécifique sur les performances. Ce qui fait dire à Matsumoto que Ruby 3.0 est trois fois plus performant que son prédécesseur. Ce chiffre est obtenu uniquement en JIT, mais la hausse reste quand même sensible en machine virtuelle (environ 40 %).
Actuellement, l’envolée des performances en JIT se fait surtout sur les charges de travail dans lesquelles quelques méthodes sont appelées très souvent. Ruby 3.1 s’attaquera aux charges contenant un plus grand nombre de méthodes.
Parmi les autres nouveautés importantes de Ruby 3.0, signalons Ractor, fonction expérimentale prévue pour fournir une exécution parallèle sans trop s’inquiéter de la thread safety. Il s’agit d’une abstraction de concurrence de type Actor-model.
On y trouve aussi Fiber Scheduler – qui permet l’interception des opérations bloquantes – des améliorations pour l’analyse statique (dont le langage RBS), ou encore une meilleure correspondance des modèles à une ligne.
Le 06 janvier 2021 à 09h10
Commentaires (12)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 06/01/2021 à 09h37
Question de béotien. En terme simple, ça veut dire quoi JIT ? Il y a bien cette page Wikipédia mais c’est un peu trop technique pour moi. En quoi est ce que ça diffère d’une compilation “classique” ?
Le 06/01/2021 à 10h42
si je ne m’abuse : en compilation classique le code est compilé (transformé depuis un langage de haut niveau en binaire exécutable) une fois pour toute au moment de la distribution, ce même binaire étant utilisé partout.
Le JIT (Just In Time) propose une compilation à la volée au moment de l’exécution. On distribue et exécute directement le code source, ça facilite les modifications. Mais on se prend la compilation à chaque exécution, même si le script n’a pas changé.
Je prendrai avec plaisir toute correction si j’ai dit une bêtise :-)
Le 06/01/2021 à 11h07
Je me permets d’apporter quelques précisions… J’aime étaler ma culture :-)
En compilation classique (“ahead of time”), le developpeur fournit un package spécifique pour chaque architecture qu’il veut supporter (il doit créer un package différent pour X86, X84, ARM, etc.) Le package contient le code qui sera exécuté sur cette architecture, et ce code sera le même pour tous les appareils où le package est installé, et ne peut donc exploter que le socle commun à toutes ces architectures (sauf chipotages)
En compilation JIT, le développeur fournit un unique package, le même pour toutes les architectures. Le package contient soit une représentation intermédiaire (bytecode java, IL sous .Net, le code source en Python). Lorsque l’utilisateur exécute l’application, la représentation intermédiaire est compilée pour la plateforme au fur et à mesure des besoins (d’où le nom….) À noter que le résultat de ce JIT peut être soit caché pour être réutilisé dans une exécution ultérieure, soit jeté quand l’application se termine (auquel cas il faudra recommencer à chaque fois).
L’avantage du JIT est que la compilation finale peut dépendre finement des capacités de la plateforme : le même code intermédiaire pourrait fort bien être compilé différemment sur un Mac Pro que sur un Mac Air, qui ont certes la même puce M1, mais l’un a 7 coeurs GPU, l’autre 8, donc un même algo pourrait être parallélisé différemment (bon, c’est un cas extrême).
Le 06/01/2021 à 10h36
Just In Time.
En gros, tu prends un langage (interprété comme PHP/Python, précompilé comme Java), tu le traduit en langage machine à la volée, et éventuellement en optimisant au gré des exécutions.
Le 06/01/2021 à 13h05
Merci !!
Je me posais aussi la question !
Le 06/01/2021 à 13h25
Si je dit pas de bêtise le php est de plus en plus précompilé aussi.
Le 06/01/2021 à 15h08
Non il est pas précompilé, il peut garder une version compilé en cache, donc si le fichier ne change pas, pas besoin de le recompiler, ce qui passe d’une exécution d’un fichier en quelques milliseconde (le temps de la compilation) et quelques micro secondes. J’ai mis de trace sur l’autoloader, et les gains de temps sont non négligeable sur une application assez lourde.
Le 06/01/2021 à 14h15
Je t’avoue que je n’en fait plus depuis au moins 10 ans … et les choses évoluent
Le 06/01/2021 à 16h07
Il y a un très bon article sur le JIT sur zestedesavoir : https://zestedesavoir.com/articles/1837/la-compilation-just-in-time-un-exemple-et-des-consequences/
Le 06/01/2021 à 17h39
S’il fallait savoir ce que veulent réellement dire les mots techniques, il n’y aurait pas beaucoup d’informaticiens
Tu lâches juste “JIT” quand tu veux faire bien dans une discussion, genre “ah ouais PHP 8 ça déchire, c’est JIT maintenant, les sites vont aller plus vite !” (ce qui est faux, mais comme personne comprend rien, ils croient que ça va plus vite avec JIT qu’avec un Apache bien configuré avec les extensions qui vont bien comme Zend, 99% des informaticiens n’y connaissent rien alors ils croient que parce que c’est JIT le code va plus vite).
Le 07/01/2021 à 14h04
Ah, c’est sûr que sur un langage hautement dynamique, le JIT est le plus souvent futile. Dans un langage statiquement typé (exemple Java), quand tu vois “a+b” tu connais le type de A et B avant d’avoir exécuté le code, et ce type sera toujours le même, donc tu peux générer le code le plus efficace. Dans un langage dynamique (exemple Javascript) quand tu vois “a+b” tu ne sais pas si a et b sont des entiers, des strings ou des matrices, et ça peut changer d’une fois à l’autre; tu passes ton temps à vérifier les types, et sauf cas particulier, un JIT ne fera pas tellement mieux qu’un interpréteur bien ficelé.
Le 06/01/2021 à 17h40
permets-toi, surtout ! J’ai essayé d’apporter un éclaircissement basé sur mon expérience, il était largement ouvert à compléments ou corrections !