¿Era MeeGo la mejor plataforma móvil del mundo? Definitivamente no. Su desarrollo e incorporación a móviles había sido lento, lentísimo. Apenas tenían aplicaciones. Internamente, no supieron poner orden y tuvieron a la gente de Symbian y GTK perdiendo enormes cantidades de dinero y tiempo intentando competir QML: Si, Nokia se liaba en guerras internas de departamentos mientras Apple y Google se hartaban de comerles el desayuno en el sector de los smartphones.
Sin embargo, y a pesar de todos los fallos arrastrados, Nokia podía haberse tirado a la piscina, haberlo dado todo por MeeGo, y habrían tenido como punto de partida de su recuperación el Nokia N9, anunciado hoy. Con este 1.0 en la calle, podían dedicarse a apretar las tuercas, sacar actualizaciones frecuentes para refinarlo, ponerse a la altura de sus competidores e incluso mejorarlos. Todas, o casi todas las aplicaciones diseñadas para él serían válidas para millones de móviles Symbian existentes en el mercado. Podrían haberse centrado en la integración de QT con Android e iPhone para venderlo como el mejor toolkit multiplataforma para móviles, toolkit del que sus competidores se beneficiarían pero que los finlandeses controlarían en la práctica. Habrían gozado de gran apoyo por parte de los desarrolladores pro-software libre, que tienen su peso en todos los rincones de Internet. Sus competidores tendrían mucha ventaja, pero al menos Nokia estaría de vuelta en la carrera.
Pero nada de eso va a ocurrir. En lugar de eso seguirán con su apuesta por Windows Phone, la única gran plataforma móvil que no puede ejecutar aplicaciones nativas QT procedentes de Symbian, y sólo porque a Microsoft no le da la gana permitirlo. Tendrán que enfrentarse a esa burocracia que hace que el ritmo de desarrollo de IE o Windows sea tan exasperantemente lento y poco sorprendente. No controlarán la plataforma de desarrollo .NET/Silverlight, ni la tienda de aplicaciones, estarán a merced de Redmond. Y tendrán que esperar a final de este año para ver el primer móvil con Windows Phone, y eso teniendo suerte.
A pesar de todo, muchos enfermos del software libre no muy afines a la mentalidad de diseño autista de Android tenemos, por fin, un teléfono moderno que nos gusta. Larga vida al Nokia N9.
21 de junio de 2011
14 de junio de 2011
Error, procesador demasiado inteligente
En este artículo de LWN se cuenta una curiosa historia de microoptimizaciones que no sirven para nada. Resulta que en equipos modernos la diferencia de tiempo de acceso entre memoria y registro de procesador es enorme, el tiempo necesario para acceder a una dirección de memoria RAM no cacheada previamente es de cientos de ciclos de CPU.
Para ayudar a los programadores a sortear esta desventaja, las CPUs modernas tienen instrucciones de "prelectura" (prefetch). Se trata de instrucciones que por si solas no hacen nada, pero advierten al procesador de que se va a leer una dirección concreta de memoria en un futuro muy cercano, información que el procesador aprovecha para decir al controlador de memoria que vaya leyendo esa dirección de memoria y colocándola en el caché L1. Así, cuando se acabe leyendo de verdad, no habrá que esperar cientos de ciclos sin hacer nada. En el kernel Linux, se utilizan las instrucciones de "prefetch" en muchos sitios, por ejemplo al ir leyendo elementos de una lista enlazada se hace un "prefetch" del próximo elemento. Sin embargo, mediciones recientes han determinado que el efecto práctico de esta técnica es el enlentecimiento del kernel - concretamente, un 0.5% más lento en el tiempo empleado en compilar un kernel.
¿Qué ha pasado? Los procesadores modernos tienen una porción de la CPU dedicada al análisis heurístico del código que se ejecuta, con el propósito de adivinar qué rutas de código se van a tomar, que partes de la memoria se van a leer, optimizar el código y hacer "prefetchs" por su cuenta (pueden estar seguros que también intentan detectar si el programa en ejecución es algún famoso benchmark de CPUs). Resulta que el analizador de código de los procesadores Intel es capaz de adivinar los "prefetchs" necesarios con más eficiencia que los programadores del kernel y GCC - hasta el punto de que esas microoptimizaciones manuales le molestan y disminuyen el rendimiento. Resumiendo, que en la próxima versión se ha eliminado todo tipo de prefetching de Linux, y es más rápido.
Este tipo de cosas, por cierto, son las que han puesto su granito de arena para que x86 triunfe y cosas como Itanium fracasen. Itanium está diseñado para que el software y el compilador hagan casi todo el trabajo de optimización, de hecho es el compilador el que debe decidir cosas como si una instrucción depende de otra y si, por tanto, se pueden procesador ambas simultáneamente o si deben ser serializadas la una detrás de la otra. De ese modo, el complejo optimizador de código se hace teóricamente innecesario y el diseño de la CPU se simplifica. Pero en la práctica resultó que los compiladores no son (y probablemente nunca sean) tan buenos y exprimir la potencia de un Itanium requiere unos esfuerzos de optimización impresionantes. Mientras tanto, el académicamente horroroso y recargado analizador de código de los x86 es capaz de optimizar en tiempo de ejecución cualquier basura que le echen encima.
Para ayudar a los programadores a sortear esta desventaja, las CPUs modernas tienen instrucciones de "prelectura" (prefetch). Se trata de instrucciones que por si solas no hacen nada, pero advierten al procesador de que se va a leer una dirección concreta de memoria en un futuro muy cercano, información que el procesador aprovecha para decir al controlador de memoria que vaya leyendo esa dirección de memoria y colocándola en el caché L1. Así, cuando se acabe leyendo de verdad, no habrá que esperar cientos de ciclos sin hacer nada. En el kernel Linux, se utilizan las instrucciones de "prefetch" en muchos sitios, por ejemplo al ir leyendo elementos de una lista enlazada se hace un "prefetch" del próximo elemento. Sin embargo, mediciones recientes han determinado que el efecto práctico de esta técnica es el enlentecimiento del kernel - concretamente, un 0.5% más lento en el tiempo empleado en compilar un kernel.
¿Qué ha pasado? Los procesadores modernos tienen una porción de la CPU dedicada al análisis heurístico del código que se ejecuta, con el propósito de adivinar qué rutas de código se van a tomar, que partes de la memoria se van a leer, optimizar el código y hacer "prefetchs" por su cuenta (pueden estar seguros que también intentan detectar si el programa en ejecución es algún famoso benchmark de CPUs). Resulta que el analizador de código de los procesadores Intel es capaz de adivinar los "prefetchs" necesarios con más eficiencia que los programadores del kernel y GCC - hasta el punto de que esas microoptimizaciones manuales le molestan y disminuyen el rendimiento. Resumiendo, que en la próxima versión se ha eliminado todo tipo de prefetching de Linux, y es más rápido.
Este tipo de cosas, por cierto, son las que han puesto su granito de arena para que x86 triunfe y cosas como Itanium fracasen. Itanium está diseñado para que el software y el compilador hagan casi todo el trabajo de optimización, de hecho es el compilador el que debe decidir cosas como si una instrucción depende de otra y si, por tanto, se pueden procesador ambas simultáneamente o si deben ser serializadas la una detrás de la otra. De ese modo, el complejo optimizador de código se hace teóricamente innecesario y el diseño de la CPU se simplifica. Pero en la práctica resultó que los compiladores no son (y probablemente nunca sean) tan buenos y exprimir la potencia de un Itanium requiere unos esfuerzos de optimización impresionantes. Mientras tanto, el académicamente horroroso y recargado analizador de código de los x86 es capaz de optimizar en tiempo de ejecución cualquier basura que le echen encima.
7 de junio de 2011
QT 5
Ya hace un tiempo que fue noticia este post en el blog de QT, que nos ilumina sobre las direcciones que podría tomar QT 5. Nadie sabe cuál va a ser el nivel de inversión de Nokia en QT a largo plazo (viendo el panorama que tienen las cosas, poco), pero al menos el equipo de programación es tan ambicioso como siempre, y si no fíjense en esto:
"While the QWidget based classes [los widgets tradicionales] are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term" "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph". Y, de este PDF con más detalles: "The core platforms will be Linux on Wayland and X11, Mac and Windows"
Espero que los gnomeros comprendan que esto me parezca bastante más interesante que la aburrida GTK. Para entendernos, lo que QT 5 pretende hacer sería equivalente a que GTK pasara a usar Clutter como pilar de todas sus GUIs. En cambio, en GTK 3.0, que acaba de salir, el pilar usado es Cairo.
Más interesante que los desfases de Gnome es preguntarse qué pasará con KDE. Una nueva versión de QT rompería la compatibilidad binaria, así que es de suponer que se necesitaría un KDE 5. Sin embargo, el cambio tecnológico no sería tan grande como lo fue de KDE3 a KDE4, por lo que más allá de experimentar con nuevas interfaces, no habría grandes novedades.
Un detalla interesante es que ya hay una nueva versión de Plasma, una especie de Plasma 2, que se basará completamente en QML (y no, no se trata de que son unos chapuceros que estén "reescribiendo" Plasma de nuevo, como se ha oído por ahí). Por esa razón, no será necesario esperar a un KDE 5 para utilizar interfaces basadas en QML, pero es que además cabría preguntarse por la influencia que tendrá Plasma en KDE 5. ¿Se imaginan que KDE declara Plasma como el framework fundamental para construir UIs? Parece demasiado radical, pero ahí está Amarok, utilizándolo.
"While the QWidget based classes [los widgets tradicionales] are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term" "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph". Y, de este PDF con más detalles: "The core platforms will be Linux on Wayland and X11, Mac and Windows"
Espero que los gnomeros comprendan que esto me parezca bastante más interesante que la aburrida GTK. Para entendernos, lo que QT 5 pretende hacer sería equivalente a que GTK pasara a usar Clutter como pilar de todas sus GUIs. En cambio, en GTK 3.0, que acaba de salir, el pilar usado es Cairo.
Más interesante que los desfases de Gnome es preguntarse qué pasará con KDE. Una nueva versión de QT rompería la compatibilidad binaria, así que es de suponer que se necesitaría un KDE 5. Sin embargo, el cambio tecnológico no sería tan grande como lo fue de KDE3 a KDE4, por lo que más allá de experimentar con nuevas interfaces, no habría grandes novedades.
Un detalla interesante es que ya hay una nueva versión de Plasma, una especie de Plasma 2, que se basará completamente en QML (y no, no se trata de que son unos chapuceros que estén "reescribiendo" Plasma de nuevo, como se ha oído por ahí). Por esa razón, no será necesario esperar a un KDE 5 para utilizar interfaces basadas en QML, pero es que además cabría preguntarse por la influencia que tendrá Plasma en KDE 5. ¿Se imaginan que KDE declara Plasma como el framework fundamental para construir UIs? Parece demasiado radical, pero ahí está Amarok, utilizándolo.
Suscribirse a:
Entradas (Atom)