|Jan 11, 2013, 01:43 PM||#1|
XCode development: upgrade late 2008 13" macbook to....
I'm a software developer, doing primarily mobile development for iOS and Android.
I currently use a late 2008 aluminum Macbook (Core 2 Duo), 2gHz, which I have upgraded with 8GB RAM and a "fusion-like" Seagate drive.
I normally operate it with the clamshell closed, and two 1600x1200 monitors - one driven off of the mini-display port, and one using an external USB adapter.
I've been concentrating more on jQuery Mobile development recently, and that isn't very processor-intense. (Worst thing is the Middleman static site generator I use, and that's not that bad on this setup.) But now I am going back to full-time Rhodes development, and I think I should upgrade.
A maxed-out current Mac Pro is a bit rich for my blood, so I am wondering how much improvement I might get from some other alternatives. I don't think I want to get a new notebook, as what I have is still sufficient for my travel needs (almost never) and so I don't want to pay the premium for a new notebook.
Oh, I'd like it to fit in a rackmout case. Just on a shelf is OK. Vertical-mount of a Mac Pro is not OK. I have seen a kit where you remove the "feet" and it barely fits in a 19" rack. I think then a Mac Pro would fit in 6U?
So, I am considering:
- A used Mac Pro. But I know I'd want to stick with a newer model, and this is still quite costly.
- The latest Mac Mini, with third-party memory expansion to 16GB and fusion drive. I would think that the quad-core i7, with hyperthreading (so, 8 threads) is going to beat the pants off of my Core 2 Duo mobile processor. (By how much?)
- Used Xserve? What about two monitors? The USB solution I have right now is acceptable, but there is some lag on the second screen. I'd prefer to use a second port on a built-in adapter or PCI bus card.
I beleive XCode has some distributed-build capability, so I assume I could still farm-out part of the build to my Macbook? I assume that XCode will deal with keeping prerequesites straight, and send some files to the Macbook for distributed build?
So, then, might it not be a bad upgrade strategy to just keep adding Mac Minis? I could buy 2-4 for the price of a Mac Pro (even used), and do it incrementally on an as-needed basis.
Edit: did some research, just looking at Geekbench scores. Looks like my Macbook get s score of 3641, while a 2.6gHz 4-core current Mini gets 12,809. So, 3 times as fast, but does this play-out in practice?
I would need to stick to very recent Mac Pros to best that.
Last edited by jtara; Jan 11, 2013 at 01:54 PM.
|Jan 11, 2013, 05:57 PM||#2|
1. You should first find out whether your current builds are speed-limited due to CPU, RAM (memory), or disk (I/O). Without knowing that, or at least having something better than a wild guess, an appropriate strategy may not yield the desired results.
Even if you know where the current bottleneck is, you may hit a different bottleneck after upgrading. E.g. if you're currently CPU-bound, and the Mac mini is 3X faster in CPU, you may find the mini being I/O-bound instead of CPU-bound, for a net gain of only 30% better build times. The real world is never as simple as one would like.
2. You need to find out for sure whether the Xcode you expect to use actually supports distributed builds. I honestly don't remember if that was removed or just made so decrepit as to be useless. It's been years since I had anything that even tried it.
Even the last time I tried it, there was a network bottleneck effect. You could have a super-fast remote Mac, such as a killer Mac Pro, but the compile-time was dwarfed by the transfer time for sending files back and forth. The net result is that distributed compile often wasn't worth doing. And that's if the feature even exists any more.
3. If you only rarely go mobile with the MBP, you need to consider whether mobile development is required, or whether your mobility mainly depends on mail, web browser, etc.
The fact that you're currently using the MBP in clamshell mode with dual displays suggests that little development occurs on the MBP's builtin screen. That tends to argue for a desktop main development machine, for which a Mac mini seems well suited.
I currently have 3 Mac minis, which I use for various purposes. They run different OS versions, intentionally. They also each have multiple bootable partitions with different OS versions, so I can do a "sliding range" of mixed or homogeneous OS versions, though I have not yet done that on a significant scale.
The only reason I can think of to get a Mac Pro would be for plugin cards, but maybe that's just me. On that front, there are external chassis to connect over Thunderbolt, so I'd be looking at that on a Mac mini before I went all-in on a Mac Pro.
search terms: thunderbolt card chassis
|Jan 14, 2013, 12:17 PM||#3|
Thanks for your response. You are right - I should look at CPU and IO during a long build, and see if I can determine where the bottleneck is. Finding bottlenecks in software is a bit of a specialty of mine, so I should apply it to my own equipment selection as well, doh!
I'm thinking of modding a 2012 mini to hold two 256GB SSDs in a Raid-0 configuration. Yes, I know I invalidate my warranty right off the bat, double the chance of failure (but not vs. the Apple Fusion Drive, because that uses both an SSD and mechanical drive - with the latter more prone to failure - and migrates rather than caches), probably won't see much improvement from the higher transfer rate, might have some difficult enabling TRIM, and might even see a degradation vs. a single SSD. But I figure in builds even though it involves small files, there are a lot of files and there will be an equal liklihood of any one file being on one drive or the other, and so there might be an advantage. Plus, I avoid the heat generated by a mechanical drive and don't incur the overhead of having the OS move files to the mechanical drive.
I've had good experience with SSDs. I do currently have a Momentus XT with a small SSD cache in my Macbook. And I have a separate Ubuntu system which has a 60GB SSD (only 30GB used currently) for the system and /user, (with a 1TB mechanical drive for bulk media files, backup, etc. - actually, two hot-plug drive slots).
My main concern with the Mini is the possibility of throttling if it heats-up during builds. I might slide by with a 256GB SSD, but my Macbook currently has about that much of my 512GB drive in use. I don't think I'd be putting VMWare on the Mini, though, and perhaps not my iTunes library, so if I boil it down to just stuff I need for development, I might get by with the 256, and then can just order it they way I need and not invalidate the warranty.
A current fully-loaded Mac Pro might do a better job, but it comes at an extreme premium for likely not much greater performance.
|Jan 14, 2013, 12:31 PM||#4|
I have 3 minis here, and when I do a full-bore CPU test, they don't throttle AFAICT. The fans kick up a notch or two, but that's it.
And if I were doing a RAID 0 like that, I'd test it using external drives first, just to see if there's any difference between that config and a single-drive config. I'd probably use the Firewire interface, because it has DMA capability that USB doesn't, but for completeness I'd really plan on testing with both interfaces.
|Jan 14, 2013, 01:15 PM||#5|
I have occasionally had my MacBook actually shut-down due to heating. Oddly, mostly during installs/upgrades. Very rarely, during the summer. It seems to be running hot even now, I suspect it needs a good cleaning.
The Mini isn't as difficult a thing to cool, though, as the 13" Macbook is. Much bigger fan.
I do plan on going with the 2.6 upgrade, I know that is going to cost some heat.
I do realize that I may not get much vs. a single drive in my use case. I have seen real-world benchmarks (file copy) that indicate that this would be advantageous in applications such as video editing. My main concern was my need for > 256GB and heat. Might as well RAID-0 them if I need two drives.
I'm going to review my disk usage to see if I can fit in 256G. Since this will be a fixed installation, for example, I can just move my iTunes library file location to my Ubuntu server. That's a big chunk. Hopefully, I can relocate not just iTunes music, but my iOS backups, apps, etc. because that is probably as big a chunk as my (non-work-releated, anyway...) music files.
I've got to beleive my day-to-day working set is less than 256G. When my original drive died, it was attractive to upgrade to 500G, but I've probably gotten sloppy about disk space since then.
|Jan 14, 2013, 08:30 PM||#6|
I use a 2011 Mac Mini (2.7GHz i5 DC/Radeon 16GB) at work and a 2012 11" Air (2.0 i7 DC 8GB) at home for Perl and iOS dev and don't have any notable performance problems on either.
|Jan 27, 2013, 03:46 PM||#8|
First off, for benchmarking purposes, I did a clean first.
I'm mostly building Rhodes projects. Much of that is compiling Ruby to Ruby Bytecode, so pre-compiled header doesn't apply.
There is a native library that gets built with it. It isn't pre-built into a static lib, so it does get built if you clean, but there's no reason normally to change anything there, and if you did, yes pretty sure it uses pre-compiled headers. (If that's applicable for compiling ARM code.)
No, C++, just C and Objective-C. (And Ruby.)
|Thread Tools||Search this Thread|
|thread||Thread Starter||Forum||Replies||Last Post|
|Problems transferring HDD from MacBook Late 2008 to Early 2008/Late 2007 MacBook Pro?||HIMAN1998||MacBook||7||Dec 16, 2013 10:34 AM|
|Is new Macbook Pro 15" a good choice for XCode / iOS development ?||LaravelNick||iPhone/iPad Programming||8||Nov 23, 2013 04:05 PM|
|RAM Corsair upgrade macbook unibody 13" late 2008 3 beeps||Juttersbitter||MacBook||10||Jan 30, 2013 06:26 AM|
|MacBook unibody late 2008 13" RAM upgrade crucial 8GB CT2KIT51264BC1067||Juttersbitter||MacBook||3||Jan 30, 2013 06:12 AM|
|Memory Upgrade for late 2008 macbook?||FallenAngel3284||MacBook||4||Jan 5, 2013 03:00 AM|
All times are GMT -5. The time now is 06:47 PM.