make -j

"DINH Viêt Hoà" <dinh.viet.hoa@free.fr> wrote in message
news:etPan.3f8e7056.15b5130b.960@homer...
| $ make clean
| $ time make
| ...
| real 0m53.712s
| user 0m19.100s
| sys 0m3.860s
|
| $ make clean
| $ time make -j 4
| ...
| real 0m39.082s
| user 0m20.450s
| sys 0m4.500s
|
| $ make clean
| $ time make
| ...
| real 0m30.381s
| user 0m19.350s
| sys 0m4.120s
|
| C'est effectué sur un monoprocesseur.
| On s'aperçoit que plus on laisse de compilations en parallèle, plus le
| temps "real" est diminué. A noter que je ne fais pas plus de choses
| pendant un make ou un autre. Cela s'explique-t-il ?
|


le cache, en fait une fois une compile efectuee, tes fichiers sont mis en
cache, alors a la seconde compil, il sera plus facile de les retrouver.

| --
| DINH V. Hoa,
|
| "quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ
|

DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:

$ make clean
$ time make
...
real 0m53.712s
user 0m19.100s
sys 0m3.860s

$ make clean
$ time make -j 4
...
real 0m39.082s
user 0m20.450s
sys 0m4.500s

$ make clean
$ time make
...
real 0m30.381s
user 0m19.350s
sys 0m4.120s

C'est effectué sur un monoprocesseur.
On s'aperçoit que plus on laisse de compilations en parallèle, plus le
temps "real" est diminué. A noter que je ne fais pas plus de choses
pendant un make ou un autre. Cela s'explique-t-il ?

Dans le deuxième cas le scheduler va favoriser les make par rapport
aux autres processus, puisque tu as 4 fois plus de make. Donc le temps
total passé dans l'exécution des make va diminuer de façon importante
même si ça coute plus en temps effectif utilisé (user+sys). Dans le
dernier cas il semble que tu bénéficies d'un effet de cache.

--

Michel TALON

$ make clean
$ time make

le dernier make est un "make -j", d'où la description donnée.

--
DINH V. Hoa,

"quoi ? faire 500km avec MA caisse ! ca va pas nan ? ça va l'user" -- sunZ

Dans le deuxième cas le scheduler va favoriser les make par rapport
aux autres processus, puisque tu as 4 fois plus de make. Donc le temps
total passé dans l'exécution des make va diminuer de façon importante
même si ça coute plus en temps effectif utilisé (user+sys).

Non. Le temps global est moins important, parce que certains make
vont être en utilisation de CPU pendant que d'autres sont en attente
d'IO. Cela montre simplement que le CPU est mieux utilisé. Le surcoût
en temps effectif vient certainement du plus grand nombre de
commutation de taches.

Le gain peut aussi s'expliquer avec les caches (il n'y a aucune
raison que le test 2 n'en bénéfie pas alors que le 3 oui).

Dans le dernier cas il semble que tu bénéficies d'un effet de cache.

Oui.

--
Je cherche 150KF pour un investissement boursier. Remboursement selon
entente même à fort taux de crédit. Si vous êtes intéressé ou avez des
renseignements pouvant m'être utile merci de m'envoyer un mail.
-+- D5 in GNU : Neuneu a acheté du .com et la fin de mois arrive -+-

Jeudi le 16 octobre 2003, vers 12:17:58 (CEST), DINH Viêt Hoà a écrit:

$ make clean
$ time make
...
real 0m53.712s
[...]

$ make clean
$ time make -j 4
...
real 0m39.082s
[...]

Une compilation fait beaucoup d'entrées/sorties (fichiers
lus/créés). En séquentiel, le processeur ne fait rien pendant ces
E/S. En parallèle, quand un processus de compilation est bloqué en
attente d'E/S, le processeur peut-être occupé par un autre processus
de compilation.

