Una de las cosas que se asumía cuando Apple anunció su trancisión de procesadores Intel x86 a Apple Silicon ARM64 es que por el camino se perdería cierto rendimiento en aplicaciones no adaptadas. Gracias a la capa de traducción de Rosetta, la pérdida es relativamente pequeña, de un 20% en comparación a código nativo.
Sin embargo, además de un funcionamiento más lento, las aplicaciones no nativas en el chip M1 de Apple pueden llegar a funcionar mal o directamente no funcionar, por lo que siempre se agradece que se actualicen con soporte para Apple silicon. Adobe con Lightroom y los desarrolladores de Handbrake (con una beta) se han dado cierta prisa en tener aplicaciones importantes listas para los nuevos equipos, pero para nuestra sorpresa, lo han hecho con menos rendimiento.
Resultados decepcionantes en dos de nuestras pruebas
En general, los resultados del M1 con código nativo son espectaculares, pero a la hora de probar la versión optimizada de Lightroom experimentamos algo muy raro: el M1 rendía mucho menos que Macs con Intel con procesadores de dos núcleos de hace años.
Así que opté por abrir Lighroom con Rosetta, que es algo que se puede hacer con la opción "Obtener información" sobre el ejecutable, de forma que el código que se ejecutara fuera el pensado para Intel y no para los nuevos. Lo que hace Rosetta es traducir el código de Intel a Apple silicon, y de forma automática, ha logrado hacerlo mejor que los desarrolladores de Adobe.
Tras comparar cuánto tardaba en generar una panorámica la versión nativa y la versión Intel con Rosetta, el resultado no dejó dudas de que algo está mal optimizado: la versión nativa es más del doble de lenta que la Intel. Y esa lentitud se siente extrema porque, como decíamos, el rendimiento es peor que el de equipos bastante antiguos.
En Handbrake, al convertir un vídeo de H.264 a H.265, la experiencia fue similar. Si bien la diferencia de tiempo entre ambos procesos es de mucho menos tiempo, que sea mejor con código Intel en modo Rosetta nos dice que algo va mal, porque como decíamos al comienzo, debería haber una diferencia de un 20% a favor del código nativo, según ocurre en muchos otros casos de uso.
A qué puede deberse esta diferencia de rendimiento
Para entender cómo es posible que algo así es posible, hemos hablado con Julio César Fernández Muñoz, compañero colaborador en Applesfera, desarrollador centrado en Apple y formador en Apple Coding.
Esta es la explicación que Julio nos dio sobre este "fenómeno" extraño:
Cuando una app se traduce con Rosetta (como Lightroom o HandBrake), las instrucciones que el sistema entiende que sirve para tareas que el M1 resuelve con sus chips específicos (como la codificación de vídeo) se derivan por CPU a este chip. El M1 tiene un controlador de procesos basado en aprendizaje automático (ML) que reconoce los tipos de instrucciones que le llegan y los deriva hacia el chip específico aunque no se esté usando la API correcta. Eso lo hace muy bien con la traducción de Rosetta que ya está derivada correctamente.
El mismo que tienen los Intel y que Adobe repite: usar sus propias APIs en C++ para todo, en lugar de no usar las APIs del sistema con aceleración de procesos. O Adobe lo impone, o nos dará apps nativas en Apple Silicon que serán más lentas que la traducción con Rosetta, irónicamente.
Esperemos que, sea cual sea la causa, no sea la tónica de cara al futuro en las aplicaciones adaptadas a Apple silicon. En muchas otras de las que hemos probado, como navegadores u Office, la optimización es genial. Es decir, no se trata de un problema de herramientas de desarrollo de Apple, y ningún desarrollador se ha quejado de ese problema en concreto.
Ver 8 comentarios