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 |
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 | |
We also thank MIT for the use of their facilities. |