En el grupo de discusión de los desarrolladores, uno de ellos planteó la inquietud de por qué el navegador se percibe ridículamente más rápido en Linux comparado a las versiones para Windows y Mac, lo que originó un interesante debate acerca de cómo el sistema operativo influye en una aplicación de este tipo.

En la discusión se exponen algunos detalles de implementación que hacen que en Linux algunas aplicaciones corran con ventaja gracias a decisiones de diseño tanto por el lado del sistema operativo como de la misma aplicación.  Por ejemplo indican que crear un proceso en Windows es mucho más caro en términos de uso de recursos y esto afecta la creación de nuevos tabs, ya que justamente en Chrome se trata de nuevos procesos.  En el caso de Linux, el sistema en general es más ligero y por lo tanto hace menos cosas en operaciones de este tipo.  Una de las posibles soluciones planteadas es tener siempre un proceso creado en forma anticipada, de tal forma de que cuando se necesite no tenga que esperar el proceso de inicialización.

X.org comienza a mostrar su nueva cara

Otro aspecto importante es la forma en que se manejan los gráficos.  En el caso de Windows se pueden usar dos tipos de gráficos : DIB (independientes del dispositivo) y DDB (dependientes del dispositivo).  En el primer caso se crean en memoria normal y luego se copian a la memoria de video, con el problema adicional de que se deben aplicar transformaciones desde una representación genérica a la representación física o final que se requiere y no siempre puede usar aceleración por hardware.  En el segundo caso, los DDB,  no se requiere tal transformación y una copia puede hacerse con un simple comando ejecutado por la GPU (bitblt), pero el diseño de Windows pone un límite artificial a la cantidad de gráficos que se pueden manejar como DDB, lo que lo convierte en un recurso escaso y poco apetecible por los desarrolladores de aplicaciones.

En el caso de Linux y pese a todo lo que la intuición puede decirnos acerca del tamaño y complejidad de X.org, este tipo de operaciones está muy optimizado, sobre todo en la última generación de drivers que utilizan gestión de memoria unificada en el kernel (GEM), específicamente usando la arquitectura de aceleración UXA.  En este caso las copias de bloques de memoria se reducen al mínimo, y dejar disponible un gráfico en la GPU es una operación acelerada por hardware.  Es tanto así que cuando se inició el desarrollo experimental de UXA en X.org se midieron mejoras en el rendimiento de hasta un 60%.

Por otra parte, según los mismos desarrolladores de Chromium, la forma en que se están creando los gráficos no siempre usa aceleración por hardware, mientras que en el caso de Linux, gracias a las nuevas arquitecturas de aceleración, primero EXA y luego UXA, todas las operaciones comunes se realizan con aceleración por hardware.

En el caso de Mac, los desarrolladores de Chromium dicen que aún no se han enfocado en optimizar el rendimiento, por lo que no tiene mucho sentido discutirlo en este momento.  De todas formas, los usuarios de Windows no deben preocuparse porque ya se han creado los registros en el sistema de seguimiento de bugs de Chromium para solucionar los problemas de rendimiento percibidos.

Links:
- Why is Linux Chrome so fast? (Chromium-dev)
- GEM The Graphics Execution Manager (LWN.net)
- Chrome más rápido en Linux que en Windows y Mac OS (CHW.net)

(cc) Ruth Bourne

Intel ha estado desarrollando activamente muchos cambios para mejorar el sistema gráfico de Linux, aplicando numerosas mejoras no sólo en su driver sino que a nivel de toda la infraestructura, incluyendo el kernel.

Con estos cambios, tanto el rendimiento, el uso de recursos y la experiencia del usuario se verán beneficiados a medida que los otros drivers comienzan a usar los nuevos componentes que Intel ha integrado en el sistema, como es el caso de Graphics Execution Manager (GEM), Kernel Mode Setting (KMS) y UMA Acceleration Architecture (UXA) que es la arquitectura de aceleración basada en GEM que viene a reemplazar al reciente EXA y al ya añejo XAA.

