A small developer's perspective on Apple's move to Intel


Apple has decided to move to Intel processors. How will that impact a small developer like cf/x?

In case you have spent the past days under a rock, here's the short summary of the most eventful mac development headline: Apple plans to transition from currently PowerPC-based Macs to Intel-based Macs in two years. What does that mean to you as a user, and how will it impact us, as a developer?

From The User's Perspective
The user perspective is rather indifferent. Apple has an impressive track record when it comes to switching architectrues, and have the required (if not unique) know-how to make a user's transition almost painless. surely, there will be some hick-ups. A few applications may not work any more, or work but appear a bit sluggish, or exhibit the occasional unexpected behaviour. On the whole, however, we expect that the problems associated with running a new Intel-based Mac won't be more troublesome to you than, for example, a switch from OS X 10.3 "Panther" to 10.4 "Tiger". It will most likely be less troublesome than what those people went through who switched from Windows NT to Windows 2000 Pro. Apple has demonstrated that it has the technology, the tools, and the know-how in place. as a user, the transition will (hopefully) be a smooth one.

From A Developer's Perspective
From a developer's standpoint, a switch to a new processor, no matter how great the tools, the know-how, and the reality-distortion-field, is always an earth-shaking event. To put it into perspective, imagine that you are running business (for example a graphics workshop). Everyone in your shop works according to written instructions, and these instructions are followed by the letter. You have invested a lot of time fine-tuning the instructions so everyone not only understands them correctly, but is also able to execute them. Now imagine you try to open the same workshop in a country that has a different culture, and that speaks a different language. Not only will you have to translate the instructions (this can be done rather quickly). The biggest problem is that different cultures simply behave differently, and a instructions that make sense, and work flawlessly in one country may simply fail in another.

With processors it is simlar. While it is relatively easy to simply translate the instructions from one processor (country) to another, it doesn't necessarily mean that the result will work. The surrounding architecture (culture) may be so different that the translated code fails. Fitting the translation to the new culture is the challenge that every developer faces.


cf/x's perspective
Apple has invested quite a lot into making the transition less painful for developer. Note that no matter how well it was presented at the WWDC 05, or what some publications claim, a transition is never 'easy'. This is simply because even if the transition was a quick and efficient process, it would still take time and resources to turn a working program into the same working program for the other architecture. There is no added value for an investment of effort. And this hurts a small developer. We have over a hundret plug-ins that need to be transitioned. Even if we were able to update a plugin a day, we'd still be facing an investment of 100 days - without any immediate benefit other than that we can continue to sell our products. 100 days we would have preferred to invest into new products. But the investment is likely to be much higher.

Where we are now
cf/x develops plug-ins for iMovie. These plug-ins are developed using an environment called 'Code Warrior' which was the preferred development environment when we transitioned to OSX. It is also still regarded as being superior in many ways to Apple's (very good) own development system called 'XCode'.
When the Mac was originally developed, it used a a programming language called 'Pascal', a language that was invented by Swiss professor Nikolaus Wirth, and since our engineers are educated by the Swiss Federal Institute of Technology (ETH), our programming language of choice. Even though this choice brings it's own problems (see later), it has protected us from the traps of writing processor-specifc programming. Had we, for example, programmed specifically for PowerPC's AltiVec (which doesn't exist on the Intel processor), we would have faced another, very difficult hurdle.

Do we have to transition our code?
The simplest approach would of course be to do nothing. Apple has demonstrated a brilliant piece of software called 'Rosetta' thatenables the Intel processor to run the original PowerPC code. However, we expect that this will not work for our products for two reasons:
- iMovie, the hosting application, is most likely fully ported to Intel, and we do not know if it's plug-in architecture will support a switch to Rosetta on-the-fly
- more important, however, is that Rosetta inflicts a heavy performance toll. Initial findings on the net indicate that Rosetta performs at roughly 25% to 50% of normal processor performance (which, nevertheless is an impressive achievement). Our plug-ins are processor-intensive video processing programs. A user would find it unacceptable if their new, high-performance Mac performed at one quarter of their capability.
So, yes, we must transition our code. There is no way around it.

The road ahead
The required development system for transitioning to OS X Intel is Apple's XCode. XCode, however, does not support Pascal. This means that in order to transition a plug-in to OS X Intel, we'll have to complete the following steps:
- re-write the whole plug-in in C (this will probably be done on CodeWarrior)
- port the code from CodeWarrior to XCode
- port the Code from PowerPC to Intel
- test, correct, and publish

This translates into the following: for each of our over 100 plug-ins we will have to complete four separate steps. And each step requires some effort, just to keep the satus quo. Our initial estimates are that we will require 50 to 100 days alone to transition the first plug-in (which will include porting our effect core), and from that moment on two to three days for each plug-in. That amounts to 300 days of investment which won't be easy to recapture. To this we'll have to add the $1000 required to rent a test machine. This means that cf/x will face an uncertain, and certainly difficult future. If anything, the next two years will see a significant decrease in new plug-ins while we transition our existing ones.

To sum up
So, in a nutshell, what does the new direction Apple is taking mean for us?
While the new processor may mean more performance, and hopefully a larger market, it definitely demands a heavy burden, and up-front investment that can easily break a small developer like us. We are cautiously optimistic that we can do it - but not thrilled that we have to do it. After all, we're betting the farm on it.

Posted: Thu - June 9, 2005 at 05:55 PM      

©