This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: query reg. gcc
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Mike Stump'" <mrs at apple dot com>
- Cc: "'Shachindra Sharma'" <shachin at gmail dot com>,<gcc at gnu dot org>,<zack at codesourcery dot com>,<dalej at apple dot com>,<sdeepak at cadence dot com>
- Date: Thu, 23 Dec 2004 20:53:01 -0000
- Subject: RE: query reg. gcc
> -----Original Message-----
> From: Mike Stump
> Sent: 23 December 2004 20:32
> To: Dave Korn
> Cc: 'Shachindra Sharma'; gcc; zack; dalej; sdeepak
> Subject: Re: query reg. gcc
>
> On Thursday, December 23, 2004, at 11:10 AM, Dave Korn wrote:
> >> b) There is a long include path these files lie on the
> network disks
> >
> > *There's* your problem. Well, probably, anyway. What
> happens when
> > you run
> > the compile from local disks?
>
> Try make -j6, seriously, one a dual CPU box, -j10 maybe. For
> completeness, I'd say try each n from 1 on up, until it
> starts slowing down again, then just use that peak number.
Actually, in this case, that even ought to work well on a single CPU box, if
as I suspect there's a lot of dead time going on waiting for the network to
reply. You should end up with a number of tasks all sleeping waiting for
network packets to come in, waking up long enough to process them and going back
to sleep; the natural asynchrony of network replies should serve to parallelize
the overlapping jobs quite effectively. Depending of course on the relative
time it takes to process the contents of the average network packet-sized file
fragment as compared to how long it takes the server to retreive and send the
average chunk.
Are we talking SMB or NFS here, anyway?
cheers,
DaveK
--
Can't think of a witty .sigline today....