Las optimizaciones de Mac OS X, por Juan de Dios Santander

Mac OS X Panther es la versión más optimizada disponible hasta ahora del Mac OS X, pero sigue siendo un sistema que necesita un equipo relativamente potente para ejecutarse con presteza. Aún así, hay que reconocerle a Apple el mérito de haber invertido esfuerzos no sólo en nuevas características, y confiar en que la llegada de equipos más potentes acelere la experiencia de cara al usuario, sino en que en la misma máquina el equipo parezca cada vez más rápido con cada versión.

De esta forma, el cambio del Mac OS X 10.0 al 10.1 fue espectacular, tanto como el cambio de 10.1 a 10.2; el cambio de Mac OS X 10.2 a 10.3 no ha sido tan drástico, pero aún así se ha notado. ¿Y qué podemos esperar de Tiger?

Historia de los cambios de rendimiento

Vamos a hablar de las diferentes versiones del Mac OS X en función de las mejoras en su rendimiento, sin hacer apenas hincapié en las características.

Apple publicó en la Mac OS X Public Beta el 13 de Septiembre de 2000, para equipos con un mínimo de 128MB de RAM, y era extremadamente lenta, especialmente cuando uno acababa de utilizar el Mac OS 9: el teclado daba la sensación de ser pegajoso, de que las letras tardaban en escribirse en pantalla décimas de segundo, lo que podía percibirse. Sin embargo, el sistema ya tenía bastante velocidad y estabilidad, y la aplicación Music Player reproducía MP3 sin cortes —salvo cuando comenzaba el disco duro a paginar como loco—. La versión Mac OS X 10.0, lanzada en Marzo de 2001, estaba más pulida que la Beta, pero constaba básicamente de la misma tecnología, y el rendimiento percibido era aún bastante decepcionante. Además, era imposible reproducir DVDs, o grabar CDs, desde el Mac OS X.

Razones fundamentales para el bajo rendimiento de la versión 10.0 del Mac OS X eran:

a) El sistema de transparencias, totalmente calculado por la CPU

b) El sistema de ventanas, basado en doble espacio de memoria del habitual por ventana, se comía la mayoría de la RAM, y era responsable de que comenzara antes la paginación

c) Código no optimizado para la apertura de aplicaciones

d) Falta de “cultura de optimización”, incluso en la propia Apple, con grandes ejecutables que se cargaban del tirón

e) Falta de optimización en Carbon

En Septiembre de 2001 Apple lanzó el Mac OS X 10.1, mucho más rápido que el anterior, debido fundamentalmente a los siguientes cambios en su arquitectura:

a) Mejoras en el núcleo del sistema, y en el código que gestionaba la apertura de aplicaciones

b) Optimizaciones en Carbon; las aplicaciones Carbon ya no ocupan el 100% del tiempo del procesador

c) Mejoras en las herramientas de desarrollo: se genera código más pequeño, y se difiere la carga de módulos no utilizados hasta el momento en que són útiles; esto disminuye la necesidad de RAM, y el uso de memoria virtual

d) Mayor uso de la programación multihebra, para permitir separar la gestión del interfaz de usuario de la gestión o proceso de datos

e) Aplicación de las técnicas anteriores a todos los programas suministrados por Apple

f) Mejoras en el Finder, que aún sufría con carpetas llenas de archivos, y con el redibujado en vivo en máquinas poco potentes

La versión 10.2, Jaguar, llegó en Agosto de 2002. Las optimizaciones fundamentales que aporta son:

a) Quartz Extreme: descarga del trabajo de composición de transparencias a la tarjeta de vídeo, si dispone de procesadores nVidia o Radeon, y al menos 16MB de RAM

b) Almacenamiento comprimido de las ventanas, para un menor uso de RAM

c) Grabación retardada para evitar fragmentación

c) Cacheo de muchas operaciones

d) Nueva mejora en los compiladores para minimizar el tamaño

e) Mejoras en el Finder, aprovechando el motor de búsqueda e indizado V-Twin; aún sigue sufriendo con carpetas llenas de miles de archivos

Y a finales de Octubre de 2003, Apple lanzó Panther, que entre otras mejoras, incluye:

a) Núcleo del sistema basado en FreeBSD 5 (los anteriores estaban basados en torno a FreeBSD 4.x)

b) Nuevas mejoras en los compiladores, incluyendo optimizaciones para PowerPC 970, alias G5

c) Bibliotecas de funciones duales, en 32 y 64 bits

d) Hotfile Adaptive Clustering: una tecnología de optimización de acceso en disco que permite pasar a una zona especial del disco duro —la de mayor velocidad de lectura, por encontrarse en la periferia del disco; si todo el disco gira a las mismas revoluciones por minuto, las zonas externas pasan más rápido por debajo de la cabeza lectora que las zonas internas— aquellos archivos de menos de 20MB a los que el sistema accede con frecuencia; en ese mismo proceso de movimiento de unas zonas a otras se produce una desfragmentación automática.

e) Mayor intensidad en el cacheo de objetos, archivos… lo que permite una sensación de velocidad creciente con la utilización del sistema; la carpeta Caches en ~/Library es testigo de ello

f) Leve mejora del Finder

En todos los grandes cambios de versión, ha habido mejoras en Cocoa que ha permitido que los autores de aplicaciones creen programas con menos líneas de código cada vez, de modo que un programa escrito para la versión Mac OS X 10.n pueda ocupar mucho menos que la versión de ese programa para Mac OS X 10.n-1, por ejemplo. Todo esto implica un menor consumo de memoria, y por tanto una mayor velocidad en la carga de los programas y un menor uso de memoria virtual.

¿Qué se prevé para la versión 10.4, Tiger, en cuanto a mejoras del rendimiento?

El propio Mac OS X actual nos deja un par de pistas, pero advierto de antemano que son simples especulaciones por parte del autor:

Actualización automática de las ventanas del Finder cuando otra aplicación cambia algo

Esto era algo que dábamos por sentado con el Mac OS clásico, pero que se perdió con Mac OS X. Lamentablemente, la forma en que estaba implementada en Mac OS 9 era la observación directa de las carpetas, algo que en Mac OS X es impensable: dedicar tiempo a “mirar”, en lugar de responder a notificaciones, penalizaría el rendimiento del sistema.

Afortunadamente, al basar Panther en FreeBSD 5, hay unas cuantas funciones específicamente pensadas para el envío de notificaciones al kernel cuando hay cambios en el sistema de archivos; podemos pensar que un próximo Finder las utilizará para devolvernos ese comportamiento tan deseable.

Optimizaciones de 64 bits

Actualmente, Panther es un sistema de 32 bits, que puede ejecutarse en procesadores de 64 bits como los PowerPC 970 gracias a que la arquitectura PowerPC siempre tuvo los 64 bits en su punto de mira. No en vano procede de la arquitectura POWER original de IBM, que ya era de 64 bits, y en la hoja de ruta del desarrollo del PowerPC, aparte de los modelos que sí se implementaron, como el 601, el 603, y el 604, existía un PowerPC 620 64 bits.

Panther proporciona ciertos servicios de 64 bits a las aplicaciones, como el uso de bibliotecas de funciones matemáticas, o el acceso a más de 4GB de memoria física, pero el espacio de memoria de cada programa sigue estando limitado a 32 bits, o 4GB. Es de esperar que Tiger pueda dar un espacio de memoria virtual de 64 bits a los programas… o al menos de 52 bits, que es el límite actual impuesto por el propio procesador 😉 Esto permitirá aumentar el rendimiento de algunos programas… ¡pero sólo de aquellos que realmente necesiten para ellos solos más de 4GB de RAM!

Multiproceso en todas partes

La necesidad de Apple de mejorar el rendimiento de sus máquinas cuando Motorola no era capaz de aumentar convenientemente la potencia de los G4 hizo que Apple comenzara a meter de dos en dos procesadores. No introdujo máquinas con un mayor número de procesadores porque la capacidad multiproceso de los G4 se veía limitada por la necesidad de compartir el bus de acceso a memoria.

Con los PowerPC 970, IBM ha proporcionado procesadores realmente pensados para el multiproceso, y las placas que Apple e IBM han creado para los PowerMac G5 proporcionan acceso independiente a cada procesador, gracias a la tecnología HyperTransport de AMD. No sería de extrañar que ahora que el PowerPC 970fx ha bajado el consumo del chip para la misma potencia, podamos ver configuraciones de cuatro procesadores en la gama Power Macintosh…

