Hasta los putos cojones de la obsolescencia programada de Apple

Ahora ya lo tengo más que claro. Apple aplica obsolescencia programada, y de forma bastante evidente.

Me explico. Tengo un iPad 1, de 64 GB y va como una moto. Bueno, iba. Porque ya no va. Vale, sí que va. La batería le dura casi lo mismo que el primer día, que suele ser lo primero que falla en estos aparatos.

Pero sólo la batería. Me llamó mucho la atención, porque en general yo no suelo dejar que los cacharros se me envejezcan en las manos y suelo revenderlos con no más de un año de uso.

Me llamó la atención que la batería, tras más de dos años de uso, estuviera como el primer día. Y más todavía cuando empezó a usarlo mi novia, con una carga diaria… No hacía más porque le duraba todo el día y a veces más. Lo usaba como su ordenador principal, toda ella tirada en el sofá.

Pero qué cosas, justo unos días antes de que saliera al mercado el iPad 3, el iPad 1 comenzó a hacer cosas muy raras. Cierres de aplicaciones inesperados. Las mismas aplicaciones que el día anterior iban perfectas, de repente empezaron a cerrarse solas.

Sobre todo Safari, que era lo que ella más usaba. Y no hubo solución. Ni reinicios, ni reseteos de fábrica ni nada de nada. Simplemente comenzaron a fallar sin otra explicación.

Para más inri, no hubo ninguna actualización del sistema operativo de por medio. Es decir, que la causa de los errores podría haber sido una actualización, pero no.

Llegó la fecha y comenzaron los fallos.

***

Ahora tengo un iPad 3… Sí que ha habido una actualización del sistema operativo, el iOS 7. Y de nuevo ha comenzado el baile.

Y ya no tengo dudas. Ahora soy yo el que está usando el aparato, y soy yo el que está seguro de que a finales de septiembre abría exactamente los mismos PDF, los mismos epub y navegaba por las mismas Webs. Con el mismo sistema operativo, recién actualizado.

Y sí, como ya he dicho, volvemos al baile. Desde este fin de semana el iPad va sensiblemente más lento, esos PDF, esos ePub, esas Webs ahora petan mi sistema. Los mismos. No prácticamente los mismos, sino exactamente los mismos.

Recordemos que a finales de este mes hay una nueva keynote y se supone que salen nuevos iPads. Yo estoy ya completamente seguro de que saldrán. A causa de cómo se está comportando el mío.
Y de nuevo una restauración no ha servido de nada.

***

Ya tenía la mosca detrás de la oreja, pero ahora estoy completamente seguro. Si mis conocimientos de las tripas de iOS fueran los de Windows, a todas luces buscaría la causa de ello. Como sólo controlo las iCosas a nivel de usuario, confirmada la sospecha, esperaré a ver si alguien descubre algo.

Yo estoy seguro.

También estoy seguro que el límite de Apple para tumbar las iCosas es de dos generaciones. Cuando sale una nueva, los cacharros que se correspondan a la ante-antepenúltima dejarán de funcionar bien.

***

Es tiempo de cambiar. Menos mal que de momento a los MAC eso no suele pasarles.

¿Son necesarios los 64 bits en un teléfono (digamos un iPhone 5S)?

NOTA: Esta entrada también se publica aquí.

La respuesta correcta es absolutamente no. No sin condiciones. Un rotundo y absoluto no. 

No obstante, se puede leer entre líneas y podría haber una razón. 

 

Pero antes comencemos con los motivos negativos. El paso de 32 a 64 bits solo está justificado si se cumplen algunas de las necesidades que vamos a comentar.

No obstante, primero debemos explicar algunas cosas. Cuando uno ejecuta una aplicación en un sistema operativo moderno, ocurren varias cosas. Por un lado está la aplicación, que necesita un espacio de memoria para poder ser cargada. Y esa aplicación tiene que tener alguna forma de hacer llamadas al sistema operativo para que este realice acciones como abrir un fichero o conectarse a Internet.

Eso se consigue con un modelo de memoria. Y la forma más fácil es que el sistema operativo y la aplicación compartan el espacio de direcciones. Dicho como una analogía, imagina que tienes una caja de un tamaño determinad y que en ella tienen que caber dos objetos. Una opción es dividir la caja en dos compartimentos, dejando un hueco para cada objeto.

