Of Intel Macs and Red Herrings

Scott Byer at Adobe put up a very nice post about the switch to intel and some of the growing pains many of us are going through. While I've added my own comments to Scott's piece, a number of my colleagues in Mac BU have asked me to weigh in on the subject here on my blog.

First off, it's difficult for me to discuss specific facts. I'm under NDA with Apple that precludes me from discussing specific issues with the transition, particularly with issues related to the tools.

Nevertheless, there are some red herrings out there, and I'm going to try to dispel a few of them.

1) Steve said it was just a recompile! What gives?

I've discussed this one before, but it bears repeating. When Steve Jobs did his demo at the last WWDC, he was talking to an audience of developers. He knew, as did every other developer in that room, that getting the code to recompile was only the first step in a long process of testing and verification. No two compilers generate code in exactly the same way, and no software developer worth the name goes through a compiler switch without extensive testing.

A few reports who've never written a line of code in their lives and who didn't actually take the time to go out and interview a variety of developers to get a different angle on the story propagated the notion that developers would be able to quickly move to Intel, but that's not what Steve was saying. Steve was only saying that the tools wouldn't be a major obstacle--or at least that Apple was prepared to get the tools to the point where they wouldn't be an obstacle.

2) Apple's been advising developers to move to XCode for years. All you had to do was follow Apple's advice.

At that time of Steve's speech at WWDC, most of the major applications weren't built using XCode. That's true for both Adobe and Microsoft. That fact alone complicates matters entirely. When this fact has been pointed out, this variation on the "Steve said it was just a recompile" meme has emerged. According to this meme, all we really needed to to was follow Apple's advice, and, well, we're the bad guys for not having done so.

While Apple did advise developers to move to XCode, Apple was rather tight-lipped as to the fundamental reason why. In the mean time, developers had to consider that advice along with the fact that Metrowerks' toolset was both significantly faster than the XCode/GCC combination and generated better code than XCode/GCC. No sane developer would sacrifice both a significant level of productivity and the quality of their product merely because Apple said so.

But all of that's very much beside the point. Whether we had gone through the pain of porting to XCode/GCC in some earlier release of our products, we'd have still had to go through this pain. The time spent doing this work then would have to have come from the features that we were, instead, adding to our programs. Arguing that we should have, somehow, absorbed this pain earlier really has little bearing on the nature and extent of the pain. We'd still have to do the work, and customers would have suffered as much then as they are now. The only difference is that, now, we have a tangibly legitimate reason for the suffering.

3) If you'd just ported from Carbon to Cocoa, your problems would have been solved.

I love this one. It so clearly demonstrates an astounding level of ignorance. I've already posted on the "Carbon vs Cocoa" issue, so I won't really belabor the point here. I'm just amazed to see people arguing that porting not only from one compiler to another but from one application framework to another would, somehow, magically be less expensive than simply porting from one compiler to the other.

4) Some apps have done it, why can't you?

In some ways, this is a legitimate criticism, but it glosses over significant differences between, say, PowerPoint or Photoshop and BBEdit. In this regard, there are two points worth considering.

The first is that the amount of work required to port a code base does not grow linearly in proportion to the size of the code base. There are a number of reasons for this, all of them related to complexity. For example, a more complex C++ program is far more likely to make use of certain language constructs (e.g. RTTI, templates and multiple inheritance) than would a less complex program. With more complex projects, the amount of work grows more on an exponential scale: i.e. twice the size of the code would require nearly ten times the amount of work to port.

The other is specifically related to GCC. GCC uses STABS to describe symbolic information so that the debugger can translate the code it's observing into symbols so that the programmer doesn't have to do this by hand. For those who care to take the time, RedHat has decent documentation on the STABS format.

The problem with STABS is that it's very verbose compared to other formats (particularly the xSYM format that Codewarrior uses). It's fairly easy to verify this. If you have XCode installed on your computer, create a simple "Hello World" Carbon project. Rename the main.c file to main.cpp (C++ generates mangled names due to overloading), and add a couple of simple classes to your app. Now, build both the debug configuration and the retail configuration. To be even safer, run strip on your retail build. Now, compare the difference in sizes between the two build.

I can't say which application, but I have it on good authority that a modern C++ application has actually hit the virtual memory wall (i.e. the combined code + generated symbols resulted in executable code larger than would fit in virtual memory). And, no, it's not an application that I've ever worked on or contributed to in any way.

 

Before I close this, I want to make two points very clear. First, I agree wholeheartedly with Scott's primary thesis: I can't imagine any developer who would prefer a long, drawn-out process of porting code from one build system to another to writing features that solve people's problems. We are already doing as much as we can possibly do. Indeed, one of the reasons I haven't posted very much as of late is because there really is a great deal of tedious work to do.

Secondly, I want to commend the tools group at Apple for the yeoman's job they've been doing to help us make the transition. I'm reluctant to name names, but I honestly wish I could. I've met with these people, and they really are an outstanding crew. Thanks, everybody. You know who you are.

 

Rick

Currently playing in iTunes: Dixie Chicken by Little Feat