Il n'empêche que l'implémentation de YARV fait qu'à un instant donné un seul thread Ruby peut s'exécuter, il y a un "Big Interpreter Lock" comme je l'ai dit dans mon message (l'intérêt d'avoir plusieurs threads dans ce cas est d'utiliser l'outillage de l'OS, de faire tourner des threads C en parallèle avec des threads Ruby (ce qui encourage les gens à coder de plus grosses parties de leur programme en C), ou encore de donner le contrôle à un autre thread si tu bloques sur une grosse entrée/sortie (mais il faut explicitement coder la relâche du verrou global)). Au contraire la JVM permet de faire tourner du bytecode vraiment en parallèle sur plusieurs cœurs, donc si tu écris tes programmes pour (il faut éviter les data races) tu pourrais avoir des gains en performance.
Je n'ai pas suivi la 2.0 mais il faudrait partir d'une source un peu plus intéressante qu'une demi-phrase sur "un bytecode plus optimisé" dans un article grand public.
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 3.
Il n'empêche que l'implémentation de YARV fait qu'à un instant donné un seul thread Ruby peut s'exécuter, il y a un "Big Interpreter Lock" comme je l'ai dit dans mon message (l'intérêt d'avoir plusieurs threads dans ce cas est d'utiliser l'outillage de l'OS, de faire tourner des threads C en parallèle avec des threads Ruby (ce qui encourage les gens à coder de plus grosses parties de leur programme en C), ou encore de donner le contrôle à un autre thread si tu bloques sur une grosse entrée/sortie (mais il faut explicitement coder la relâche du verrou global)). Au contraire la JVM permet de faire tourner du bytecode vraiment en parallèle sur plusieurs cœurs, donc si tu écris tes programmes pour (il faut éviter les data races) tu pourrais avoir des gains en performance.
Je n'ai pas suivi la 2.0 mais il faudrait partir d'une source un peu plus intéressante qu'une demi-phrase sur "un bytecode plus optimisé" dans un article grand public.