Pero es que además Apple está trabajando mucho en la creación de clúster, y la introducción de RendezVous permite descubrir qué ordenadores tienen alojados programas que pueden servir para acelerar la tarea que se está realizando en el equipo actual. Actualmente, es posible acelerar la compilación de un programa con Xcode si existen varias copias de Xcode en diferentes equipos de una red local, y también es posible hacerlo con Shake… Después del lanzamiento de un par de versiones previas de Xgrid para Panther, no me cabe duda de que Xgrid será parte integrante de Tiger, y que habrá varias aplicaciones en el sistema capaces de hacer uso de esa capacidad… ¿Quizá iMovie, o iDVD?

Rendimiento, rendimiento, rendimiento

Independientemente de la versión del Mac OS X a la que nos refiramos, Apple lleva mucho tiempo haciendo hincapié en el rendimiento percibido por los usuarios en sus páginas para desarrolladores, y estos son los puntos clave para crear aplicaciones Carbon o Cocoa que tengan un buen rendimiento en Mac OS X:

a) Pedir notificaciones, no esperar: si te dedicas a ver si pasa algo, pierdes muchísimo tiempo; si pides notificaciones de sucesos (un click, un movimiento de ventana, la introducción de un CD) sólo se llamará a tu programa cuando haya algo de interés; una aplicación Cocoa hace esto automáticamente, mientras que las aplicaciones Carbon pueden reescribirse para que lo hagan;

b) Reducir el tamaño del “conjunto de trabajo”: el conjunto de trabajo es el número de páginas de memoria virtual o real ocupadas por un programa; se puede reducir este tamaño tanto reduciendo el código, como utilizando técnicas especiales para partir la aplicación en “trozos”;

c) Utilizar ejecutables Mach-O [objectos Mach con mucho machismo encima ;-)]: una aplicación Carbon compilada en este formato sólo podrá ejecutarse en Mac OS X, pero será mucho más rápida por utilizar un formato más optimizado; una aplicación Carbon en formato PEF podrá quizá funcionar en Mac OS 9, pero será más lenta en Mac OS 9;

d) Pre-enlazar (optimizar) la aplicación durante la compilación: una aplicación no pre-enlazada tarda mucho más en ejecutarse la primera vez que el resto; una aplicación ya pre-enlazada arranca más rápidamente todas las veces —aunque el sistema de memoria virtual hace que volver a arrancar una aplicación que se ejecutó hace poco sea aún más rápido.

Desde la versión 10.2 parece que los desarrolladores realmente están asumiendo estas técnicas, y disponemos de aplicaciones que son más rápidas.

Rendimiento, swap, y placebo

De todas formas, hay quienes quieren acelerar al máximo sus equipos, e intentan exprimir hasta la última gota de velocidad. Una de las opciones que se ha vuelto muy popular últimamente es el cambio de lugar del archivo swap a una partición distinta del disco, que se ha formateado en el antiguo formato HFS (aparecido en 1985 con el Mac Plus), en lugar del HFS+ (aparecido con Mac OS 8.1) o el HFS+ con registro (aparecido con una actualización de Jaguar).

¿Qué se pretende con esta optimización? En primer lugar, al sacar el archivo swap a una partición propia, el archivo swap nunca estará fragmentado. En segundo lugar, al utilizar el sistema de archivos más simple posible para esa partición, se minimiza el número de escrituras que el sistema tiene que hacer cuando vuelca páginas de memoria a disco.

¿Realmente tiene rendimiento esta optimización? Hay quien dice que ha obtenido incrementos de rendimiento espectaculares con esta configuración, y hay quien comenta que ha perdido el tiempo al hacerlo, para no tener ningún resultado perceptible.

Soy de la opinión de que el cambio de lugar del archivo de paginación a una partición con formato HFS tiene un efecto muy limitado sobre el rendimiento del equipo, especialmente con Panther, por las siguientes razones:

a) Un disco de formato HFS no comparte el tamaño de página con el tamaño de bloque; para que lo haga, hay que dar un tamaño a la partición de poco menos de 256MB. Si el tamaño es superior, se utilizará un tamaño de bloque superior a los 4KB; si se utiliza un tamaño inferior a 128MB, el tamaño de bloque será inferior a 4KB. Cualquier diferencia con el tamaño de bloque hace que la lectura y escritura no sea óptima.

