asynchronisme : on lance une tache donc on ne connait pas la durée qui va s'exécuter en même temps qu'une autre : par ex, interroger une api.
parallélisation : on veut réduire une tache en la fractionnant en n sous ensembles qui s’exécutent en même temps : par ex convertir une vidéo couleur en n&b : on peut découper la vidéo en 4 morceaux de même durée, appliquer l'algo sur chacun des morceaux et quand tous sont fini on ré-assemble le tout.
Alors en soit oui, mais il y a des amalgames. La parallélisation est le fait de faire plusieurs choses en même temps et l'asynchronisme est le fait de gérer le décallage temporel qu'il peut y avoir entre 2 évènements. J'aime bien parler de réactif pour l'engouement actuel. Il s'agit de considérer toutes tes IO selon des paradigmes asynchrones supprimant tout blocage.
Pour ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.
Pour la parallélisation oui, pour du réactif les threads et process sont de piètres palliatifs.
La diff entre thread et process : le thread utilise une mémoire partagé, les processus des espaces mémoires diff.
En terme de rapidité, ils sont sensiblement équivalent (si on est pointilleux, non car la création d'un process à un coût au lancement qui est en plus pas identique selon l'OS utilisé) mais le processus est plus consommateur en mémoire. (ce qui n'est pas forcément un soucis si on la ram suffisante)
Le thread a un défaut majeur : il partage ça mémoire et donc 2 taches ne doivent pas écrire sur le même espace en même temps.
Avoir la RAM suffisante est vraiment un palliatif quand on compare au résultats des solutions réactives et tu es face à un problème de taille : la multiplication de tes threads ou processus multiplie les commutations de contexte. Donc plus tu as de clients plus tu passe une proportion de ton temps dans tes commutations de contexte. Entre ça et la RAM qui va avec c'est très dommageable, pour les gros car ce sont des serveurs en plus à avoir et pour les petits parce que ça empêche de fonctionner correctement sur les les plus petites machines.
Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.
La différence est drastique.
Par ex, ton navigateur Chrome ou Firefox fait de l'asynchrone en utilisant un process par onglet (mais souvent plusieurs threads dans ce même onglet) : dans l'absolu, ce n'est pas parfait.
Ils ont d'autres contraintes. Ils ont par exemple besoin de garantir qu'un onglet n'accède pas aux données d'un autre onglet. Le fonctionnement des greens threads pose aussi des problèmes quand tu exécute du code qui n'est pas à toi.
Si les green thread ne sont pas disponibles, et qu'on veut faire de l'asynchrone ou de la parallélisation, il faut trancher entre thread ou process
Tu te fourvoie sur les greens threads, ils ne sont pas vraiment fais pour la parallélisation et ce ne sont pas les meilleurs pour ça.
Le principe derrière réactif dont je parlais plus haut c'est d'avoir un pattern reactor. Tu as une boucle d'évènements1 et tu les traite l'un après l'autre sans avoir de thread (et encore moins de processus) entre la boucle d'évènement et le traitement. Tu as une boucle par CPU et une file d'évènements devant. Chaque IO doit passer par cette boucle d'évènements. Ça c'est l'interne, l'implémentation, c'est du traitement coopératif, on ne préempte pas c'est toi qui laisse la main. Évidement il ne faut pas être être CPU bound (sinon tu as besoin de paralléilisation) mais IO bound.
POE et twisted te montrent assez directement ce paterne. Mais tu as d'autres API qui l'encapsule et t'aide à t'en servir. C'est ça les green thread. Chaque appel qui paraît bloquant est en fait implémenté de façon asynchrone et est l'occasion de passer la main à l'évènement suivant. Mais il y en a d'autres comme les acteurs ou rx par exemple.
Pour en revenir à PHP, je ne vois pas pourquoi l'asynchronisme ou la parallélisation n'aurait pas d'utilité, peut importe le moyen employé ?
En php tu ne gère pas un serveur qui reçois des requêtes que tu dois traiter. Ton code est instancié pour chaque requête. C'est la stack qui s'occupe de ça pour toi. Tu as différentes façon de lancer ton code PHP ce n'est pas lié à ta version de php (pour pouvoir être réactif il faut effectivement ajouter des choses dans le langage). Pour le parallélisme, il est par essence massivement parallèle. Tu peut avoir des besoin de parallélisation en plus, mais en soit c'est rare et c'est dangereux de faire du parallélisme par requête.
c'est basé à fond sur epoll(4) pour attendre des évènements sur une série de file descriptor ↩
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 3. Dernière modification le 02 décembre 2020 à 01:00.
Je ne suis pas d'accord :)
Alors en soit oui, mais il y a des amalgames. La parallélisation est le fait de faire plusieurs choses en même temps et l'asynchronisme est le fait de gérer le décallage temporel qu'il peut y avoir entre 2 évènements. J'aime bien parler de réactif pour l'engouement actuel. Il s'agit de considérer toutes tes IO selon des paradigmes asynchrones supprimant tout blocage.
Pour la parallélisation oui, pour du réactif les threads et process sont de piètres palliatifs.
Avoir la RAM suffisante est vraiment un palliatif quand on compare au résultats des solutions réactives et tu es face à un problème de taille : la multiplication de tes threads ou processus multiplie les commutations de contexte. Donc plus tu as de clients plus tu passe une proportion de ton temps dans tes commutations de contexte. Entre ça et la RAM qui va avec c'est très dommageable, pour les gros car ce sont des serveurs en plus à avoir et pour les petits parce que ça empêche de fonctionner correctement sur les les plus petites machines.
La différence est drastique.
Ils ont d'autres contraintes. Ils ont par exemple besoin de garantir qu'un onglet n'accède pas aux données d'un autre onglet. Le fonctionnement des greens threads pose aussi des problèmes quand tu exécute du code qui n'est pas à toi.
Tu te fourvoie sur les greens threads, ils ne sont pas vraiment fais pour la parallélisation et ce ne sont pas les meilleurs pour ça.
Le principe derrière réactif dont je parlais plus haut c'est d'avoir un pattern reactor. Tu as une boucle d'évènements1 et tu les traite l'un après l'autre sans avoir de thread (et encore moins de processus) entre la boucle d'évènement et le traitement. Tu as une boucle par CPU et une file d'évènements devant. Chaque IO doit passer par cette boucle d'évènements. Ça c'est l'interne, l'implémentation, c'est du traitement coopératif, on ne préempte pas c'est toi qui laisse la main. Évidement il ne faut pas être être CPU bound (sinon tu as besoin de paralléilisation) mais IO bound.
POE et twisted te montrent assez directement ce paterne. Mais tu as d'autres API qui l'encapsule et t'aide à t'en servir. C'est ça les green thread. Chaque appel qui paraît bloquant est en fait implémenté de façon asynchrone et est l'occasion de passer la main à l'évènement suivant. Mais il y en a d'autres comme les acteurs ou rx par exemple.
En php tu ne gère pas un serveur qui reçois des requêtes que tu dois traiter. Ton code est instancié pour chaque requête. C'est la stack qui s'occupe de ça pour toi. Tu as différentes façon de lancer ton code PHP ce n'est pas lié à ta version de php (pour pouvoir être réactif il faut effectivement ajouter des choses dans le langage). Pour le parallélisme, il est par essence massivement parallèle. Tu peut avoir des besoin de parallélisation en plus, mais en soit c'est rare et c'est dangereux de faire du parallélisme par requête.
c'est basé à fond sur
epoll(4)pour attendre des évènements sur une série de file descriptor ↩https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll