Série d'articles
Ruby et Rust sont, en un sens, des langues opposées. Donc,
Je voudrais m'y attendre.
Par conséquent, je voudrais écrire un article sur la coopération entre Ruby et Rust en plusieurs parties. (Parce que c'est une personne qui ne dure pas longtemps, ça peut s'arrêter bientôt)
Pour la première fois, j'ai réfléchi au but de la coopération, alors que ce serait bien de coopérer.
Bien que j'ai une vie longue et élancée de Ruby, Rust reste un amateur pour toujours (ou plutôt, j'écris rarement des programmes en Rust). Je ne connais pas du tout le monde de la programmation système, et je souffre en premier lieu de la phobie du compilateur.
Lorsque j'écris un script en Ruby, je me demande souvent: "Pourquoi ne réécrire pas cette partie dans Rust pour la rendre plus rapide?"
Par exemple, la démo Helix [^ helix] a montré un exemple d'implémentation de blank?
D'ActiveSupport dans Rust pour améliorer de manière écrasante les performances [^ blank].
[^ helix]: l'un des mécanismes qui relie Ruby et Rust. https://github.com/tildeio/helix
[^ blank]: Bien sûr, la grande amélioration des performances concerne la méthode blank?
. L'application Rails entière n'explosera pas. Cela dit, vide?
Est exécuté plusieurs fois dans Rails, donc je ne pense pas que ce soit une bonne idée.
Cependant, c'est une illusion commune que "le remplacement de Ruby par un langage de programmation système (pas seulement Rust) le rendra plus rapide (n'importe quoi)". En prenant le traitement des chaînes comme exemple, les méthodes intégrées telles que «String # gsub» et «String # downcase» fonctionnent très rapidement en elles-mêmes. Même si un amateur réécrit le processus de combinaison de certaines de ces méthodes avec Rust, il n'y a pas de victoire.
"Ruby est lent", mais dans quel sens est-il lent? Les appels de méthode et les évaluations de bloc sont raisonnablement coûteux, donc si vous effectuez un processus qui combine un grand nombre d'appels de méthode dans un grand nombre d'itérations, il sera beaucoup plus lent que ce que vous avez écrit en C ou Rust. C'est souvent le cas. Dans un tel endroit, il peut y avoir lieu d'envisager une réécriture par Rust.
Ce que vous aimeriez attendre de l'accélération de Rust, c'est la programmation parallèle / parallèle. Rust préconise "Fearless Concurrency" [^ fc], et il semble que la programmation parallèle a un mécanisme qui rend difficile la couverture de bogues, et il semble que la parallélisation puisse être faite très facilement avec un traitement hautement parallèle [^ para]. ].
[^ fc]: C'est aussi le Titre du chapitre du langage de programmation Rust (TRPL).
[^ para]: Dans mon expérience de Rust proche de zéro, le temps d'exécution a été divisé par deux simplement en ajoutant un peu de parallélisation en utilisant rayon. était là.
C'est lié à l'histoire du désir de vitesse, mais n'est-il pas possible de réduire la consommation de mémoire en convertissant le traitement qui cause une très grande quantité de déchets dans Ruby en Rust? Un programme qui continue à s'exécuter, comme une application Web, aura fréquemment un garbage collection. Les performances peuvent s'améliorer si la fréquence est réduite.
Par exemple, l'analyse morphologique est susceptible d'être un processus dans lequel des déchets sont susceptibles de se produire. Ruby dispose également d'une bibliothèque d'analyse morphologique basée sur MeCab, Juman ++, etc., afin que vous puissiez facilement utiliser l'analyse morphologique. Cependant, même si vous souhaitez simplement extraire uniquement la nomenclature du texte, par exemple, une grande quantité de chaînes de caractères supplémentaires sera générée. Parce que les informations obtenues à partir de ces bibliothèques sont, par exemple, par morphologie (en utilisant MeCab comme exemple).
Est un assistant,Assistant de cas,Général,*,*,*,Mais,Géorgie,Géorgie
(L'onglet après "ga"). Si vous divisez cela par des tabulations et des virgules, vous pouvez créer un certain nombre d'objets String. La plupart d'entre eux sont inutiles. Ceux-ci deviennent des ordures. Donc, quand je compare les paroles de la partie avec «" nomenclature "» ... etc., je sens que cela semble inefficace [^ inefficace].
[^ inefficace]: Je ne sais pas si c'est vraiment inefficace à moins de le mesurer correctement.
Puisque Rust gère la mémoire sans utiliser le garbage collection, il peut être efficace si Rust est en charge de l'analyse morphologique et de l'extraction des informations nécessaires et de la transmission du résultat à un script Ruby. ..
Qu'en est-il autre que la performance?
Parfois, vous souhaitez utiliser certains des meilleurs outils et bibliothèques Rust de Ruby. Il est tout à fait naturel d'utiliser un logiciel C dans Ruby, et la plupart des soi-disant «bibliothèques d'extensions» sont probablement faites en C. L'écriture d'une bibliothèque d'extensions largement utilisée dans Rust est un obstacle majeur dans la mesure où elle nécessite un compilateur Rust à la destination de l'installation, mais c'est tout à fait concevable s'il s'agit d'un outil interne.
L'utilisation du logiciel Rust dans Ruby, même si ce n'est pas sous la forme d'une bibliothèque d'extensions, augmentera dans le futur.
Il est également possible d'utiliser Ruby de Rust.
Il arrive souvent que le processus qui peut être écrit de manière très concise en Ruby soit très gênant en Rust, C, C ++, etc. Il peut être possible d'écrire partiellement un tel traitement dans Ruby.
En fait, Rutie [^ rutie] semble avoir un mécanisme pour appeler du code Ruby du côté de Rust.
[^ rutie]: Un des mécanismes qui relie Ruby et Rust. https://github.com/danielpclark/rutie
Pour Ruby appelé du côté Rust, mruby peut également être un candidat. Référence: mruby-sys