On Tuesday 23 August 2005 17:39, Cedric BRINER wrote: > Qu'entends-tu par: ``disk bound''
CAD que find est avant tout "bloque" par les performances du disque. De plus, un disque a deux limitations. Sont taux de transfert maximal (quand les blocs se suivent bien...) et le nombre de mouvement des tetes par seconde (assez lie a la vitesse de rotation, quoique ca depend du genre de mouvement). Or, find n'a pas besoin de lire les data de chaque fichier, mais simplement les informations relatives a ceux-ci et contenu dans les "directory". Ce qui fait que find doit lire plein de blocs relativement petits et non contigus. Il est donc tres limite par la performance du disque. En dehors de ca, et a part les transferts de data entre le kernel et la "data user space" du programme, find a bien peu de travail a effectue si ce n'est de "balayer" des structures et de comparer leurs valeurs. find n'est donc pas un tueur de CPU... Sur mon systeme, lancer un 'find / -print' m'utilise entre 1.0 et 1.5 % de CPU... alors que le disque est sur le genoux en train de "savonner" entre 150 et 500 tps (tracks / second) !!! C'est donc la qu'est le goulet d'etranglement... > *) Imaginons que chaque tache prenne environ de 30min a 1h30 de calcul et > 1/4 de la memoire. Que de trouver un nouveau fichier prenne 4 min. Alors > executer autant de ``mon_programme'' que de processeurs me semble etre une > bonne politique. Oui et non... ca depend :-) Il faut separer les deux choses. Tu parles d'un programme de calcul qui prend 1h (en moyenne), puis de recherche de fichier qui ne prend que 6.7% de ce temps... Si tu as besoin de rechercher des fichiers dans ton systeme de maniere reguliere, ne peux-tu as envisager de faire un find de temps en temps (find / -print), dont le contenu sera mis dans un seul fichier, puis de faire un grep sur ce contenu ? C'est ce que je fais depuis des annees. Actuellement, mon find me prend 305 secondes, genere un fichier de 45 MB contenant 803'000 fichiers. Un 'grep toto' me prend 0.5 secondes... soit 610 fois plus rapide que de faire un find. Bien sur, le fichier pourait aussi contenir la taille, le UID, etc. Mais, meme si le fichier devient plus gros, le grep sur celui-ci restera massivement plsu rapide que le find. Si maintenant, tes programmes qui durent 1 heure, generent des tonnes de fichiers aux noms aleatoires, le problemen est different. Mais malgre cela, find reste peut-etre la moins bonne solution. A moins qu'en plus les fichiers ne soient crees a des endroits aleatoires dans le systeme :-) > Si au lieu de ca, on lance les 100 mon_programme en parallele, alors j'en > aurais que le_nombre_de_processeur en un instant donne qui tourneront alors > que les autres seront en ``sleep''. Ce qui se rapproche de (*) a la > diffrence pres que cette methode sera bcp plus couteuse question swap ! Pour benefichier au maximum de l'effet 'N', il faut que le programme soit tres petit (au niveau code) et qu'il utilise exclusivement des 'shared libraries'. Sinon, chaque libraririe (ou portion de code) statique sera dupliquee dans la memoire !!! Toutefois, il faut encore que le programme soit fortement oriente "boucle de calcul", ainsi les portions de code a execute auront plus de chance de rester dans la memoire cache... mais... il y a uassi un desavantage. Il se peut que la version 1 du programme tourne un moment sur le CPU A. Donc, c'est la cache (text) du CPU qui sera utilisee... puis, ce process va ceder sa place a un autre et il y a pas mal de chances qu'il se retrouve a devoir tourner sur un autre CPU... alors la cache du CPU A doit etre invalidee (facile et peu couteux) et le 'code' a execute doi etre recharge dans la cache du nouveau CPU (tres couteux). Et encore, nous ne parlons que du caching du code executable... C'est quand on commence a envidager le probleme des data que ca se corse vraiment. En effet, dans le cas des data, rien n'est partage entre les process. Ce qui fait que plus on a de CPU, plus on a de chances d'etre "reschedule" sur un autre CPU avec le probleme de la cache directement lie. Ceci engendre une charge importante sur la cache des CPU et, de fait, sur le bus memoire. La saturation peut donc etre tres vite atteinte si les programmes manipulent de grosses sections de donnees. C'est la raison pour laquelle les systemes destines a etre utilises comme serveur de calcul // ont des fonctionalites dans le kernel permettant de bloquer un process sur un CPU en particulier (entre autre). Cette fonction est disponible sous Linux mais elle n[est pas en standard dans le kernel. En plus, il est important d'avoir un bus memoire consequent, ainsi que des chipsets et MMUs un peu plus exotique que ceux que l'on trouve dans les PC. Aussi, ces systems groupent les CPUs par paquet de 2 ou 4 sur une meme carte avec un chipset particulier destine a emeliorer la coherence des caches entre les N CPUs de la carte. Les MMUs sont concus pour permettre la serialisation des requetes a la memoire, ainsi que l'independances des acces DMA. En plus, il vaut mieux utiliser des CPUs dont l'architecture est specialement etudiee pour optimiser le pipeline et la cache... c'est-a-dire concu pour etre mis en // avec d'autres CPUs. Meme si les Pentium/Xeon/AMD sont optimises au maximum, ils n'ont pas ete concus pour ce genre d'usage et il engendres une saturation plus rapidement que des architectures Power & Itanium. Ce qui fait aussi que l'on ne trouve pas vraiment de chipset concus pour supporter 64 ou 128 Pentium (en vrai partage de memoire !!!). > > A moins d'avoir N disques, auquel cas il est cense de lancer un find par > > disque (voir deux...). > > Je ne comprends pas cette phrase. On doit avoir un petit probleme de > comprehension. Sachant que le disque EST le goulet d'etranglement, il est parfaitement logique de lancer un find par disque. _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