Bueno, pues este es el modelo de memoria estándar, aunque hay otros, es el más común. Es decir, la caja es la memoria disponible en el sistema, y en un hueco está el sistema operativo y en el otro la o las aplicaciones cargadas y en ejecución. Hasta aquí todo bien. Por lo tanto, pasar de 32 a 64 bits es tener una caja más grande.

En palabras más o menos técnicas, un microprocesador de 32 bits es capaz de direccionar hasta 4GB de memoria RAM y uno de 64 unos cuanto miles de millones de Terabytes. Decimos 4GB porque es un estándar, pero los micros x86 y los ARM tienen una capacidad que se llama modo PAE y que permite direccionar 128GB de RAM o incluso más sin salirnos de los 32 bits.

Pero lo habitual en un microprocesador moderno, para evitar florituras extrañas (como punteros de 32 bits en lugar de 24 que es lo habitual, o modelo segmentado), es que tengan la memoria dividida en 1/3 ó 2/2. Es decir, de los 4GB disponibles para cada aplicación, 1 GB está ocupado por el sistema operativo y los otros 3 por la aplicación. O en el otro modelo, mitad y mitad. 

Siguiendo la analogía de la caja, 1/3 de ella el objeto que es el sistema operativo y los otros 2/3 al programa en sí. De este modo, cuando una aplicación quiere hablar con el sistema operativo, se asoma y actúa en consecuencia.

Todo esto es virtual. Suponiendo un iPhone con 1GB de RAM, poca división real como la descrita vamos a tener. O en otras palabras, suponiendo un teléfono con 4GB de RAM, y ejecutando una sola aplicación, la división estaría hecha tal y como hemos comentado, pero con un GB de RAM la cosa no parece muy coherente.

En otras palabras, da igual el tamaño virtual de la caja. Da igual que le quepan sólo dos objetos que sumen 4GB (32 bits) o tropecientos Terabytes (64 bits), porque la realidad es que, ocupando 1, la hemos llenado.

En resumen, pasar de 32 a 64 bits por motivo de tamaño de programa y de sistema operativo es una completa y supina gilipollez. Porque aun tirando de memoria virtual (swap a disco, en este caso a memoria flash), carece de sentido.

Siempre a nivel teórico, sería posible que las aplicaciones necesitaran más de esos dos o tres GB de memoria para funcionar.

¿Las necesita algún programa que se ejecute en un teléfono? Pues francamente no. Y menos aún cuando la memoria real de un teléfono como el iPhone es de 1 GB. Poca partición podemos hacer ahí, pero poca poca.

***

Otro motivo podría ser que un micro de 64 bits se ejecute mucho más rápido que uno de 32. Sí, por lo general es cierto. Al crecer en ancho de registros, también se optimiza su juego de instrucciones, por lo que en general, a una misma velocidad y sin tener en cuenta el cambio de anchura, suelen ir más rápidos. Simplemente porque toman el doble de celdas de memoria de una tacada, tanto para programa como para datos. Evidentemente, los periféricos deben acompañar. 

Eso se hace de varias formas. O bien se instala memoria que permita ser leída en bloques de 64 bits, o bien se instalan dos bancos de 32 bits que se leen de forma simultánea, o 4 de 16, u 8 de 8… Ignoro la arquitectura interna del iPhone, pero no me mojaría mucho si dijera que usa dos bancos de 32 bits.

También hay una más, la económica y la que se suele realizar más habitualmente. Se trata de tener el mismo ancho de bits de memoria y hacer dos lecturas (o escrituras) seguidas. De este modo, aun teniendo un procesador de 64 bits, podemos usar memoria de 32 bits con unos pequeños cambios en la arquitectura real del sistema.

El handicap aquí es que pese a tener un sistema teóricamente más rápido en realidad no lo es tanto, ya que para cada instrucción a ejecutar necesitamos dos lecturas, ejecución, dos escrituras, etc, frente a lectura, ejecución, escritura.

Y eso sin entrar en el almacenamiento de segundo nivel, o de disco, que en los teléfonos suele ser memoria flash. Mientras que el disco sea interno al teléfono siempre podemos seguir la idea de usar varios bancos, pero en cuanto metamos una tarjeta normal y corriente estamos limitados a su velocidad estándar. 