b) No todos los fallos de paginación implican al archivo de intercambio, sino al disco en el que se encuentran los programas o datos que se están manipulando —ver nota sobre el funcionamiento de la memoria virtual—.

c) Si el disco duro en cuestión es un disco rápido, y la RAM también lo es, la diferencia de tiempo entre escribir las entradas en una partición HFS y una HFS+ con o sin registro son mínimos.

d) Las lecturas y escrituras en el archivo de paginación raramente son continuas, puesto que a lo largo del mismo se van dispersando diferentes bloques de memoria, de diferentes programas, en diferentes momentos. Por eso la fragmentación no es un gran problema para este tipo de archivo.

e) El sistema de asignación de bloques del sistema de archivos HFS+, especialmente en la implementación que hace el Mac OS X, previene la fragmentación

f) Panther contiene un tipo adicional de optimización sobre discos HFS+ con registro, que no realiza en los HFS+ a secas ni en los HFS: la optimización adaptable de “archivos calientes”, o Hotfile Adaptive File Optimization. Consiste en dos partes: una desfragmentación de los archivos más utilizados por debajo de 20MB; y la colocación de los mismos en la zona más rápida —por construcción— del disco duro, que es la zona periférica. Esta optimización no se aplica a particiones que no tengan activado el registro, lo que sólo es posible en particiones HFS+.

g) En ningún momento el cambio de partición del archivo de intercambio logra minimizar el número de fallos de página que obligan al uso de la memoria virtual, ya que eso es una función de la memoria instalada, de los programas abiertos, y de los datos manipulados por los mismos.

Como conclusión, podríamos decir que esta optimización podría ser más perceptible en el caso de equipos con discos duros lentos que trabajen con grandes estructuras en memoria, pero no cuando lo que se hace es trabajar con múltiples programas a la vez…

Nota: funcionamiento de la memoria virtual

Después de tanto hablar de memoria virtual, y archivos de paginación, intercambio o swap… ¿qué son en realidad?

El concepto de memoria virtual nació hace mucho tiempo, cuando la memoria RAM era mucho más cara que ahora, y muchísimo más lenta también. En aquella época, era difícil tener un sistema con más de 64KB de RAM, pero se podían tener entre 5 y 10MB de disco duro, o lo que es lo mismo, 10*1024/64 veces más memoria en disco que en RAM.

Aquel tamaño de RAM, muchas veces, era insuficiente para almacenar todos los datos de un problema, especialmente si el sistema —para amortizar su enorme coste— se compartía mediante el uso de terminales entre múltiples usuarios. Esa necesidad hizo que se buscara una forma de utilizar el espacio de almacenamiento masivo —sí, 10MB eran masivos en la época— como si fuera RAM auténtica.

Para ello se necesita:

a) Un sistema para asignar direcciones independiente de la RAM

b) Un sistema para comprobar el uso de diferentes bloques de memoria

c) Un sistema de intercambio de datos entre memoria y disco

Para simplificar, supongamos que iniciamos varios programas, que ocupan 8KB cada uno. Cuando hayamos lanzado 8, habremos cubierto los 64KB de memoria que tenemos. ¿Qué pasará cuando lancemos un noveno programa?

En primer lugar, el sistema operativo consultará qué bloques de memoria física —páginas— han sido los menos usados, hasta encontrar los 8KB que nos hacen falta. Volcará esos 8KB a disco, y cargará en memoria física un nuevo programa que ocupará 8KB en total. Si entrara un décimo programa en memoria, se haría lo mismo.

Puesto que para poder acceder a los datos en un disco éste se divide en diferentes bloques, lo normal es hacer coincidir el tamaño de bloque en disco con el tamaño de página. Si tenemos una zona del disco dedicada en exclusiva a la memoria virtual, no necesitaremos crear un archivo específico. Si en cambio utilizamos un “archivo de intercambio”, o “swapfile”, será necesario utilizar operaciones de lectura/escritura estándares, incluyendo el cambio de tamaño del archivo en el catálogo del disco cuando crezca.

