Re: Xcode Performance on 8-Core Macs
Re: Xcode Performance on 8-Core Macs
- Subject: Re: Xcode Performance on 8-Core Macs
- From: "Chris Espinosa" <email@hidden>
- Date: Sun, 15 Apr 2007 17:44:16 PDT
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
_______________________________________________
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