Discussion :

[giova_fr]

Bonjour à tous.

Je rencontre souvant le mot "overhead" dans des docs sur le language .NET, j'imagine que ce mot a une signification "générale" dans le domaine de la programmation.

L'excelentissime site wordreference ne m'a pas apporté d'explication.

Voici quelques extraits, que veut dire ce mot svp?

The thread pool cuts these overheads by sharing and recycling threads.

You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes.

[souviron34]

overhead signifie "en plus"..

C'est une notion en informatique désignant ce qui est nécessaire en plus de ce qui est évident..

Cela peut être pour de la mémoire, de la vitesse, ce qu'on veut..

Par exemple, dans ton deuxième exemple, il dit que :

si on crée plusieurs processus, on va demander plus de ressources (et en mémoire et en temps) car on va devoir changer de contexte (donc par exemple utiliser le loader pour charger un autre processus), et faire des appels de fonctions entre différents processus..

Cela peut être juste du temps, juste de la mémoire, ou les deux..

Si par exemple on fait un tri, on va (en général) avoir besoin d'une copie du buffer initial, ou d'une table de pointeurs sur les éléments. On va donc créer de 'l'overhead", puisque au lieu d'avoir une table de N, on en aura 2.. Dans ce cas-là ce sera de "l'overhead" mémoire.

D'un autre côté, si par exemple on fait une boucle compliquée, et qu'on veut sauvegarder des paramètres à la fin de chaque tour de boucle, si on les sauvegarde sur disque on va créer de "'l'overhead" par rapport à les stocker en mémoire, car l'écriture sur disque sera plus lente que l'écriture en mémoire..
Dans ce cas, ce sera de "l'overhead" temps.


En général on a une combinaison des deux phénomènes.

Il est extrêmement rare que l'on puisse programmer un algorithme en utilisant exactement le montant de ressources égal au nombre d'éléments à traiter.

La comparaison de 2 algorithmes pour le meme problème tiendra donc compte de l'overhead, le meilleur étant celui donnant l'overhead minimum.. (bien que cela ne soit pas le seul facteur, voire le plus déterminant suivant les critères)

[giova_fr]

Merci pour cette explication détaillée !

Donc pour résumer ce mot fort interressant, on pourrait le traduire par "consommation implicite".

Voici le premier exemple remis dans son contexte, et qui maintenant m'apparait bien plus clair :

Few hundred microseconds are spent organizing things as a fresh private local variable stack. Each thread also consumes around 1MB of Memory.The thread pool cuts these overheads by sharing and recycling threads

J'en retiens :
Que la creation d'un thread ne necessite plus forcement 1MB de RAM. Egalement que sa creation peut etre plus rapide, du fait que certains mecanismes/informations necessaires à son fonctionnement, sont déjà disponibles, car partagés entre tous les threads du thread pool.

[souviron34]

Donc pour résumer ce mot fort interressant, on pourrait le traduire par "consommation implicite".

Plutôt "surcoût"..

Il y a le coût normal, et des surcoûts peuvent apparaîtrent à divers endroits pour diverses raisons...

Que la creation d'un thread ne necessite plus forcement 1MB de RAM.

Non. Elle nécessite toujours 1MB de RAM..

C'est juste que, d'éprès ce que je comprend, un certain nombre de ressources sont partagées (pool) et donc par exemple soit sont attribuées au démarrage, soit sont réellement partagées, faisant que le résultat final apparaît comme si la création d'un thread prenait moins de 1MB.

Egalement que sa creation peut etre plus rapide, du fait que certains mecanismes/informations necessaires à son fonctionnement, sont déjà disponibles, car partagés entre tous les threads du thread pool.

oui..


Si on reprend un exemple d'implantation de ce que tu mentionnes :

utiliser N threads devrait prendre au minimum N*1 MB + N*S micro-secondes..

L'utilisation d'un pool change le facteur 1 MB par x MB, x < 1, et S' micro-secondes, S' < S..



Quand tu regardes de manière "extérieure" le problème :

admettons qu'un thread soit défini par une structure de 10 entiers. (peu importe, mais c'est pour l'exemple).

Pour le créer, il faudrait donc allouer un espace de 10 entiers et faire 10 assingations pour initialiser.

Dans ce cas, la mémoire utilisée devrait être (10 * 32 bits) par exemple, et le temps devrait être le temps de 11 instructions (allocation + 10 assignations).

Si ce qui est réellement utilisé est 1 MB et 3 micro-secondes , cela signifie un overhead en mémoire de (1 MB - 10*32 bits), et en vitesse de (3 micro-secondes/nb de cycles CPU/seconde - 11*cycles CPU/seconde)

Plus donc on réduit l'overhead, plus on est efficace pour arriver au même résultat..

Alors l'exemple est simpliste (et certainement faux), mais il me semble parlant...


Enfin, il y a en général deux parties : un overhead incompressible, et un overhead qui peut s'améliorer...

[giova_fr]

C'est tres clair, merci encore pour vos explications.

Je comprendrai bien désormais les docs traitant cette notion. On est vraiment dans un domaine passionnant !

A en lire votre signature, je devinne que c'est une notion que vous devez garder en permanence à l'esprit, notamment lorsqu'il s'agit de traiter un tres grand nombre d'éléments... ou que les ressources sont trés limitées (systeme embarqué).

[souviron34]

c'est une notion que vous devez garder en permanence à l'esprit, notamment lorsqu'il s'agit de traiter un tres grand nombre d'éléments... ou que les ressources sont trés limitées (systeme embarqué).

Euh.. Oui et non...

C'est une notion que TOUT programmeur devrait garder à l'esprit QUEL QUE SOIT le nombre d'éléments ou les ressources...

Ce qui est considéré comme "beaucoup de ressources" à un moment donné sera considéré comme "limité" plus tard.. Ce qui est considéré comme "peu d'éléments" à un moment donné sera vraisemblablement (très) fortement augmenté dans le futur... (par exemple on passera d'une image 640*480 à une HD..)

Ce n'est pas parce que la mémoire RAM ou les Disques durs ne coûtent pas cher, ou que la vitesse des CPU augmente, qu'il ne faut pas penser à réduire au maximum l'utilisation de ces ressources, justement à cause du futur...

C'est (malheureusement) une tendance prononcée aujourd"hui de ne pas trop se pencher sur ce type de choses, qui est pourtant essentiel...

Word nécessite 5k pour sauvegarder 1 lettre. Ce n'est pas franchement efficace.. Par contre, la version de Photoshop que j'ai date de 1999, et tourne avec 4 MB de mémoire... Donc a fortiori avec 2 Gig...

Donc, plus on pense à utiliser au mieux les ressources qu'on a, plus on va durer dans le temps, et moins on va imposer à l'utilisateur de contraintes (de renouvellement ou d'upgrade de machine)

Et cela force un peu à vérifier qu'on ne fait pas tout un tas de trucs inutiles....

C'est donc au contraire une bonne pratique pour TOUS les programmes de se soucier de l'utilisation des ressources, et de tenter de les minimiser (sans aller forcément vers de l'optimisation extrême, qui là sera effectivement réservée aux cas techniquement limites).