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.
Commentaires (12)
#1
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” ?
#1.1
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 :-)
#1.2
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).
#2
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.
#2.1
Merci !!
Je me posais aussi la question !
#2.2
Si je dit pas de bêtise le php est de plus en plus précompilé aussi.
#2.3
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.
#3
Je t’avoue que je n’en fait plus depuis au moins 10 ans … et les choses évoluent
#4
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/
#5
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).
#5.1
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é.
#6
permets-toi, surtout ! J’ai essayé d’apporter un éclaircissement basé sur mon expérience, il était largement ouvert à compléments ou corrections !