On Wed, Jun 02, 2010 at 09:05:34PM -0400, Jack Howarth wrote:
> On Wed, Jun 02, 2010 at 08:47:54PM -0400, Alexander Hansen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 6/2/10 8:43 PM, Jack Howarth wrote:
> > > On Wed, Jun 02, 2010 at 08:36:58PM -0400, Alexander Hansen wrote:
> > > On 6/2/10 8:26 PM, Jack Howarth wrote:
> > >>>> On Wed, Jun 02, 2010 at 08:04:20PM -0400, Benjamin Reed wrote:
> > >>>> On 6/2/10 7:55 PM, Jack Howarth wrote:
> > >>>>>>> One possible workaround might be to change gcc45.info
> > >>>>>>> to reduce the number of parallel builds so that the
> > >>>>>>> load sensitivity is reduced. So instead of using...
> > >>>>>>>
> > >>>>>>> num_cpu=$(echo `sysctl -n hw.ncpu`)
> > >>>>>>> make -j $num_cpu
> > >>>>>>>
> > >>>>>>> we would reduce num_cpu by one if greater
> > >>>>>>> than one so that the build is either serial
> > >>>>>>> or leaves a free core whenever building in parallel.
> > >>>>>>> This won't 'fix' the problem but it might make
> > >>>>>>> it less likely.
> > >>>>
> > >>>> So if GCC's build is not repeatably compatible with -jN, then it
> > >>>> should probably not be doing it by default. :P
> > >>>>
> > >>>>> This is a recent regression upstream. The question is do you
> > >>>>> penalize all users with multiple core machines for those
> > >>>>> unlucky users running two cores at high load? As I said before,
> > >>>>> a rational (and less extreme) workaround would be to leave
> > >>>>> a free core available to reduce the load on the machine.
> > >>>>> I build gcc trunk nightly and have never seen this failure
> > >>>>> on a dual quad.
> > >>>>> Jack
> > >>>>
> > >>>>
> > >>>>
> > >
> > > I'll point out that I had my single instance of this failure on a
> > > single-core powerpc, and had no such problem building on a two-core
> > > Macbook under load.
> > >
> > >> Are you sure you're not confusing the issue with...
> > >
> > >> cp %b/gcc/config/darwin-sections.def
> > >> %i/lib/gcc4.5/lib/gcc/%m-apple-darwin${darwinvers}/%v/plugin/include/config
> > >
> > >> on powerpc? I suspect these are totally different problems. The compiler
> > >> plugin support apparently isn't installing the plugin header directory
> > >> on powerpc-apple-darwin. As I mentioned before, this cp comamnd can be
> > >> skipped on powerpc because there will never be a dragonegg compiler
> > >> plugin for powerpc (only i386 and x86_64 darwin).
> > >
> > >
> > I'm not confusing anything. I mentioned earlier in this thread that I
> > had an instance of _this_ problem:
> >
>
> So that implies that the parallel build on even a single job
> can trigger the problem. Definitely there is little reason to
> parallel build on a single core so we could limit the parallel
> builds to machines with more than two cores for safety.
In general, using more -j than core on one/few-core systems actually
does increase overall build speed. It lets the the build process take
advantage of (for example) I/O in one thread while heavy CPU in
another. Saturate multiple resources rather than having one mostly
idle waiting for another. No idea if there is a limit beyond which it
no longer helps ("always something wanting disk" or "not enough
parallel-izable tasks without queuing for disk").
dan
--
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