Otra forma de utilizar la memoria virtual es utilizando “archivos vinculados a memoria”. Esto no implica espacio de intercambio, sino que cuando se intenta abrir un archivo no se carga en memoria, salvo que se vaya a acceder a alguna parte del mismo. Esto se utiliza para el código de los programas, que normalmente es de sólo escritura. Así, si se busca espacio en memoria física, se puede liberar la de un programa que no esté en uso sin tener que escribirla a disco, puesto que se recuperará directamente del archivo en el que se encuentra el programa.

¿Qué pasa si todos los programas están activos? Pues que el sistema los va rotando por el disco, de forma que escribe a disco la memoria que haga más tiempo que no se borró, luego la siguiente, y así sucesivamente, de modo que el disco no parará de leer y escribir, y apenas habrá tiempo para hacer otra cosa: a esto se le denomina “disk trashing”, o “basureo del disco”, y prácticamente paraliza el sistema.

Esto es especialmente grave si afecta al propio sistema operativo: por eso existe la posibilidad de marcar ciertas zonas de memoria como “cableadas”, o “wired”, y siempre permanecen en memoria física, permitiendo que exista la posibilidad de matar aquellos procesos que estén enlenteciendo el sistema.

En aquellos primeros momentos, el espacio de memoria virtual tenía entidad propia en el disco, y no formaba parte del sistema de ficheros. Sistemas operativos como Linux aún viven esa herencia, y necesitan una partición específica, en la que no puede haber jamás ningún otro archivo, para el archivo de intercambio.

Bibliografía

Artículos de John Siracusa sobre el Mac OS X en ArsTechnica:

http://arstechnica.com/reviews/4q00/macosx-pb1/macos-x-beta-1.html

http://arstechnica.com/reviews/01q2/macos-x-final/macos-x-1.html

http://arstechnica.com/reviews/01q4/macosx-10.1/macosx-10.1.html

http://arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-1.html

http://arstechnica.com/reviews/003/panther/macosx-10.3-1.html

Notas de Apple sobre Optimización para Mac OS X:

http://developer.apple.com/performance/appperformance.html

Nota Técnica sobre el formato HFS+:

http://developer.apple.com/technotes/tn/tn1150.html

Artículo en la KB sobre la fragmentación de disco:

http://docs.info.apple.com/article.html?artnum=25668

0 0 votos
Article Rating
Subscribe
Notify of
9 Comments
Oldest
Newest Most Voted
Opiniones Inline
Ver todos los comentarios
Anónimo
Anónimo
19 years ago

Un gran trabajo. Gracias por escribir un artículo así de claro y conciso.

Anónimo
Anónimo
19 years ago

Un excelente articulo.
Un saludo.

Anónimo
Anónimo
19 years ago

Magnífico

Anónimo
Anónimo
19 years ago

Solo un apunte, HyperTransport no es de AMD, es del HyperTransport Consortium.. (http://www.hypertransport.org/)

Inicialmente fue idea de AMD, pero la especificación final se desarrolló con un montón de fabricantes..
Vamos, que 100% de AMD no es..

Anónimo
Anónimo
19 years ago

Es el mismo caso que el FireWire… y nos hartamos de decir que es de Apple 😉

Anónimo
Anónimo
19 years ago

Este artículo es buenísimo. Enhorabuena.

Anónimo
Anónimo
19 years ago

¡plas! ¡plas!

Para cuando el próximo…

Anónimo
Anónimo
19 years ago

Para quitarse el sombrero y no perder tiempo en pruebas inútiles.
Hala, ahora mismo sigo haciendo lo de siempre: usar el ordenador, no dejar que el ordenador me use a mí, como en el caso de los peceros.
Un saludo 😉

Anónimo
Anónimo
16 years ago

Tengo un Mac Intel con 250Gb de disco duro, 1Gb de memoria, desde hace unos dias me sale una informacion que dice: su disco de arranque esta casi lleno, con whatsize, solo tengo ocupados 33 Gb del disco duro, pero en iformacion de Mac solo me queda libres 55Gb. He desinstalado programas, pasado applejack, pero sigue igual. ¿Alguien sabe por que pasa esto y la solucion?

9
0
Me encantaría saber tu opinión, por favor, deja un comentariox
()
x