I have been using a Mac mini to port my C++/Qt based code to Mac OS X for the last 3.5 years. This is one of the early PowerPC based Mac minis, upgraded to 1GB of RAM. Being Apple hardware, it is expensive for what you get. But it has served me well. The small form factor (approx 17 x 17 x 5 cm) has also been useful in my cramped office, where I have it attached to the same monitor, mouse and keyboard as my Windows box through a KVM switch. But it is struggling to keep up with PerfectTablePlan’s ever increasing code base. A clean build of the PerfectTablePlan source into a Universal (fat) binary now takes an eye-watering 36 minutes to compile and link on the Mac mini. Building a PowerPC-only debug version still takes nearly half that time. That is painful, even just for occasional porting work.
As my main development environment is Windows, I can’t really justify the cost (or office space requirements) of a Mac Pro. So I decided to buy a new Mac mini, with an Intel Core 2 Duo processor. I did look around to see if I could find one at a discount. However, this being Apple hardware, no-one dares sell at anything significantly less than Apple’s RRP. I bought the smaller (120GB) disk variant and had the dealer upgrade it to 2GB RAM, which tests on my old Mac mini indicated should be plenty for compiling and linking. I didn’t want to do the memory upgrade myself as I know, from experience with my first Mac mini, that removing the case involves putty knives and some very worrying cracking noises.
I had all sorts of problems trying to get the right cables. Firstly I wanted a Firewire cable so I could copy the set-up across from the old machine to the new machine using Apple’s Migration Assistant software. But it turns out that the old Mac Mini has a Firewire 400 6-pin socket, whereas the new Mac Mini has a Firewire 800 9-pin socket. I ordered a 6-pin to 9-pin Firewire cable cable. Then I discovered that there is more than one type of DVI cable. The old Mac mini was attached to my KVM switch with a DVI-I cable. The new Mac mini only accepts mini-DVI or (via a supplied adaptor) DVI-D. So I ordered a dual link DVI-D to DVI-D cable as well.
Once I had the right cables things went relatively smoothly. The Migration Assistant software copied almost all the apps and data across from the old machine to the new one. It even preserved settings for the apps, e.g. the email accounts in my Thunderbird email client. I just had to re-install XCode (which wasn’t copied across) and rebuild my Qt libraries (to avoid copious warnings due to the fact they had been built with an earlier version of XCode/gcc).
To use the migration assistant you simply:
- connect the 2 machines with a Firewire cable
- start-up the old machine with the ‘T’ key depresses to put it in ‘Target’ mode
- start-up the new machine
- follow the on-screen instructions
Nice. If only it was was that easy to set-up a new Windows machine.
A quick test shows that the new Mac mini is nearly 6 times faster at compiling and linking a Universal binary of PerfectTablePlan from scratch[1]:
The time the new Mac mini takes to compile and link an Intel-only debug release of PerfectTablePlan also compares favourably with a similar build on my Windows 2.13 GHz Intel Core 2 Duo box with 4GB of RAM[2].
This isn’t a fair hardware comparison, as the two machines are using completely different compilers and linkers and the Windows box was running various background services. But it certainly shows that Intel-based Mac minis are worth considering for use as development machines.
[1] The newer machine is using a newer version of XCode/gcc.
[2] The Windows box is using Visual Studio 2005.
Successful Software 
I use the new Mac Mini to do the same thing. Quite the bang for the buck.
You can also use an ethernet cord, just did that last night with my new laptop. It’s far more common to have one of those around.
I’ve been using the Mini myself for web and game development and I couldn’t be happier. I took the risk and upgraded the harddrive to a faster 7200rpm/320gb and put in 4 gigs of memory (of which 3 gigs get used by the 32-bit OS).
The only drawback is that it’s an older model with Intel integrated graphics so it is absolutely crap at playing modern games. The latest Mini has a decent NVidia chip I think.
Pingback: Using Mac Mini for development: http://s… | Cafyn
Mac Mini is a good cost-effective option for development purposes, especially during financial crunch. Our company bought mac minis to develop iPhone apps. BTW, we use two-input switchable monitors to use the same monitor for PC and Mac computers. This also help to save some funds. Moreover, we have VNC installed on every Mac so developers can quickly help each other remotely.
For the sake of curiosity I have downloaded recently released QT development environment for Windows ‘Qt Creator IDE’. When I created few simple projects with few lines of code per file, few files per project the compilation time surprised me. Probably because of MOC compiler QT developers avoid using precompiled headers. I do not know about GCC compiler though with VC++ you could use them to reduce compilation time (once again not sure, probably MOC might be a problem). Even 383 seconds looks like disaster to me.
>Even 383 seconds looks like disaster to me.
That is a completely clean build of around 100k LOC, including code generation by the QT MOC and UI tools.
What KVM are you using; does it work well. I tried an older Belkin I had lying around but it tended to freeze up (!) occasionally and not allow input.
I am using an Avocent KVM. It is OK, but sometimes it thinks a key is stuck when you change over. So you get some key being held down permanently in a random window until you switch back. Most annoying.
I had a similar experience moving from a Dual CPU PowerMac G5 to a Quad Core Mac Pro — my Xcode build times were faster by a factor of 10-20.
To be fair, this is not indicative of the performance difference overall (the Mac Pro was closer to 2-4 times faster overall) but I think that Xcode/gcc runs much, much better on the Intel Macs than it ever did on PowerPC Macs.
Hi Andy,
The full build (completely clean) of 20K lines MFC application with VC++ 7.1 took 18 seconds. => 18 * 5 = 90 seconds. Now compare 267 and 90. I’d investigate precompiled headers option in any way. The strange thing though (As I said before) that their wizard generated applications do not use precompiled headers.
My dev. machine is quite outdated: Single core Athlon 64 bit(first generation) and 760 MB memory.
Oleg
QMake Manual -> Manual -> Using Precompiled headers
Oleg,
I have always been a bit suspicious about pre-compiled headers – but I don’t even remember why now. I will investigate building Qt with pre-compiled headers. It probably isn’t worth it for PerfectTablePlan itsself, as the headers change too much. Thanks for the tip.
I have just recently tested the /Gm (enable minimal rebuilds) setting for VS2005 and that seems to make a big difference to Windows rebuild times.
I have cracked open a couple of mac minis to upgrade the RAM, but I used butter knives instead of putty knives. Its not all that difficult. I wouldn’t do it if you are a perfectionist and would upset if the case doesn’t sit exactly lined up. C’mon, you can’t even notice! Honest!
I have opened the case on the first Mac Mini. I didn’t do it the second because:
-any damage caused wouldn’t be covered by the warranty
-the dealer did it for free
-it’s a hardware problem!!!!
I am glad if it will save you some time,
QT still building on my ancient machine, meanwhile I have some suggestions that might help you either.
I read the documentation now and it looks like code example not very correct there (at least for VC compiler it will not reduce the time of compilation. Once again I am not sure here – you have to try it yourself.
I think that correct way would be:
preheaders.h – where you have to include all qt headers
preheaders.cpp – I think this file must exist either to generate correct pch.
Then typical class in your application should look like
/// some.h
class Some
{
void foo();
}
/// some.cpp
#include “preheaders.h”
#include “some.h”
void Some::foo()
{
}
I do not think you change QT headers very often. The simplest way to understand the concept is generating some MFC or ATL application and look at their structure. (stdafx.h and stdafx.cpp)
/Gm – is very good thing but sometimes you have to rebuild whole application to fix some strange things if flag enabled.
As far as I know in VC 80 also exists flag that may enable utilizing the power of 2 cores. I never was interested in it though :)
distcc is your friend.
I have a mini under my table and the serious juice out where I don’t have to hear it or look at it.
I have been using Mac mini for developmment. I can not say that I`m satisfied with it. We bought mini`s at the end of 2007. Memory was upgraded up to 2 Gb, so it is acceptable. But Hdd is small and it is 5200 :( and it is very hard to upgrade it due to mini design. So performance is not good. imho it is easy and cheaper buy laptop, upgrade it`s memory + hdd and use windows/linux for development. mac mini is an affordable solution for mac specific (MacOS, IPhone)development tasks only.
Thanks for the great article, and many useful follow-up comments. I’m in exactly the same position – I’m about to start porting a Windows app to Mac using a Mac Mini. One question: My windows setup has two DVI monitors, connected to a dual-DVI graphics card in the PC. I’d love to use the same two screens, as well as the same keyboard and mouse, on the Mac. Is there any sort of KVM switch or similar that can handle dual-monitors, and can the Mac feed two monitors?
Hi Andy,
One more thing to add – I found that their last wizard has check box for precompiled headers generation. Everything works OK. And question – what is the purpose of creating instance of QCoreApplication and running loop in console app?
QCoreApplication a(argc, argv);
return a.exec();
Thank you Andy that you growing my curiosity regarding QT and finally I try it out myself.
>Is there any sort of KVM switch or similar that can handle dual-monitors
Not that I am aware of.
>and can the Mac feed two monitors?
Not that I am aware of.
>QCoreApplication
“This class is used by non-GUI applications to provide their event loop. … QCoreApplication contains the main event loop, where all events from the operating system (e.g., timer and network events) and other sources are processed and dispatched. It also handles the application’s initialization and finalization, as well as system-wide and application-wide settings.”
NB/ You don’t have to use QCoreApplication to create a Qt console app.
Hey I just saw your article. I use a previous-gen Mini as my main dev machine. It has the DVI-connector which I use with an older cinema display. I’m going to upgrade to the newest mini and I assumed that the supplied DVI adaptor would work work with my display.
Is that not the case? Can I use the DVD-D connector with the DVI-I cinema display?
>Can I use the DVD-D connector with the DVI-I cinema display?
I don’t remember the gory details. I suggest you ask your local Apple dealer.
Great article, which is exactly what I’m looking for :)), the power of google.
BTW, you can use Matrox for dual monitor with any vga port.
I’m setting up a small office and this is exactly what I’ve been looking at since I can’t afford to spend for 2 mac book pros.
Pingback: Speccing my dream development PC « Successful Software