Autant dire qu'on est dans des développements très spécifiques qui n'affectent pas la majorité des programmes écrits en Python.
Bon, ok, j'en ai fait un peu trop. Il est tellement fréquent de lire CPython c'est de la m**** à cause du GIL que j'ai voulu redonner du poids au fait que CPython marche plutôt pas mal. Mea Culpa !
Et il me parait important de rappeler que le problème du GIL n'est pas un problème générique mais un problème qui affecte des cas précis d'utilisation de Python.
les faiblesses de CPython sont des cas particuliers, alors que justement, dans l'absolu, la latence sur les I/O ou une application monothread sont des cas particuliers.
J'avoue que je comprends pas ta phrase.
Il y a le cas général qui comprend tous les types d'applications possibles avec les threads où on peut dire que Python va s'en sortir dans certains cas et pas dans d'autres. Donc au final, une non réponse.
Ensuite, on peut partitionner l'ensemble des application des applications utilisant des threads en applications IO-Bound et en CPU-Bound. Dans le premier cas, Python s'en sort bien, dans le deuxième pas.
Difficile de savoir si le premier cas couvre une majorité ou une minorité d’application. Surtout que c'est plus par domaine. Dans le calcul scientifique, traitement de données (image, video, statistiques), on est souvent dans du CPU-bound donc le GIL peut poser problème. Dans le domaine des utilitaires, des langage d'intégration, on est plus souvent dans du IO-Bound voir du rien-du-tout-bound (ça marche déjà à la vitesse qu'il faut).
Si CPython a une gestion des threads aussi merdique que les OS libres en 2000 (linux-threads et libc_r sous FreeBSD) et bien c'est la vie. Il faut l'admettre.
Si j'avais voulu nier, je l'aurai même pas rappeler dans la dépêche. Tu pourrais m'en dire plus sur la gestion des threads des années 2000, je ne connais pas mais ça m'interesse....
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 3.
Je me relis pour voir:
Bon, ok, j'en ai fait un peu trop. Il est tellement fréquent de lire CPython c'est de la m**** à cause du GIL que j'ai voulu redonner du poids au fait que CPython marche plutôt pas mal. Mea Culpa !
Et il me parait important de rappeler que le problème du GIL n'est pas un problème générique mais un problème qui affecte des cas précis d'utilisation de Python.
J'avoue que je comprends pas ta phrase.
Il y a le cas général qui comprend tous les types d'applications possibles avec les threads où on peut dire que Python va s'en sortir dans certains cas et pas dans d'autres. Donc au final, une non réponse.
Ensuite, on peut partitionner l'ensemble des application des applications utilisant des threads en applications IO-Bound et en CPU-Bound. Dans le premier cas, Python s'en sort bien, dans le deuxième pas.
Difficile de savoir si le premier cas couvre une majorité ou une minorité d’application. Surtout que c'est plus par domaine. Dans le calcul scientifique, traitement de données (image, video, statistiques), on est souvent dans du CPU-bound donc le GIL peut poser problème. Dans le domaine des utilitaires, des langage d'intégration, on est plus souvent dans du IO-Bound voir du rien-du-tout-bound (ça marche déjà à la vitesse qu'il faut).
Si j'avais voulu nier, je l'aurai même pas rappeler dans la dépêche. Tu pourrais m'en dire plus sur la gestion des threads des années 2000, je ne connais pas mais ça m'interesse....