Comment réaliser le parallélisme avec Ruby MRI avec des threads liés aux E/S

La langue n’est pas seulement utilisée par les gens, mais même les sites Web l’utilisent. Le langage est l'un des principaux problèmes auxquels les programmeurs sont confrontés, surtout lorsqu'il s'agit de Ruby. Les performances offertes par Ruby peuvent être l'une des raisons pour lesquelles les programmeurs ne voudraient pas utiliser ce langage. En raison des plaintes concernant les performances de Ruby, cela montre seulement que le framework est en retard par rapport aux autres frameworks utilisés aujourd'hui par les programmeurs. Même si ces problèmes sont dus à Ruby, il est facile à utiliser.

La question sera toujours : comment atteindre le parallélisme avec l'IRM de Ruby ?

Pour répondre, la meilleure solution est d'avoir les threads liés 1/0. Les threads peuvent influencer le parallélisme observé aujourd’hui dans les processeurs. Le Ruby MRI est connu pour ne pas soutenir le parallélisme. Même si vous avez beaucoup de threads, avec Ruby MRI, un seul thread s'exécutera en permanence et c'est grâce à GIL.

Certaines déclarations indiquent que Ruby MRI n'aidera pas à atteindre le parallélisme et tout cela est dû à GIL, qui est responsable d'imposer des restrictions sur les threads. Pour cette raison, les gens pensent que Ruby est inutile et n’est pas d’une grande aide pour atteindre le parallélisme. Ces déclarations peuvent être suffisamment vraies si vous utilisez des opérations liées au processeur. Pourquoi? Lorsque vous utilisez les opérations liées au CPU, de bonnes performances ne seront jamais évidentes et auront toujours des performances faibles et tout cela est dû au fait que la planification des threads est gérée par l'espace utilisateur et que GIL joue un grand rôle puisque c'est celui qui limite le fils.

Contrairement à ces déclarations, les threads liés aux E/S sont ceux qui aident Ruby MRI à atteindre le parallélisme. La vitesse des threads liés aux E/S est limitée par les E/S trouvées dans les ordinateurs. Celui qui gère les threads liés aux E/S est l'interpréteur Ruby qui se trouve dans l'espace du noyau. Étant donné que l'interpréteur Ruby est situé à l'extérieur, les threads liés aux E/S peuvent s'exécuter librement puisqu'il n'y a pas de restrictions et pourront s'exécuter en parallèle car le GIL n'est pas présent. L'espace noyau est responsable de la planification des threads liés aux E/S, ce qui leur permettra de s'exécuter en continu sur de nombreux hubs.

Si vous souhaitez que vos threads s'exécutent et atteignent le parallélisme sans aucune restriction, le Ruby MRI avec des threads liés aux E/S est la meilleure option. Contrairement aux opérations liées au processeur, vous pouvez probablement rencontrer de nombreuses restrictions dans votre thread car GIL est présent. Quel que soit le nombre de threads que vous utilisez, si le GIL existe, un seul thread peut s'exécuter simultanément. Néanmoins, si vous utilisez le Ruby MRI avec des threads liés aux E/S, vos performances peuvent s'améliorer et atteindront certainement le parallélisme. De plus, si vous travaillez sur une tâche liée aux E/S, le Ruby MRI avec des threads liés aux E/S est fait pour vous car il peut s'exécuter en parallélisme et ne vous empêchera pas d'avoir plusieurs threads. N'oubliez pas que vos discussions doivent être en sécurité à tout moment.