Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

make -j optimization



On Thu, Sep 30, 2004 at 01:47:20PM -0400, Brendan wrote:
> On Thursday 30 September 2004 13:42, David Kramer wrote:
> > In GNU make, you can specify a -j <n> option, to run <n> commands
> > simultaneously.  This is good.
> >
> > I'm having an argument with a coworker over whether specifying a value for
> > <n> greater than the number of the processors in the system actually does
> > any good or not.  I don't see how it can.

I/O wait.

> > In fact, specifying one fewer than the number of processors shoudl
> > have almost the same performance as specifying the number of
> > processors.

I don't see how this makes sense, unless you're talking about a large
number of processors (i.e. n>3).  On a dual-CPU system, the difference
is quite substantial, in my experience.

> I'm sure other know much more than I do, but with 2 processors, we
> always used -j3, because if one thread is waiting for something
> (input, i/o, whatever) then the 3rd process comes in and balances it
> back out.

I have read elsewhere that this is a common case resulting in
performance gain.  Some of the engineers at MCL also were in the habit
of compiling this way because they said it was faster.  I myself have
never tried it but...

> There are loads of benchmarks on this, so googling might be your
> best bet.

...indeed.  Or you can just use the time command to do it yourself.  It
shouldn't take very long, if you have SMP machines...

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040930/b176cfc1/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org