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