No obstante, esto no nos interesa porque el iPhone no soporta eso.

***

Una aplicación de 64 bits puede llegar a ocupar hasta un 40% más de memoria y hasta un 100% (el doble justo) de disco porque sus punteros tienen el doble de tamaño, y las estructuras de datos suelen ocupar el doble. Y al duplicarse el tamaño de las instrucciones máquina, gastan el doble de espacio al estar almacenados en disco.

Por lo tanto, suponiendo un iPhone con 1GB de RAM y ejecutando programas de 64 bits puros, ese giga se nos queda en aproximadamente 640M realmente útiles comparados con la versión de 32 bits. Es decir, que si queremos acompañar el uso de memora al rendimiento, tenemos que ampliarla en su justa razón. No me extrañaría que el iPhone 5S llevara 2GB de RAM, porque si lleva sólo 1, el efecto final va a ser menos memoria para las aplicaciones, sin hablar del espacio de disco. 

Hazte cuenta que tus 32 GB de disco serán equivalentes, con suerte, a unos 24GB, si no 16. Bonito, ¿no?

***

¿Hay alguna mejora real en tener 64 bits? Sí, sólo una, pero que no es obligatoria ni exclusiva de los 64 bits. El juego de instrucciones seguro que está más optimizado y el rendimiento multimedia y potencia de cálculo de fuerza bruta sí que se notan, y mucho.

¿Por qué? La toma de datos con el doble de ancho significa significativamente menos operaciones. Por ejemplo, una multiplicación de 64 bits en un procesador de 32 bits que no tenga instrucciones de 64 bits necesita hasta 4 multiplicaciones de 32 bits más una o varias sumas, secuencias de control aparte. En 64, esas posibles 5 instrucciones se convierten en una sola. Hemos acelerado 5 veces la operación, y sólo sin tener en cuenta también los tiempos de acceso. Es decir, con 32 bits, una instrucción se compone de tomar de memoria, ejecutar, poner en memoria. ¿La parte más lenta? Poner en memoria, seguida de tomar de memoria y finalmente ejecutar. Sustituimos cinco lecturas y cinco escrituras por una de cada. El incremento de rendimiento, aunque sea memoria de 32 bits bajo un entorno de 64 es literalmente enorme.

No obstante, para tener ese incremento de rendimiento no es necesario pasar a los 64 bits ni mucho menos. ¿Sabéis qué significan las siglas SSE, SSE2, SSE3? Pues eso mismo, que también podemos tomar un procesador de 32 bits y añadirle instrucciones especiales o, como se hace más habitualmente y que también ha hecho Apple, añadir un coprocesador más rápido y dejar que sea él el que haga todo ese trabajo. Si digo tarjeta de vídeo seguro que se me entiende mejor. 

***

Por lo tanto, lo dicho. Los 64 bits no son más que puro marqueting para generar aplausos y dejar bocas abiertas, tanto, que ahora todo el mundo quiere procesadores de 64 bits en sus teléfonos. Posiblemente veamos un Galaxy S4 cuya única mejora sean esos 64 bits, seguidos de un Note 4…

Y de nuevo Apple ha vuelto a conseguir que toda la industria de la telefonía móvil vaya detrás de ellos…

En fin…

***

Y ahora sí, puede que realmente sea éste el motivo por el cual los teléfonos de Apple comiencen a llevar chips ARM de 64 bits, que no les hacen ninguna falta.

¿Qué pasa con el MacBook Air? ¿Os imagináis un Air con un ARM de 64 bits, 8 ó 16 GB de RAM, menos de un quilo de peso, ejecutando la versión 12 de OS X que ha sido integrada con el iOS 9 (por cierto, cerrando el círculo) y con una duración de batería de 16 ó 24 horas? ¿Os imagináis algo a caballo entre el iPad y el Air, al estilo de una Surface PRO pero con la duración de batería de un iPad y el rendimiento de un Air? Me refiero a un MAC completo, plenamente funcional, pero en formato tableta.

Pues estad atentos, que los tiros van por ahí. No sacan un Air con un ARM porque estos todavía no tienen el rendimiento de un i3 o un i5, pero tiempo al tiempo. Y esperemos que Microsoft se ponga las pilas.