Il existe un point d'équilibre au-delà duquel augmenter le nombre de
processus (si le graphe de dépendances de la compilation s'y prête)
fera baisser les performances. Ce point est surtout lié à la quantité
de mémoire disponible (il faut éviter de swapper), mais d'autres
facteurs peuvent entrer en compte comme la surcharge sur le système de
fichiers (accès concurrents), la performance de l'ordonnanceur où le
coût des changements de contexte.

--
Arnaud

DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:

$ make clean
$ time make
...
real 0m53.712s
user 0m19.100s
sys 0m3.860s

$ make clean
$ time make -j 4
...
real 0m39.082s
user 0m20.450s
sys 0m4.500s

$ make clean
$ time make

Je suppose make -j qqch > 4

...
real 0m30.381s
user 0m19.350s
sys 0m4.120s

C'est effectué sur un monoprocesseur.
On s'aperçoit que plus on laisse de compilations en parallèle, plus le
temps "real" est diminué. A noter que je ne fais pas plus de choses
pendant un make ou un autre. Cela s'explique-t-il ?

Et je suppose aussi que c'est des resultats reproductibles en repetant
plusieurs fois consecutivement (sinon vaut voir du cote des caches,
des serveurs nfs eventuels, ...)

La difference entre real et user+sys c'est du temps passe a attendre.
Attendre quoi ? Des I/O. Donc on attend environ 30 s que des I/O se
fasse et on mouline reellement 23s. Si on arrive a faire les I/O en
// de la compilation, on pourra on mieux arriver a tout faire en 30s,
c'est ce que reussit apparemment ta troisieme commande. Pour que ca
marche, il faut avoir suffisemment de memoire pour ne pas swapper.

A+

--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Stephane Dupille <sdupille+news@teaser.fr> wrote:

Dans le deuxième cas le scheduler va favoriser les make par rapport
aux autres processus, puisque tu as 4 fois plus de make. Donc le temps
total passé dans l'exécution des make va diminuer de façon importante
même si ça coute plus en temps effectif utilisé (user+sys).

Non. Le temps global est moins important, parce que certains make
vont être en utilisation de CPU pendant que d'autres sont en attente
d'IO.

Oui, enfin les deux raisonnements reviennent exactement au même, plus
de temps CPU est alloué au build et moins aux autres process. Sachant
qu'un autre process est schedulé, soit parceque le processus courant a
épuisé son quantum, soit qu'il est bloqué en attente d'IO.

Cela montre simplement que le CPU est mieux utilisé. Le surcoût
en temps effectif vient certainement du plus grand nombre de
commutation de taches.

Ben oui, ce qui m'avait frappé dans ces chiffres, c'est que usr et sys
augmentent mais real diminue fortement. Donc en effet multiplier le make
multiplie les processus qui sont bloqués en attente d'IO et introduit
une inefficacité dans le système, sans parler des frais de commutation.
S'il y avait plusieurs procs, évidemment on gagnerait avec plusieurs
programmes se compilant en même temps. Averc un seul proc ce gain est
impossible, donc a priori on ne récolte que des ennuis. Cependant real
diminue de moitié. Outre l'effet de cache que tu notes, je pense que
simplement plus du processus est alloué au build au détriment du reste,
par exemple comme tu le notes, il y a une plus grande probabilité qu'il
y ait toujours au moins une compil en train de s'exécuter.

Le gain peut aussi s'expliquer avec les caches (il n'y a aucune
raison que le test 2 n'en bénéfie pas alors que le 3 oui).

Dans le dernier cas il semble que tu bénéficies d'un effet de cache.

Oui.

--

Michel TALON

Michel Talon wrote:

Stephane Dupille <sdupille+news@teaser.fr> wrote:

Dans le deuxième cas le scheduler va favoriser les make par rapport
aux autres processus, puisque tu as 4 fois plus de make. Donc le temps
total passé dans l'exécution des make va diminuer de façon importante
même si ça coute plus en temps effectif utilisé (user+sys).

Non. Le temps global est moins important, parce que certains make
vont être en utilisation de CPU pendant que d'autres sont en attente
d'IO.

Oui, enfin les deux raisonnements reviennent exactement au même, plus
de temps CPU est alloué au build et moins aux autres process. Sachant
qu'un autre process est schedulé, soit parceque le processus courant a
épuisé son quantum, soit qu'il est bloqué en attente d'IO.

Si j'ai bien compris, si on remplace le processus de make par, par
exemple, le lancement, de n instances d'un programme de calcul pur. Ca
ira plus vite si elles sont lancees en parallele que si elles sont
lancees en sequentiel. Desole, mais ca contredit toutes mes croyances
sur les OS. En plus, le fait d'ajouter plus de processus en parallele,
devrait plutot ralentir puisque le scheduler devrait mettre plus de
temps a choisir le processus suivant.
Dans le cas de make, ca accelere, uniquement, parce que pendant un acces
disque, un processus est endormi, et que la main est donnee a un autre.


Didier.

youp <youp@youp.org> wrote in message news:<bmobaj$ls0$1@wfn.emn.fr>...

Michel Talon wrote:

Stephane Dupille <sdupille+news@teaser.fr> wrote:

Dans le deuxième cas le scheduler va favoriser les make par rapport
aux autres processus, puisque tu as 4 fois plus de make. Donc le
temps total passé dans l'exécution des make va diminuer de façon
importante même si ça coute plus en temps effectif utilisé
(user+sys).

Non. Le temps global est moins important, parce que certains make
vont être en utilisation de CPU pendant que d'autres sont en attente
d'IO.

Oui, enfin les deux raisonnements reviennent exactement au même,
plus de temps CPU est alloué au build et moins aux autres
process. Sachant qu'un autre process est schedulé, soit parceque le
processus courant a épuisé son quantum, soit qu'il est bloqué en
attente d'IO.

Si j'ai bien compris, si on remplace le processus de make par, par
exemple, le lancement, de n instances d'un programme de calcul pur. Ca
ira plus vite si elles sont lancees en parallele que si elles sont
lancees en sequentiel. Desole, mais ca contredit toutes mes croyances
sur les OS. En plus, le fait d'ajouter plus de processus en parallele,
devrait plutot ralentir puisque le scheduler devrait mettre plus de
temps a choisir le processus suivant. Dans le cas de make, ca
accelere, uniquement, parce que pendant un acces disque, un processus
est endormi, et que la main est donnee a un autre.

Tout dépend. Il y a au moins trois phénomènes différents qui peuvent
entre en jeu.

- Le premier, c'est bien que certains processus profite du temps que
les autres sont bloqués sur des attentes entrées/sorties. Comme toi,
je suis prèsque sûr que c'est le phénomène qu'on voit ici. Et c'est
un phénomène qui ne marche pas avec des processus non IO-bound.
Mais...

- S'il y a un processus de fond qui prend 100% du CPU. Tu lances aussi
un processus qui prend 100% du CPU. Chaque processus reçoit en fait
50% du CPU. En revanche, si tu en lances 4, chaque processus reçoit
20% du CPU. Seulement, quatre des processus travaillent sur ton
problème -- tu as 80% du CPU, et le processus initial n'en a que
20%. Ça peut bien payer un peut plus de temps dans le schéduleur.

- Enfin, il y a le cas où un processus prend toute la mémoire réele.
Et que quatre processus en prend beaucoup plus, qui fait que tous
les processus se mettent à pager comme des fous, et le tout va moins
vite. Dans ce cas-ci, d'avantage de processus peuvent rallentir le
tout, même dans le cas des processus IO-bound. (Surtout si la
mémoire virtuelle et les fichiers sont sur le même disque physique,
et se font de la concurrence pour les accès.)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16