Re: Threads vs Process

Le 05/03/2025 à 20:31, Jo Engo a écrit :

Le Wed, 14 Aug 24 22:31:14 +0000, OL a écrit :
 

Non et de très loin. Dans ce cas le thread est plus recommandé mais
c'est plus compliqué à programmer.

 C'est un peu plus compliqué. Pour faire simple, sur un système multi-
cœurs, les threads vont s'exécuter sur le même cœur : totalement inefficace pour du calcul (utilisation du processeur à 100% -> un seul thread s'exécute à la fois, et les autres cœurs sont inutilisés). les processus, dans le cas où on a beaucoup d'entrées-sorties où s'ils sont fortement couplés, sont totalement inefficace (mobilisation de toues les ressources du système pour ne rien faire)
Il y a des variantes dans les threads, mais elles ne seront jamais efficace pour le calcul
Il y a des variantes pour les processus, mais ils ne seront jamais efficace en cas de beaucoup d'entrées-sortties, de latence ou la nécessité d'un fort couplage.

Je crois que vous ne connaissez pas le monde GEM, parce que de mémoire c'est l'exemple typique que j'ai fait je n'ai pas parlé de calcul parallèles, cela ne me viendrais pas à l'esprit, pourquoi faire ce genre de chose sur un processeur unicore unithread? Si ce n'est perdre du temps dans le switch des tâches.
N'empêche que le thread peut être ultra efficace pour gérer une interface et faire un calcul concurrent, typiquement player son ou vidéo.
Le GEM est assez particulier et de conception ancienne fait pour de faibles ressources, il'est très efficace pour une application avec interface statique type traitement de texte et pas étudié du tout pour une utilisation intensive comme doivent le faire un logiciel type playeur.
En effet pour gérer l'interface il n'y a pas de système de pseudo interruption logicielle en fonction des événements, ceux-ci doivent être vérifiés à intervalle suffisamment régulier pour assurer la fluidité de l'interface, les applications standard n'ont pas besoin de cela, elles rentrent dans le gestionnaire d'événements et sont misent à l'arrêt tant que l'interface n'est pas sollicitée ou qu'un timer soit atteint ce qui est très efficace pour décharger le processeur et largement suffisant pour gérer classiquement une interface, mais lorsque l'on doit faire en même temps du calcul intensif c'est une autre histoire car d'une part c'est très inefficace la perte de temps est énorme sur certains aes pas pensés pour ce genre de charge même si les aes modernes se débrouillent pas mal mais surtout cela demande pas mal d'effort de gestion du temps pour vérifier suffisamment l'interface pour qu'elle réponde au moins tous les 100ms voir moins pour plus de fluidité et à la fois pas trop souvent pour ne pas écrouler les performances. Le thread élimine de manière élégante et efficace le défaut de conception de l'aes en effet in thread se contente de gérer l'interface et l'autre de faire le calcul, le thread de l'interface n'aura quasi aucun coût car il sera mis au repos par l'aes, l'autre thread pourra avoir tout son temps à faire uniquement les calculs, plus de gestion du temps pour gérer l'interface et interroger l'interface, on se retrouve avec la même efficacité qu'une interruption logicielle.
Il n'y a pas photo sur ce point.
Sinon actuellement on n'a pas de système capable de répartir 2 threads sur 2 coeurs ou 2 threads physique, mais il existerait une possibilité d'intérêt sur le 68080 annoncé comme supportant l'hyperthreading (aucune preuve que cela marche), l'hyperthreading peut être intéressant pour charger un processeur comme le 68080 car ul est capable de réaliser jusque 4 instructions par cycle mais cela est très théorique la plupart du temps il n'est capable que de faire 1 instruction avec un peu de chance 2 les programmes ne sont pas adaptés avec 2 thread on peut espérer augmenter la charge même si le doublement n'est réaliste à mon avis car on doit partager la bande passante.
Ol