• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Distributed build overhead and Mac Mini vs XServe pricing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed build overhead and Mac Mini vs XServe pricing


  • Subject: Re: Distributed build overhead and Mac Mini vs XServe pricing
  • From: Scott Tooker <email@hidden>
  • Date: Sun, 16 Jan 2005 11:22:05 -0800


On Jan 16, 2005, at 9:48 AM, Andrew Kimpton wrote:


Scott Tooker wrote:


I believe that the Mac Mini has a 4200 rpm drive so the I/O performance is not going to compete with the faster disks you find in the G5 PowerMac or the xServe. However, as you point out the price for a Mac mini is much lower, so using more Mac Minis may compensate (don't know since I've never tried).


That's quite slow by current standards (I guess there's quite a price saving). My PowerBook G4 has the 5400 RPM drive, but that's still a bit faster. During a distributed build is the local drive used for retrieving framework headers etc. ? Or does the data coming across the net include a fully precompiled set of headers with everything in it? Avoiding swapping would be the other key thing - the minis are really no bargain at all with the Factory installed 1Gig Ram (add nearly $500 !), perhaps the more modest 512MB for an additional 75 bucks would be better value.

Hmm, take that 4200 figure with a grain of salt. I though I saw that up on the Apple web site, but now I can't find it. So I'm not sure how fast the drive is, but it's not going to be as fast as our higher performance machines.


As to how distributed builds works, if you are using a PCH then we create it on the local machine and push it out to all the remote builders. We also preprocess all files locally and then push out the preprocessed sources to the remote builders. Also, all copying of headers and resources into the final product and linking occur on the local machine.

Since compilation is usually an I/O intensive process I think 512MB would be fine for a builder, as long as it is not doing a ton of other stuff.


The rule of thumb I go by is to start with 4 to 6 remote builders and then increase from there if you are using a fast local machine.

Yep - I'm thinking that starting with 4 may be a good way to start, I suspect we may even have other users for the machines around the office (upgrading old iMacs on office desks etc.) if we find that the Minis really don't cut it. We'll see what management says :-)


The local machine needs to perform all preprocessing for the remote build servers, so 6 remote builders will place more strain on the local machine than 2 remote builders.


Yep - I've found that a slow machine doing the 'coordination' can have a overall build performance improved if it does NOT include itself in the distributed build farm but rather is just 'running the build'.

Yeah, I've actually changed this for the next version of Xcode so you can't have the local machine participate by default.


Scott


Scott


Andrew 8-)





_______________________________________________
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


References: 
 >Distributed build overhead and Mac Mini vs XServe pricing (From: Andrew Kimpton <email@hidden>)
 >Re: Distributed build overhead and Mac Mini vs XServe pricing (From: Scott Tooker <email@hidden>)
 >Re: Distributed build overhead and Mac Mini vs XServe pricing (From: Andrew Kimpton <email@hidden>)

  • Prev by Date: Re: Carbon with UNIX
  • Next by Date: Re: Carbon with UNIX
  • Previous by thread: Re: Distributed build overhead and Mac Mini vs XServe pricing
  • Next by thread: Re: Distributed build overhead and Mac Mini vs XServe pricing
  • Index(es):
    • Date
    • Thread