Wie erreicht man Parallelität mit Ruby MRI mit I/O gebundenen Threads

Die Sprache wird nicht nur von Menschen verwendet, sondern auch von Websites. Die Sprache ist eines der Hauptprobleme, mit denen Programmierer konfrontiert sind, insbesondere wenn es um Ruby geht. Die Leistung, die Ruby bietet, kann einer der Gründe sein, warum Programmierer die Sprache nicht verwenden wollen. Die Beschwerden über die Leistung von Ruby zeigen nur, dass das Framework gegenüber anderen Frameworks, die heute von Programmierern verwendet werden, ins Hintertreffen geraten ist. Auch wenn diese Probleme wegen Ruby aufgetreten sind, ist es einfach zu benutzen.

Die Frage wird immer sein, wie kann man mit Rubys MRI Parallelität erreichen?

Die beste Lösung ist, die 1/0 gebundenen Threads zu verwenden. Die Threads können die Parallelität beeinflussen, die in den heutigen Prozessoren zu beobachten ist. Ruby MRI ist dafür bekannt, dass es die Parallelität nicht unterstützt. Auch wenn Sie viele Threads haben, wird mit Ruby MRI nur ein Thread kontinuierlich ausgeführt, und das liegt an GIL.

Es gibt Aussagen, die besagen, dass Ruby MRI nicht dazu beiträgt, Parallelität zu erreichen, und dass dies auf GIL zurückzuführen ist, die für die Auferlegung von Einschränkungen für Threads verantwortlich ist. Aus diesem Grund denken die Leute, dass Ruby nutzlos ist und keine gute Hilfe bei der Erreichung von Parallelität darstellt. Diese Behauptungen mögen wahr sein, wenn Sie CPU-gebundene Operationen verwenden. Aber warum? Wenn Sie die CPU-gebundenen Operationen verwenden, werden Sie nie eine großartige Leistung sehen, sondern immer eine niedrige Leistung haben. Das liegt daran, dass das Thread-Scheduling vom Userspace gehandhabt wird und die GIL eine große Rolle spielt, da sie die Threads begrenzt.

Im Gegensatz zu diesen Aussagen sind die E/A-gebundenen Threads diejenigen, die dazu beitragen, dass Ruby MRI Parallelität erreicht. Die Geschwindigkeit der E/A-gebundenen Threads wird durch die E/A in Computern begrenzt. Die I/O-gebundenen Threads werden vom Ruby-Interpreter verwaltet, der sich im Kernelspace befindet. Da sich der Ruby-Interpreter außerhalb befindet, können die I/O-gebundenen Threads frei laufen, da keine Einschränkungen vorhanden sind, und sie können parallel laufen, da die GIL nicht vorhanden ist. Der Kernel-Space ist für die Planung der E/A-gebundenen Threads verantwortlich, so dass diese kontinuierlich auf zahlreichen Hubs laufen können.

Wenn Sie möchten, dass Ihre Threads ohne Einschränkungen laufen und Parallelität erreichen, ist das Ruby MRI mit I/O-gebundenen Threads die beste Option. Im Gegensatz zu den CPU-gebundenen Operationen, können Sie wahrscheinlich eine Menge von Einschränkungen in Ihrem Thread, weil GIL vorhanden ist. Egal, wie viele Threads Sie haben, wenn die GIL vorhanden ist, kann nur ein Thread gleichzeitig laufen. Wenn Sie jedoch das Ruby MRI mit E/A-gebundenen Threads verwenden, kann sich Ihre Leistung verbessern und Sie werden definitiv Parallelität erreichen. Auch wenn Sie an einer I/O-gebundenen Aufgabe arbeiten, ist das Ruby MRI mit I/O-gebundenen Threads das Richtige für Sie, da es parallel laufen kann und Sie nicht daran hindert, mehrere Threads zu haben. Denken Sie nur daran, dass Ihre Threads zu jeder Zeit sicher sein sollten.