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 | Blog | 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 Fri, 1 Oct 2004, Derek Martin wrote:

> 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.

This is a 4-way AIX box running AIX 5.2.

> > 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...

Major DOH!

Apparently make is not smart enough to not build things it doesn't have 
the dependencies for yet.  Huh?  Make has one function and one function 
only: build dependencied before the things that need them.  

I was trying to compile Rogue Wave.  There are about 20 or 30 .o target
files that get build from .cpp files.  Then there's a library that gets
built from the .o files.  Even though the makefile correctly had the .c
files as dependencies for the .o files, and the .o files as dependencies
for the library, it tried to "ar" the library together before all the .o 
files were created, resulting in about half of them being "not found".

That blows.  How could they get that wrong?  If it's not going to be smart 
enough to try building a target until its dependencies are built, then at 
least only parallelize the commands to build one target at a time.


----------------------------------------------------------------------------
DDDD   David Kramer         david at thekramers.net       http://thekramers.net
DK KD  
DKK D  "I still say a church steeple with a lightening rod on
DK KD  top shows a lack of confidence." 
DDDD                                                           - Doug McLeod 




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