Les langages interprétés sont très souvent pénalisés par leur Global Interpreter Lock (de son petit nom GIL),
Je me souviens d'une discussion. Par contre, impossible de me souvenir si c'était sur une mailing list avec Guido dedans ou sur un obscur forum. N'hésitez pas à corriger, c'est de mémoire ce que je vais dire, et elle peut me jouer des tours.
Le GIL (qui oblige l'utilisation d'un seul thread. Contrairement à un processus, un thread partage l'espace mémoire avec ses autres potes thread) a été introduit dans Python pour simplifier l'implémentation du langage. Plus tard, des personnes ont voulu débrayer le GIL et Guido n'a pas été super enthousiaste, car il ne voulait pas voir débarquer les soucis de la programmation concurrente. Après, il y a une histoire avec ces personnes qui ont crée Stackless Python, mais je n'ai pas très bien compris si il y avait encore un GIL dedans. Bref.
Une autre raison pour le GIL, d'après Guido, c'est la perte de performance sur l'ensemble du langage. Si j'ai bien compris, le fait de débrayer le GIL oblige à faire un tas de vérification sur une large portion du langage pour éviter les deadlock, inversion de priorité et autres joyeuseté de la prog concurrente, ce qui serait ballot pour quelqu'un qui ne s'intéresse pas vraiment aux threads. Ces vérifications seraient bien plus couteuse que le fait d'empêcher le multi-threading.
Cet histoire de GIL est donc une histoire de compromis. Si quelqu'un est capable d'apporter un compromis qui penche plus en faveur du multi-thread, nul doute que ce sera intégré à l'implémentation standard.
Désolé d'avoir parasiter ce fil Ruby, mais j'imagine que ça doit être la même chose pour l'implémentation de référence en Ruby.
# Du pourquoi du GIL
Posté par Sekigo . En réponse à la dépêche Sortie de Rubinius 2.0. Évalué à 6.
Je me souviens d'une discussion. Par contre, impossible de me souvenir si c'était sur une mailing list avec Guido dedans ou sur un obscur forum. N'hésitez pas à corriger, c'est de mémoire ce que je vais dire, et elle peut me jouer des tours.
Le GIL (qui oblige l'utilisation d'un seul thread. Contrairement à un processus, un thread partage l'espace mémoire avec ses autres potes thread) a été introduit dans Python pour simplifier l'implémentation du langage. Plus tard, des personnes ont voulu débrayer le GIL et Guido n'a pas été super enthousiaste, car il ne voulait pas voir débarquer les soucis de la programmation concurrente. Après, il y a une histoire avec ces personnes qui ont crée Stackless Python, mais je n'ai pas très bien compris si il y avait encore un GIL dedans. Bref.
Une autre raison pour le GIL, d'après Guido, c'est la perte de performance sur l'ensemble du langage. Si j'ai bien compris, le fait de débrayer le GIL oblige à faire un tas de vérification sur une large portion du langage pour éviter les deadlock, inversion de priorité et autres joyeuseté de la prog concurrente, ce qui serait ballot pour quelqu'un qui ne s'intéresse pas vraiment aux threads. Ces vérifications seraient bien plus couteuse que le fait d'empêcher le multi-threading.
Cet histoire de GIL est donc une histoire de compromis. Si quelqu'un est capable d'apporter un compromis qui penche plus en faveur du multi-thread, nul doute que ce sera intégré à l'implémentation standard.
Désolé d'avoir parasiter ce fil Ruby, mais j'imagine que ça doit être la même chose pour l'implémentation de référence en Ruby.