Quand je compile un Makefile avec l'option -j de make (pour lancer plusieurs
tâches en même temps), cela se passe bien, sauf pour les archives créées
avec ar. En effet "ar" n'est pas réentrant et cela ce passe mal en général
avec un message du genre :
ar: lib.a: Resource temporarily unavailable
Est-ce que quelqu'un connaît une solution à ce problème (genre poser des
verrous sur une ligne de Makefile) ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 07/03/08 17:25, dans <20080307162016$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3F6EC14.C70BF%, Eric Levenez écrit:
L'option "-j" seule, qui lance tout en parallèle, "écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
C'est un problème avec Mac OS X: quand un processus fait beaucoup d'accès disque, les performances du système s'écroulent! :(
Je ne parlais pas de cela. Le problème est juste que lancer quelques dizaines de compilations simultanées (plus que de c¦urs disponibles), cela ralenti. Idem sur GNU/Linux.
Pour une compilation d'un petit projet, le "-j" par rapport à "-j8" me fait perdre 2 % de temps, ce qui est négligeable. Le "-j" seul sur un gros projet je l'avais testé sur du GNU/Linux justement et cela était utilisable ou du moins le -jN était nettement plus performant.
Je le remarque bien lorsque les tâches effectuées chaque nuit se mettent en route: lancer un Emacs prend plusieurs dizaines de secondes, alors que c'est habituellement quasiment immédiat (que la machine soit chargée ou non). Je n'ai pas ce genre de problème avec Linux.
Je n'échangerais pas mon Mac OS X contre deux barils de GNU/Linux ! :-p
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 07/03/08 17:25, dans <20080307162016$31f7@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C3F6EC14.C70BF%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
L'option "-j" seule, qui lance tout en parallèle,
"écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
C'est un problème avec Mac OS X: quand un processus fait beaucoup
d'accès disque, les performances du système s'écroulent! :(
Je ne parlais pas de cela. Le problème est juste que lancer quelques
dizaines de compilations simultanées (plus que de c¦urs disponibles), cela
ralenti. Idem sur GNU/Linux.
Pour une compilation d'un petit projet, le "-j" par rapport à "-j8" me fait
perdre 2 % de temps, ce qui est négligeable. Le "-j" seul sur un gros projet
je l'avais testé sur du GNU/Linux justement et cela était utilisable ou du
moins le -jN était nettement plus performant.
Je le
remarque bien lorsque les tâches effectuées chaque nuit se mettent
en route: lancer un Emacs prend plusieurs dizaines de secondes,
alors que c'est habituellement quasiment immédiat (que la machine
soit chargée ou non). Je n'ai pas ce genre de problème avec Linux.
Je n'échangerais pas mon Mac OS X contre deux barils de GNU/Linux ! :-p
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 07/03/08 17:25, dans <20080307162016$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3F6EC14.C70BF%, Eric Levenez écrit:
L'option "-j" seule, qui lance tout en parallèle, "écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
C'est un problème avec Mac OS X: quand un processus fait beaucoup d'accès disque, les performances du système s'écroulent! :(
Je ne parlais pas de cela. Le problème est juste que lancer quelques dizaines de compilations simultanées (plus que de c¦urs disponibles), cela ralenti. Idem sur GNU/Linux.
Pour une compilation d'un petit projet, le "-j" par rapport à "-j8" me fait perdre 2 % de temps, ce qui est négligeable. Le "-j" seul sur un gros projet je l'avais testé sur du GNU/Linux justement et cela était utilisable ou du moins le -jN était nettement plus performant.
Je le remarque bien lorsque les tâches effectuées chaque nuit se mettent en route: lancer un Emacs prend plusieurs dizaines de secondes, alors que c'est habituellement quasiment immédiat (que la machine soit chargée ou non). Je n'ai pas ce genre de problème avec Linux.
Je n'échangerais pas mon Mac OS X contre deux barils de GNU/Linux ! :-p
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C3F74B5A.C7179%, Eric Levenez écrit:
Le 07/03/08 17:25, dans <20080307162016$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3F6EC14.C70BF%, Eric Levenez écrit:
L'option "-j" seule, qui lance tout en parallèle, "écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
C'est un problème avec Mac OS X: quand un processus fait beaucoup d'accès disque, les performances du système s'écroulent! :(
Je ne parlais pas de cela. Le problème est juste que lancer quelques dizaines de compilations simultanées (plus que de c¦urs disponibles), cela ralenti. Idem sur GNU/Linux.
Avec des resources infinies (excepté le nombre de cores), ça ne devrait pas ralentir. Donc c'est peut-être lié: quand on lance beaucoup de processus simultanés, il y a plus d'accès disque que dans la normale: swap, plus d'échecs concernant le cache disque... Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Dans l'article <C3F74B5A.C7179%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 07/03/08 17:25, dans <20080307162016$31f7@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C3F6EC14.C70BF%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
L'option "-j" seule, qui lance tout en parallèle,
"écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
C'est un problème avec Mac OS X: quand un processus fait beaucoup
d'accès disque, les performances du système s'écroulent! :(
Je ne parlais pas de cela. Le problème est juste que lancer quelques
dizaines de compilations simultanées (plus que de c¦urs disponibles), cela
ralenti. Idem sur GNU/Linux.
Avec des resources infinies (excepté le nombre de cores), ça ne
devrait pas ralentir. Donc c'est peut-être lié: quand on lance
beaucoup de processus simultanés, il y a plus d'accès disque que
dans la normale: swap, plus d'échecs concernant le cache disque...
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Dans l'article <C3F74B5A.C7179%, Eric Levenez écrit:
Le 07/03/08 17:25, dans <20080307162016$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3F6EC14.C70BF%, Eric Levenez écrit:
L'option "-j" seule, qui lance tout en parallèle, "écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
C'est un problème avec Mac OS X: quand un processus fait beaucoup d'accès disque, les performances du système s'écroulent! :(
Je ne parlais pas de cela. Le problème est juste que lancer quelques dizaines de compilations simultanées (plus que de c¦urs disponibles), cela ralenti. Idem sur GNU/Linux.
Avec des resources infinies (excepté le nombre de cores), ça ne devrait pas ralentir. Donc c'est peut-être lié: quand on lance beaucoup de processus simultanés, il y a plus d'accès disque que dans la normale: swap, plus d'échecs concernant le cache disque... Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Le 08/03/08 13:24, dans <20080308121804$, « Vincent Lefevre » <vincent+ a écrit :
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Tous les essais que j'ai effectué m'ont montré que Linux gère mal les priorités entre processus et thread multiples par rapport à Mac OS X. D'autres ont le sentiment inverse. Bref, tout dépend de ce que l'on fait et de comment on le fait.
Il y a quelques jours un article montrait que FreeBSD 7.0 gérait mieux le SMP que GNU/Linux. Aussitôt des Linuxiens ont démentis montrant qu'en prenant le tout dernier noyau Linux (non sorti), GNU/Linux était plus rapide. Si on ne dit pas que "Linux c'est mieux", on est accusé de FUD.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 08/03/08 13:24, dans <20080308121804$1f09@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Tous les essais que j'ai effectué m'ont montré que Linux gère mal les
priorités entre processus et thread multiples par rapport à Mac OS X.
D'autres ont le sentiment inverse. Bref, tout dépend de ce que l'on fait et
de comment on le fait.
Il y a quelques jours un article montrait que FreeBSD 7.0 gérait mieux le
SMP que GNU/Linux. Aussitôt des Linuxiens ont démentis montrant qu'en
prenant le tout dernier noyau Linux (non sorti), GNU/Linux était plus
rapide. Si on ne dit pas que "Linux c'est mieux", on est accusé de FUD.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 08/03/08 13:24, dans <20080308121804$, « Vincent Lefevre » <vincent+ a écrit :
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Tous les essais que j'ai effectué m'ont montré que Linux gère mal les priorités entre processus et thread multiples par rapport à Mac OS X. D'autres ont le sentiment inverse. Bref, tout dépend de ce que l'on fait et de comment on le fait.
Il y a quelques jours un article montrait que FreeBSD 7.0 gérait mieux le SMP que GNU/Linux. Aussitôt des Linuxiens ont démentis montrant qu'en prenant le tout dernier noyau Linux (non sorti), GNU/Linux était plus rapide. Si on ne dit pas que "Linux c'est mieux", on est accusé de FUD.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Paul Gaborit
À (at) Sat, 08 Mar 2008 17:53:24 +0100, Eric Levenez écrivait (wrote):
Le 08/03/08 13:24, dans <20080308121804$, « Vincent Lefevre » <vincent+ a écrit :
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Tous les essais que j'ai effectué m'ont montré que Linux gère mal les priorités entre processus et thread multiples par rapport à Mac OS X. D'autres ont le sentiment inverse. Bref, tout dépend de ce que l'on fait et de comment on le fait.
Il y a quelques jours un article montrait que FreeBSD 7.0 gérait mieux le SMP que GNU/Linux. Aussitôt des Linuxiens ont démentis montrant qu'en prenant le tout dernier noyau Linux (non sorti), GNU/Linux était plus rapide. Si on ne dit pas que "Linux c'est mieux", on est accusé de FUD.
Sur FreeBSD et au moins depuis la version 5, sur une machine mono-processeur et mono-coeur, les compilations vont beaucoup plus vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les compilations du noyau et du monde qui ne sont pas de petits logiciels puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités sont gérés différement...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sat, 08 Mar 2008 17:53:24 +0100,
Eric Levenez <usenet@levenez.com> écrivait (wrote):
Le 08/03/08 13:24, dans <20080308121804$1f09@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Tous les essais que j'ai effectué m'ont montré que Linux gère mal les
priorités entre processus et thread multiples par rapport à Mac OS X.
D'autres ont le sentiment inverse. Bref, tout dépend de ce que l'on fait et
de comment on le fait.
Il y a quelques jours un article montrait que FreeBSD 7.0 gérait mieux le
SMP que GNU/Linux. Aussitôt des Linuxiens ont démentis montrant qu'en
prenant le tout dernier noyau Linux (non sorti), GNU/Linux était plus
rapide. Si on ne dit pas que "Linux c'est mieux", on est accusé de FUD.
Sur FreeBSD et au moins depuis la version 5, sur une machine
mono-processeur et mono-coeur, les compilations vont beaucoup plus
vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les
compilations du noyau et du monde qui ne sont pas de petits logiciels
puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités
sont gérés différement...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sat, 08 Mar 2008 17:53:24 +0100, Eric Levenez écrivait (wrote):
Le 08/03/08 13:24, dans <20080308121804$, « Vincent Lefevre » <vincent+ a écrit :
Ça ralentit sous Linux, mais je trouve que c'est pire sous Mac OS X.
Tous les essais que j'ai effectué m'ont montré que Linux gère mal les priorités entre processus et thread multiples par rapport à Mac OS X. D'autres ont le sentiment inverse. Bref, tout dépend de ce que l'on fait et de comment on le fait.
Il y a quelques jours un article montrait que FreeBSD 7.0 gérait mieux le SMP que GNU/Linux. Aussitôt des Linuxiens ont démentis montrant qu'en prenant le tout dernier noyau Linux (non sorti), GNU/Linux était plus rapide. Si on ne dit pas que "Linux c'est mieux", on est accusé de FUD.
Sur FreeBSD et au moins depuis la version 5, sur une machine mono-processeur et mono-coeur, les compilations vont beaucoup plus vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les compilations du noyau et du monde qui ne sont pas de petits logiciels puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités sont gérés différement...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Levenez
Le 11/03/08 14:34, dans , « Paul Gaborit » a écrit :
Sur FreeBSD et au moins depuis la version 5, sur une machine mono-processeur et mono-coeur, les compilations vont beaucoup plus vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les compilations du noyau et du monde qui ne sont pas de petits logiciels puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités sont gérés différement...
"make -j4" est bien plus rapide que "make" sur ma machine avec Mac OS X, mais "make -j" est plus lent (idem sur un Linux sur une machine 2 c¦urs). Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait. Il n'y a aucune raison que le comportement de Mac OS X soit différent de FreeBSD ou de GNU/Linux.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/03/08 14:34, dans <wt93aqxfkpl.fsf@marceau.enstimac.fr>, « Paul
Gaborit » <Paul.Gaborit@invalid.invalid> a écrit :
Sur FreeBSD et au moins depuis la version 5, sur une machine
mono-processeur et mono-coeur, les compilations vont beaucoup plus
vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les
compilations du noyau et du monde qui ne sont pas de petits logiciels
puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités
sont gérés différement...
"make -j4" est bien plus rapide que "make" sur ma machine avec Mac OS X,
mais "make -j" est plus lent (idem sur un Linux sur une machine 2 c¦urs).
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait. Il
n'y a aucune raison que le comportement de Mac OS X soit différent de
FreeBSD ou de GNU/Linux.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/03/08 14:34, dans , « Paul Gaborit » a écrit :
Sur FreeBSD et au moins depuis la version 5, sur une machine mono-processeur et mono-coeur, les compilations vont beaucoup plus vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les compilations du noyau et du monde qui ne sont pas de petits logiciels puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités sont gérés différement...
"make -j4" est bien plus rapide que "make" sur ma machine avec Mac OS X, mais "make -j" est plus lent (idem sur un Linux sur une machine 2 c¦urs). Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait. Il n'y a aucune raison que le comportement de Mac OS X soit différent de FreeBSD ou de GNU/Linux.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Paul Gaborit
À (at) Tue, 11 Mar 2008 19:06:59 +0100, Eric Levenez écrivait (wrote):
Le 11/03/08 14:34, dans , « Paul Gaborit » a écrit :
Sur FreeBSD et au moins depuis la version 5, sur une machine mono-processeur et mono-coeur, les compilations vont beaucoup plus vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les compilations du noyau et du monde qui ne sont pas de petits logiciels puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités sont gérés différement...
"make -j4" est bien plus rapide que "make" sur ma machine avec Mac OS X, mais "make -j" est plus lent (idem sur un Linux sur une machine 2 c¦urs).
D'accord. Là, c'est normal. Un 'make -j' lance brutalement *toutes* les tâches en parallèles (sauf si il y a dépendance). C'est donc normal qu'on écroule la machine. Les 'make' actuels ne sont pas encore assez intelligents pour gérer dynamiquement la charge de la machine.
Donc, ça me rassure sur la gestion des priorités de Mac OS X...
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait. Il n'y a aucune raison que le comportement de Mac OS X soit différent de FreeBSD ou de GNU/Linux.
Un 'make -j' (avec beaucoup de trucs parallélisables) écroule n'importe quel OS (ou tout du moins, écroule les performances accordées par l'OS à l'utilisateur).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 11 Mar 2008 19:06:59 +0100,
Eric Levenez <usenet@levenez.com> écrivait (wrote):
Le 11/03/08 14:34, dans <wt93aqxfkpl.fsf@marceau.enstimac.fr>, « Paul
Gaborit » <Paul.Gaborit@invalid.invalid> a écrit :
Sur FreeBSD et au moins depuis la version 5, sur une machine
mono-processeur et mono-coeur, les compilations vont beaucoup plus
vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les
compilations du noyau et du monde qui ne sont pas de petits logiciels
puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités
sont gérés différement...
"make -j4" est bien plus rapide que "make" sur ma machine avec Mac OS X,
mais "make -j" est plus lent (idem sur un Linux sur une machine 2 c¦urs).
D'accord. Là, c'est normal. Un 'make -j' lance brutalement *toutes*
les tâches en parallèles (sauf si il y a dépendance). C'est donc
normal qu'on écroule la machine. Les 'make' actuels ne sont pas encore
assez intelligents pour gérer dynamiquement la charge de la machine.
Donc, ça me rassure sur la gestion des priorités de Mac OS X...
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait. Il
n'y a aucune raison que le comportement de Mac OS X soit différent de
FreeBSD ou de GNU/Linux.
Un 'make -j' (avec beaucoup de trucs parallélisables) écroule
n'importe quel OS (ou tout du moins, écroule les performances
accordées par l'OS à l'utilisateur).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 11 Mar 2008 19:06:59 +0100, Eric Levenez écrivait (wrote):
Le 11/03/08 14:34, dans , « Paul Gaborit » a écrit :
Sur FreeBSD et au moins depuis la version 5, sur une machine mono-processeur et mono-coeur, les compilations vont beaucoup plus vite en utilisant 'make -j 4' plutôt que 'make' (testé avec les compilations du noyau et du monde qui ne sont pas de petits logiciels puisque c'est *tout* FreeBSD).
Si ce n'est pas le cas sur Mac OS X, c'est peut-être que les priorités sont gérés différement...
"make -j4" est bien plus rapide que "make" sur ma machine avec Mac OS X, mais "make -j" est plus lent (idem sur un Linux sur une machine 2 c¦urs).
D'accord. Là, c'est normal. Un 'make -j' lance brutalement *toutes* les tâches en parallèles (sauf si il y a dépendance). C'est donc normal qu'on écroule la machine. Les 'make' actuels ne sont pas encore assez intelligents pour gérer dynamiquement la charge de la machine.
Donc, ça me rassure sur la gestion des priorités de Mac OS X...
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait. Il n'y a aucune raison que le comportement de Mac OS X soit différent de FreeBSD ou de GNU/Linux.
Un 'make -j' (avec beaucoup de trucs parallélisables) écroule n'importe quel OS (ou tout du moins, écroule les performances accordées par l'OS à l'utilisateur).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Levenez
Le 15/03/08 15:57, dans <1idupkc.zwa9ga1hyvo1sN%, « Xavier » a écrit :
Eric Levenez wrote:
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait.
Utilise CHUD pour "débrancher" les autres processeurs.
Avant (Mac PPC) j'avais effectivement avec CHUD un onglet dans les préférences systèmes pour désactiver un processeur (pas un c¦ur). Je n'ai rien de ça maintenant sur ma machine (Mac Intel). J'ai trouvé "Reggie SE" qui permet de voir les caractéristiques de 8 CPU, mais le programme ne semble pas capable de désactiver un processeur ou un c¦ur. Rien trouvé d'autre sur le sujet.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 15/03/08 15:57, dans <1idupkc.zwa9ga1hyvo1sN%xavier@groumpf.org>,
« Xavier » <xavier@groumpf.org> a écrit :
Eric Levenez <usenet@levenez.com> wrote:
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait.
Utilise CHUD pour "débrancher" les autres processeurs.
Avant (Mac PPC) j'avais effectivement avec CHUD un onglet dans les
préférences systèmes pour désactiver un processeur (pas un c¦ur). Je n'ai
rien de ça maintenant sur ma machine (Mac Intel). J'ai trouvé "Reggie SE"
qui permet de voir les caractéristiques de 8 CPU, mais le programme ne
semble pas capable de désactiver un processeur ou un c¦ur. Rien trouvé
d'autre sur le sujet.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 15/03/08 15:57, dans <1idupkc.zwa9ga1hyvo1sN%, « Xavier » a écrit :
Eric Levenez wrote:
Mais je n'ai pas de Mac monoc¦ur sous la main pour voir ce que cela fait.
Utilise CHUD pour "débrancher" les autres processeurs.
Avant (Mac PPC) j'avais effectivement avec CHUD un onglet dans les préférences systèmes pour désactiver un processeur (pas un c¦ur). Je n'ai rien de ça maintenant sur ma machine (Mac Intel). J'ai trouvé "Reggie SE" qui permet de voir les caractéristiques de 8 CPU, mais le programme ne semble pas capable de désactiver un processeur ou un c¦ur. Rien trouvé d'autre sur le sujet.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
laurent.pertois
Eric Levenez wrote:
Avant (Mac PPC) j'avais effectivement avec CHUD un onglet dans les préférences systèmes pour désactiver un processeur (pas un c½ur). Je n'ai rien de ça maintenant sur ma machine (Mac Intel). J'ai trouvé "Reggie SE" qui permet de voir les caractéristiques de 8 CPU, mais le programme ne semble pas capable de désactiver un processeur ou un c½ur. Rien trouvé d'autre sur le sujet.
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Eric Levenez <usenet@levenez.com> wrote:
Avant (Mac PPC) j'avais effectivement avec CHUD un onglet dans les
préférences systèmes pour désactiver un processeur (pas un c½ur). Je n'ai
rien de ça maintenant sur ma machine (Mac Intel). J'ai trouvé "Reggie SE"
qui permet de voir les caractéristiques de 8 CPU, mais le programme ne
semble pas capable de désactiver un processeur ou un c½ur. Rien trouvé
d'autre sur le sujet.
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Avant (Mac PPC) j'avais effectivement avec CHUD un onglet dans les préférences systèmes pour désactiver un processeur (pas un c½ur). Je n'ai rien de ça maintenant sur ma machine (Mac Intel). J'ai trouvé "Reggie SE" qui permet de voir les caractéristiques de 8 CPU, mais le programme ne semble pas capable de désactiver un processeur ou un c½ur. Rien trouvé d'autre sur le sujet.
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Eric Levenez
Le 16/03/08 23:08, dans <1idx49d.8fi6031rec5meN%, « Laurent Pertois » a écrit :
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
Ah, oui, c'est cela. Cela marche bien :-)
J'ai fait quelques essais de compilation d'un petit projet. Pour mieux voir les effets du -j il aurait fallu un plus gros projet sans bibliothèque (ou alors fait à la main en une fois).
---
Avec un seul c¦ur :
make -j1 : 18,7 s make -j2 : 17,7 s make -j : 17,8 s
Avec une compilation en plus que le nombre de c¦ur, cela va un poil plus vite, sûrement parce qu'il y a des attentes d'E/S disque. Le "-j" n'écroule pas le système (pas une grosse compile non plus).
---
Avec 8 c¦urs :
make -j1 : 17,5 s make -j2 : 8,8 s make -j4 : 5.3 s make -j7 : 4,3 s make -j8 : 4,0 s make -j9 : 3,9 s make -j : 4,3 s
Idem qu'avec un seul c¦ur.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/03/08 23:08, dans
<1idx49d.8fi6031rec5meN%laurent.pertois@alussinan.org>, « Laurent Pertois »
<laurent.pertois@alussinan.org> a écrit :
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
Ah, oui, c'est cela. Cela marche bien :-)
J'ai fait quelques essais de compilation d'un petit projet. Pour mieux voir
les effets du -j il aurait fallu un plus gros projet sans bibliothèque (ou
alors fait à la main en une fois).
---
Avec un seul c¦ur :
make -j1 : 18,7 s
make -j2 : 17,7 s
make -j : 17,8 s
Avec une compilation en plus que le nombre de c¦ur, cela va un poil plus
vite, sûrement parce qu'il y a des attentes d'E/S disque. Le "-j" n'écroule
pas le système (pas une grosse compile non plus).
---
Avec 8 c¦urs :
make -j1 : 17,5 s
make -j2 : 8,8 s
make -j4 : 5.3 s
make -j7 : 4,3 s
make -j8 : 4,0 s
make -j9 : 3,9 s
make -j : 4,3 s
Idem qu'avec un seul c¦ur.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 16/03/08 23:08, dans <1idx49d.8fi6031rec5meN%, « Laurent Pertois » a écrit :
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
Ah, oui, c'est cela. Cela marche bien :-)
J'ai fait quelques essais de compilation d'un petit projet. Pour mieux voir les effets du -j il aurait fallu un plus gros projet sans bibliothèque (ou alors fait à la main en une fois).
---
Avec un seul c¦ur :
make -j1 : 18,7 s make -j2 : 17,7 s make -j : 17,8 s
Avec une compilation en plus que le nombre de c¦ur, cela va un poil plus vite, sûrement parce qu'il y a des attentes d'E/S disque. Le "-j" n'écroule pas le système (pas une grosse compile non plus).
---
Avec 8 c¦urs :
make -j1 : 17,5 s make -j2 : 8,8 s make -j4 : 5.3 s make -j7 : 4,3 s make -j8 : 4,0 s make -j9 : 3,9 s make -j : 4,3 s
Idem qu'avec un seul c¦ur.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 16/03/08 23:08, dans <1idx49d.8fi6031rec5meN%, « Laurent Pertois » a écrit :
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
À noter que MenuMeters est incompatible et ne peut marcher avec.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/03/08 23:08, dans
<1idx49d.8fi6031rec5meN%laurent.pertois@alussinan.org>, « Laurent Pertois »
<laurent.pertois@alussinan.org> a écrit :
Chez moi, je l'ai retrouvé dans /Developer/Extras/PreferencePanes.
À noter que MenuMeters est incompatible et ne peut marcher avec.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