Hace un par de semanas Intel liberó la versión 2.7 de su driver xf86-video-intel, pero ya hay una nueva versión de prueba en miras a convertirse en la versión 2.8.  Normalmente, esto toma dos a tres meses, pero esta vez decidieron aplicar cambios rápidamente, y cortar por lo sano, literalmente.

Intel ha eliminado completamente el soporte de EXA en favor de la nueva arquitectura de aceleración UXA.  Por si esto no fuera poco, además han eliminado Direct Rendering Infrastructure 1 (DRI1), funcionalidad que es el soporte fundamental para la aceleración por hardware y que ya muestra sus años.

Esto quiere decir que todo lo que consideramos como estable, probado y conocido ha sido eliminado para enfocar los esfuerzos hacia la nueva arquitectura y de paso forzar su uso y estabilización.  Por lo tanto, para usar aceleración por hardware 2D, ahora sólo está disponible UXA que lamentablemente aun no está libre de bugs.  Los usuarios que han habilitado UXA dicen que el sistema es bastante más rápido que lo que se haya conocido antes en Linux, pero hay problemas de estabilidad y rendering que no han sido resueltos.  Ya hace poco les contamos que en el recién liberado Ubuntu 9.04, se prefirió mantener EXA configurado por omisión.

Como este driver se demorará un tiempo en llegar a las distribuciones, se espera que los usuarios avanzados lo instalen y reporten los bugs encontrados en UXA antes de que llegue al usuario común y corriente.

Eliminar código antiguo es una estrategia que ha resultado bastante bien para tener menos código que mantener, centralizar esfuerzos en lo que realmente vale la pena y en el fondo eliminar lastre para tener una base sencilla, sólida y limpia.

Link : Intel releases new driver, kills EXA/DRI1 (phoronix.com)

Cuando Ubuntu 9.04 esta próximo a llegar a su fecha de lanzamiento, Canonical dice que no habilitará por omisión la nueva arquitectura de aceleración de video UXA de Intel, dado que a pesar de mostrar notables mejoras en el rendimiento, no se encuentra suficientemente estable para ser usado por todo el mundo.

UXA (UMA Acceleration Architecture) es responsable de la aceleración 2D del sistema gráfico de Linux y se encarga de traspasar al hardware las operaciones típicas 2D de un escritorio moderno como son bitblt, rectangulos, alpha blending, etc.  Hoy en día esta responsabilidad cae en EXA Acceleration Architecture, antepasado directo e inspirador de UXA.  EXA tiene un diseño reciente pero comparado con UXA, no considera las mejoras respecto a gestión de memoria realizadas últimamente en el kernel mediante GEM (Graphics Excecution Manager).

En los benchmarks que se han realizado para comparar UXA con EXA se ha detectado que UXA es notablemente más rápido, incluso se han detectado mejoras en más de un 50% del rendimiento para algunas tareas, pero en su estado actual varios usuarios han reportado problemas de estabilidad con corrupción, caídas y bloqueos del servidor gráfico, entre otros.

Bryce Harrington, el ingeniero lider de X.org en Canonical, ha decidido que las mejoras en rendimiento no compensan los bugs que se presentan y por lo tanto no habilitarán UXA por omisión en Ubuntu 9.04.  De todas formas, a este ritmo se espera que UXA se encuentre suficientemente estable en 6 meses más cuando salga Ubuntu 9.10. Considerando que Ubuntu 9.10 incluirá el kernel 2.6.29 ya se convierte en un release que provoca grandes expectativas.

Aquellos amantes de la velocidad que no le teman a la inestabilidad, pueden probar como se comporta UXA con sus chips de video Intel, habilitándolo con las instrucciones de UxaTesting en el wiki de Ubuntu.

Links:
- Canonical not to enable UXA, too problematic (Phoronix)
- Intel UXA Acceleration performance (Phoronix)
- Lo nuevo en X Server 1.6 (FayerWayer)
- Ubuntu 9.04 no incluirá el kernel 2.6.29 (FayerWayer)