|Jan 11, 2013, 02: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 02:54 PM.
|Jan 11, 2013, 06: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, 01: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, 01: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, 02: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, 09: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 14, 2013, 10:17 PM||#7|
Simple suggestion: Don't run the Android emulator.
I have Eclipse set to automatically build to my dropbox with each save. All of my Android test devices are hooked up to the same dropbox account and I just go down the line tapping the file / replace / install / launch. It's worlds faster and much easier than using the emulator.
Edit: Of course, I'm talking about work where I've been given a large budget with which to buy equipment (including the dozen test devices)... I guess you're a bit more budget constrained (which I understand... I can't afford to replace my 2006 MBA or 2007 iMac at home...)
Don't tell me Macs don't last: 2007 iMac, 2007 Mac Mini, 2008 MacBook Air, all Vintage.
(iMac obsoletion: April 28, 2015, MBA: October 14, 2015, Mac Mini: March 9, 2016)
|Jan 16, 2013, 06:23 PM||#8|
I did a simple test building a fairly large Rhodes project for device, and using Activity Monitor. Not a very sophisticated test, but gets me the basics. My results may be useful to others.
In this scenario XCode build is CPU limited. It ran 100% CPU for most of the build. Disk activity was mostly reading, with a pretty low overall rate, but a peak of 70MB/sec. Write activity was even less, with peaks at maybe 50MB/sec.
Keep in mind I am currently using a Momentus XT hybrid drive with a small flash, but certainly big enough to build the project without touching the mechanical.
Based on this, I don't think the RAID-0 will buy me anything. So, I'll go with either the 256G single flash drive or the Fusion option. I suppose the latter will be less hassle overall, as I won't have to worry about pruning my drive, but then I will have to tolerate any heat problem it brings (along with the 2.6gHz option) and reduction of reliability.
My test build took 2:45. I have another project that takes much longer. I'll report back with that, and with the difference with the Mini, assuming I go ahead with that.
|Jan 23, 2013, 09:56 PM||#9|
I ordered the 2.7gHz i7 with Fusion drive and 4GB RAM.
I decided to splurge on RAM. I ordered a set of Kingston KHX16LS9P1K2/16 2x8GB directly from Kingston (out of stock everywhere, and, 48-hour delay direct from Kingston - in very short supply). These cost nearly twice as much as low-end RAM, but I think it is prudent. These are CL9 at 1600 and 1.35V. My aim is to reduce the heat load - given the highest-clocked i7 and the two drives - and at the same time gain a bit of performance.
So, I won't be doing any mods to install RAID-0 SSDs.
Will report back once I have this set-up.
|Jan 24, 2013, 03:27 PM||#10|
Aside: Wow, I can't say enough about Kingston customer service!
I'd called them yesterday because I couldn't find the LoVo CL9 RAM I wanted in stock anywhere. They told me that they were out of stock, but had 11 sets coming in in the next 48 hours. So, I went ahead and ordered directly from Kingston.
Turned out they either did have them or got them in the same day. The order went out yesterday (same day I ordered) and arrived this morning by Fedex overnight.
And they included a 25-anniversary 8GB USB flash drive at no cost, to boot.
|Jan 26, 2013, 03:52 PM||#11|
Got the Mini yesterday, after a hiccup with the address label. (Sent back to UPS off the truck for relabelling, so a day delay.)
Hooked it up to my living-room TV for initial setup, and immediately had sleep/HDMI issues.
Apple support wasn't very helpful. I wasn't sure if I could wake it up with the power button like on a MacBook or what. Rep said hit any key on the keyboard, but that didn't work. I had to figure out myself that only the System key will wake it up. (At least on a PC USB keyboard. Windows key... rep wasn't very happy with that, LOL, he was like all bets are off not an Apple keyboard...)
Then the picture went wacky and had to reboot to get it back. Mostly just a blue screen with only parts of the UI showing. On occasion, swiping the mouse would reveal parts of the UI.
Was told I shouldn't plug the HDMI into my Denon AV receiver but instead directly to the TV. Didn't help. So, switched to the DP port, but not a good solution, as I need to use both ports for my work. (Need to run two DVI monitors.)
After I disabled sleep the problem hasn't recurred, knock on wood. I think it just doesn't restore the video properly after sleep. On the HDMI port it blinks once when you plug it in, doesn't do that on the DP port with an HDMI adapter, but other than that haven't seen the problem again.
Ran GeekBench, then installed my 16GB Kingston 1600/CL9 LoVo (1.35V) RAM, and ran GeekBench again. I'll share those results in detail when I have a chance, but there was an improvement in the overall score (64-bit) from 12750 to 13250, certainly modest. But much bigger improvements in some specific memory scores, some as much as 20-30% (like bandwidth).
Ran an 8-hour stress test with GeekBench with no errors and performance in a very tight range which I assume means the CPU was not throttled.
It did run very hot, like 210 degrees F on the cores. Cooled down very quickly once I stopped the test, so assume will be OK for routine development use.
|Jan 27, 2013, 04:46 PM||#13|
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 11:34 AM|
|Is new Macbook Pro 15" a good choice for XCode / iOS development ?||LaravelNick||iPhone/iPad Programming||8||Nov 23, 2013 05:05 PM|
|RAM Corsair upgrade macbook unibody 13" late 2008 3 beeps||Juttersbitter||MacBook||10||Jan 30, 2013 07:26 AM|
|MacBook unibody late 2008 13" RAM upgrade crucial 8GB CT2KIT51264BC1067||Juttersbitter||MacBook||3||Jan 30, 2013 07:12 AM|
|Memory Upgrade for late 2008 macbook?||FallenAngel3284||MacBook||4||Jan 5, 2013 04:00 AM|
All times are GMT -5. The time now is 11:25 PM.