Stitching the future together
Being able to compile for multiple platforms with multiple compilers, but within the same Xcode IDE, is especially important in the wake of Apple CEO Steve Jobs' plea to developers to continue building universal binaries. These are executable files that can run on both PowerPC and Core Duo processors. There's no magic to these files...in fact, there isn't really any "universality" to them, despite the marketing notion of their using a kind of Mac-inspired Esperanto.
In his own way illuminating the gulf that still exists between the two camps, Reinders explained universal binaries this way: "Apple doesn't use a term that sometimes you'll hear technologists use. 'Fat binary' is the term a lot of technologists use, because what you actually do is, you compile the program twice. You compile it once with a G5 compiler, once with a compiler producing an Intel binary, and then they're stitched together. Then the operating system takes a piece of that [executable file], when it's getting ready to load, and decides essentially which half to load."
So a fat binary may very well include the single-threaded and the multithread-capable binary streams, stitched together. To accommodate this, Apple's Xcode environment must support multiple compilers, including Intel's new ones.
Since C++ is already a fairly rigid standard, those who rely on that knowledge for their livelihood as Mac developers should be relieved to learn they can easily replace their G5 GCC compiler with Intel's C++ compiler, without implementing radical changes to their source code. But mindset shifts among the Apple faithful have never been as easy as re-socketing. Ever since Steve Jobs' days running the renegade NeXT, his developers have preferred a different object-oriented C language derivative, called Objective-C. Supporters argue the language predates C++ by a few years, and besides, is cleaner and easier to manage. And anyone gets the idea that an alternative to C++ is a bad idea, may be advised to check out Microsoft's own C#.
The Mac OS X operating system itself is written in Objective-C; and the Cocoa API, which Apple produced for developers to utilize classes, structures, and methods for the Mac operating environment, is optimized for use with Objective-C. If Reinder's argument holds true, even the operating system itself may not be utilizing the most optimum technology available for taking advantage of the Mac's newfound parallelism.
So will there be a second stage of the mindset shift down the road, leading Apple developers back toward a mainstream development path, with optimized parallelism as the reward? "I don't sense a shift one way or the other," Reinders surprised us by responding. "I know that Apple's still very committed to Objective-C. We do not currently support that in our compiler, and we don't have any plans to do that." He conceded that both C++ and C programmers who have used Objective-C with Cocoa, have noted that the tools which Apple has preferred to date are perhaps the ones best suited for the operating system.
But that doesn't mean they're best suited for the processor. Objective-C presently does include what it describes as support for multithreading. But its system of "thread detachment" is not a standardized - and many would say not a straightforward - means of accomplishing Apple's and Intel's shared goal of parallelism; more importantly, though, it isn't one that's optimized for use with Intel processors. So the possibility remains that, even as the Mac operating system itself divorces itself from the universal binary system, as it will eventually do, its own code may not be quite as optimized as it could be. As a result, whether Mac users will actually have many opportunities to observe the "2 - 3x" performance improvement that Steve Jobs proclaimed for its benchmark tests, may depend on whether enough developers both in and outside of Apple are willing to swallow their pride, and set their development course more toward the mainstream.
