template<class Cpp, class Qt, class ... Y_Mas>

Apple M1 y productividad

Apple M1 y productividad

    ¿Cómo se relacionan los chips M1 con la productividad de un equipo?

Ayer comienzó la WWDC 2021, la conferencia de desarrolladores de Apple y, como no, también tuvo lugar la tan esperada keynote en la que se anunciaron las siguientes versiones de sus principales sistemas operativos (aún estoy digiriendo todo lo presentado).

En la WWDC 2020 Apple también anunció que dejaría de usar los procesadores de Intel para migrar a sus propios chips (los que luego se llamarían M1), basados en su experiencia con el desarrollo de procesadores para iPhone, iPad, Apple Watch, etc. Estos procesadores cuentan con un diseño tipo SoC (system on a chip), es decir, que integran en un única bloque gran cantidad de componentes como puede ser la CPU, GPU, controlador de memoria, controlador de disco, etc. Además, en lo que concierne a la CPU, consta de cuatro núcleos de alto rendimiento (llamados Firestorm 🔥), y cuatro de alta eficiencia energética (Icestorm 🧊); los primeros son mucho más potentes pero consumen 10 veces más energía (13,8 W vs 1,3 W).

Los M1 logran superar con diferencia a las versiones más potentes de los i5 e i7 de Intel, e incluso llegan a igualar a los i9 en algunas pruebas de rendimiento. Tradicionalmente estos benchmarks miden la potencia bruta de un sistema (tales como operaciones por segundo, tiempo en tareas sintéticas), y al final resumen los resultados en un único valor fácilmente comparable. Ahora bien, de las cosas más impresionantes no es sólo que los M1 son rápidos, muy rápidos en estos tests sintéticos, sino que además parecen rápidos, y esto es el núcleo de este artículo (😉).

El día a día de la gran mayoría de los usuarios no es llevar el sistema al límite todo el tiempo, tal y como hacen estos benchmarks. El usuario no suele medir cuántas cosas puedo hacer en X segundos, sino más bien cuánto tiene que esperar para que lo que está haciendo termine. El flujo más habitual se parece a un conjunto de ráfagas pico en medio de valles más largos de menos exigencia computacional. Y es precisamente en la transición de valle a pico donde el usuario percibe la velocidad del sistema, donde la juzga y, hasta cierto punto, donde le importa: que su equipo puede con lo que se le pide. Podemos tener 11 aplicaciones abiertas tranquilamente, pero es cuando abrimos la número 12, o accedemos a un vídeo en el navegador, o guardamos un documento, o aplicamos un efecto a una imagen, es en el pico cuando decimos que el sistema no puede más 😰.

Acá es cuando el sistema operativo, macOS Big Sur (y el ayer anunciado macOS Monterey), toma la potencia bruta y el diseño del M1 y los convierte en experiencia de usuario: siempre que puede trata de tener los Firestorm (núcleos de alto rendimiento) libres, sin hacer nada, mientras que los Icestorm llevan toda la carga. ¡Y es perfecto! porque esos núcleos tienen capacidad de sobra para gestionar las tareas de los valles (y consumiendo muy poca energía), a la vez que dejan a los titanes libres para reaccionar rápidamente ante cualquier demanda inesperada. Con esto, el sistema no sólo es rápido, sino que lo parece, responde al usuario cuando lo necesita, lo mantiene con tiempo de espera 0 👍🏼.

Hace poco leí un artículo muy interesante sobre gestión de proyectos que trataba un problema parecido (dejo el enlace al final): personalmente todos tenemos 11 tareas entre manos, y vamos bien, hasta que una de ellas entra en un pico: un problema difícil de resolver o que requiere un estudio más profundo, una reunión inesperada, un e-mail delicado, un bug de última hora, un ticket que se ha complicado y generado 7 nuevas tareas. Y a nivel de equipo pasa lo mismo: todos con varias responsabilidades, deadlines, funcionalidades que añadir, errores que resolver. Cuando nosotros o nuestro equipo estamos siempre al 100% (o más, que no es raro) no tenemos margen de maniobra y colapsamos: retraso en las tareas anteriores, estrés, impacto negativo en otros miembros del equipo). Como he dicho, esto aplica tanto a nivel de equipo (existen Icestorm y Firestorm para distintas tareas) como a nivel personal.

Cuando se planifica un proyecto a largo plazo es normal dejar un margen de maniobra, un colchón de recursos (tiempo, dinero, personal) para imprevistos. ¿Por qué, entonces, esta estrategia se diluye y desaparece cuando pasamos a las tareas específicas y su planificación a corto plazo? 😳

En estas situaciones de saturación el equipo tampoco puede dar un poquitico más porque simplemente no tiene tiempo para tonterías y tiene que hacer otras cosas antes de que se vaya a casa. Ese poquitico más es lo que muchas veces diferencia a lo mediocre de lo bueno, y a lo bueno de lo excelente, lo que marca la diferencia. Y terminan considerándose tonterías porque no son importantes, lo importante es estar a tope.

Por último, hay que tener en cuenta que nuestra eficacia y eficiciencia no es uniforme: cada persona tiene sus ritmos, sus fortalezas y debilidades, la productividad cambia durante el día, cambia dependiendo de la tarea que estemos haciendo, de cuál hayamos hecho, de la reunión de la que venimos o la que vamos a tener y que nos tiene ocupado un hilo en segundo plano. Estar a tope hace que no podamos organizar nuestras tareas de la forma más adecuada, con tiempo para despejarnos, limpiar el escritorio el mental, re-organizar ideas, reiniciar el sistema (y sí, hablo también del ordenador, que no pocos requieren un borrón y cuenta nueva de vez en cuando también para funcionar mejor).

Si dejamos que el equipo no esté al 100% será mucho más productivo, se sentirá mejor, tendrá más empodaramiento sobre sus tareas, no habrá retrasos porque se habrá planificado sobre ese sub-100%, se podrán adelantar trabajos, hacer tonterías que den valor añadido, innovar en ideas para las que nunca hay tiempo y que pueden ser el siguiente hit.

¿Cómo planificamos la gestión de nuestros núcleos? ¿Los usamos todos a tope para todo? ¿O dejamos que los Icestorm del equipo y personales estén disponibles para, entonces sí, darlo todo 💪🏼?

Para quien quiera profundizar en este tema os recomiendo la lectura de Exigir el 100% de ocupación de las personas está destruyendo la eficiencia de tu equipo y organización .