On Thu, 10 Oct 2002, Daniel Cordey wrote: > de taille des codes diminue de mani�re imortante la quantit� de code � > charger dans la m�moire. De plus, cela r�duit de mani�re drastique pa > "pression" sur la D-Cache du CPU. L'un dans l'autre, sur un serveur cette
Tr�s int�ressant, je n'avais pas pens� � cet aspect du probl�me. Un autre aspect est (en particulier sur ix86) qu'il est assez facile d'optimiser le syst�me en rempla�ant la libc standard par une libc optimis�e pour le processeur donn�e, �ventuellement avec une option par cas via LD_LIBRARY_PATH ou LD_PRELOAD. Cela permet de conserver une grande compatibilit� du syst�me (programmes compil�s pour 386) tout en ayant une bonne performance (kernel recompil� pour le bon processeur, libc binaire et autres biblioth�ques comme SSL p.ex. �galement). Un autre avantage des biblioth�ques partag�es est que l'on peut facilement faire des patches au syst�me sans changer le kernel: p.ex. transformer les ouvertures de "/dev/remote/sun1/nst0" en un rmt presque trivialement. Il y a notamment le package virtualfs qui impl�mente quelque chose de semblable � NFS mais compl�tement en user-space. Am�liorer cela pour supporter le `fail-over' entre deux serveurs serait le travail d'une demi-journ�e: faire de m�me avec NFS ... (*) (*) c'est peut-�tre d�j� fait, je ne sais pas. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
