Macintosh y el cambio a Intel, según Scott Byer (Adobe)

Me gustaría poder traducir por completo el interesante artículo de Scott Byer acerca de lo que significa la transición de Mac OS X PowerPC a Intel para Adobe, y las diferencias que existen entre esta transición y el anterior cambio de chip (68K a PowerPC), pero los términos de uso de Adobe me lo impiden, así que iremos desgranando poco a poco el artículo, haciendo uso del _uso apropiado_ que todavía podemos ejercer… y añadiendo algunas cosas interesantes por el camino.

En primer lugar, “Scott deja claro que la política de la empresa”:http://www.adobe.com/products/pdfs/intelmacsupport.pdf es que no sacará versiones en binario universal de los programas de la Suite CS2, ni de las versiones actuales de los que fueron programas de Macromedia. Habrá que esperar a versiones siguientes —¿CS3, MX 2007?— para ver binarios universales. Al menos, Lightroom será universal.

En segundo lugar, Scott compara el paso de 68K a PowerPC con el PowerPC/Intel. Nos recuerda que Adobe en su momento sacó unos plugins PowerPC para Photoshop que daban en torno al 80% del rendimiento con el 10% del esfuerzo —las cifras son mías—. Y eso era posible porque Apple creó el Mixed Mode Manager, por medio del cual el código 68K, que estaba siendo emulado, podía llamar a código PowerPC nativo, y el código PowerPC nativo, a su vez, podía llamar a código 68K que necesitara emulación. Todo esto lo permitía la gestión de instrucciones no soportadas del 68K y del PowerPC, aunque el sistema se había pensado con otros chips en mente —incluso se podía soportar el Pentium, en caso de necesidad, y siempre que existiera un emulador—.

Lo cierto es que el PowerPC es un chip muy bueno para la emulación, especialmente de un chip como el 68K, que tenía algo de RISC en su filosofía de diseño, con muchas instrucciones de tamaño fijo, y muchos registros equivalentes entre sí, y la penalización de rendimiento no era tan grande. Un emulador PowerPC completo para x86, como ha demostrado PearPC, es una cosa MUCHO más lenta.

Además, la inclusión del Mixed Mode Manager permitió a Apple no tener que traducir todo el Mac OS de golpe, sino poco a poco… lo cuál a la larga no fue bueno para Apple. Pero me estoy yendo del artículo de Scott.

La cuestión es que la arquitectura de Photoshop se basa en un núcleo central que llama a muchas funciones, y la mayoría de ellas pueden ser sustituidas mediante plugins. La estructura modular del programa permitía el mantener la mayoría en código 68K —código que, además, realizaba muchas llamadas al sistema operativo, de modo que parte de las funciones se realizaban a velocidades nativas—, y llamar a código PowerPC en los auténticos procesos de información —que no llamaban al sistema operativo—. El tiempo de preparación de esos módulos, junto al tiempo de test, era muy reducido frente a la creación de la aplicación concreta.

He intentado encontrar más información sobre Rosetta que la disponible en la Guía de Programación de Binarios Universales, porque si bien está claro que un programa que se lanza como Intel no puede llamar a _plugins_ PowerPC, no se dice nada de lo contrario, pero si fuera posible, ya se habría hecho 😉

Respecto a por qué, después de todo, no es posible pasar el proyecto de CodeWarrior a Xcode y recompilar, la razón que da Scott es que aún no se ha dado el paso hacia Xcode, porque Xcode aún está por detrás de CodeWarrior en velocidad a la hora de abrir grandes proyectos, en velocidad a la hora de compilar —si bien Xcode puede distribuir la compilación entre varias máquinas, y CodeWarrior no—, en el tamaño del código compilado… y para Adobe, aún no es capaz de gestionar una aplicación mastodóntica como las que componen CS2.

Aún así, Scott reconoce que Apple está haciendo un trabajo _asombroso_ de actualización y mejora de Xcode para superar sus limitaciones, y acaba con este párrafo:

Soy ingeniero, y siempre estoy a favor de sacar productos para que los clientes aprovechen sus máquinas al máximo tan pronto como sea posible, pero es que no hay forma de que sacar un Binario Universal de Photoshop CS2 tenga sentido. Si se piensa en el cambio de herramientas, con la enorme carga de trabajo te ingeniería y aseguramiento de calidad, si se piensa en cuánto hace ya del lanzamiento de Photoshop CS2, y si se incluye el hecho de que las auténticas estaciones de trabajo aún no están listas, creo que estaréis de acuerdo: es mucho mejor que nos centremos en asegurar que Photoshop CS3 es capaz de obtener cada gramo de potencia de esas torres basadas en Intel que partirán la pana por entonces, que hacer un trabajo enorme en pasar un código anticuado a las nuevas herramientas.