Re: 6 DAY compile! Any volunteers for distributed build CPU sharing?
Re: 6 DAY compile! Any volunteers for distributed build CPU sharing?
- Subject: Re: 6 DAY compile! Any volunteers for distributed build CPU sharing?
- From: "Dirk Stegemann (Mailing-Lists)" <email@hidden>
- Date: Thu, 14 Jun 2007 11:18:42 +0300
Hello,
Am 14.06.2007 um 05:28 schrieb Laurence Harris:
You might be surprised. I seem to recall that some people find
Xcode's performance better using 4 cores than 8, at least in some
situations.
An Apple engineer (Chris Espinosa) wrote a detailed explanation on
the Xcode list some time ago (see e-mail attached below).
Am 14.06.2007 um 10:04 schrieb Laurence Harris:
Oh, and it just occurred to me that distributed builds only work
with the same kind of processor, so you'd need to distribute to
PowerPC Macs. You can't distribute from a PowerPC to an Intel or
vice versa IIRC.
That's correct -- and if *I* remember correctly, cross-architecture
distributed building will be possible in Leopard. Maybe only when
targeting Mac OS X 10.5 alone, let's not hope for that...
Best,
Dirk Stegemann
----- snip -----
Von: Chris Espinosa
Datum: 16. April 2007 03:44:16 GMT+03:00
An: email@hidden
Betreff: Re: Xcode Performance on 8-Core Macs
This is an interaction between the Tiger kernel architecture and
gcc's precompiled header mechanism. We made some fixes in the
10.4.9 kernel to address it, but the complete fix is in the Leopard
kernel.
Basically, a precompiled header is a binary dump of gcc's process
space at the end of processing the prefix header and before
compiling the source file. When gcc is given a pch, it memory-maps
it in and then begins compiling the input file.
Since gcc needs to write to its memory once compilation begins, the
pch file is mapped read-only, which means the kernel marks its
pages copy-on-write (COW). When gcc writes to a memory page, it's
copied and detatched from the mmapped pch.
When you run multiple gcc jobs in parallel, and they share the same
pch, the kernel can get saturated making the initial copies of the
pages from the pch file. Performance starts to degrade after 4
parallel instances of gcc on Tiger. (You still have the other 4
cores available for other threads in Xcode, such as indexing,
processing the build log, and updating the dependency graph, so your
OctoMac is not going to waste).
The kernel in Leopard is much more efficient in handling heavily
parallel COW scenarios, so no changes in gcc or Xcode will be
necessary to make this work better in Leopard. We haven't done a
dot-release of Xcode since the 8-ways were launched, and we'll
consider capping the number of parallel gcc invocations that use
the same pch so we don't hit this pathological case in Tiger.
For now, setting the expert setting to limit the number of parallel
gcc instances seems to be the best bet.
Chris
----- snip -----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden