- La Macintosh era considerada una computadora rápida gracias al microprocesador 68000, pero en el uso real el disquete se convirtió en el cuello de botella de velocidad
- El punto que Steve Jobs veía como especialmente problemático era el tiempo de arranque, desde encenderla hasta la prueba de memoria, la inicialización del sistema operativo y la carga del Finder
- Jobs presionó a Larry Kenyon diciendo que, si reducía el arranque en 10 segundos, 5 millones de usuarios ahorrarían 50 millones de segundos cada día, y que en un año eso equivaldría a decenas de vidas humanas
- Como el equipo ya estaba motivado para mejorar el rendimiento del software, no está claro cuánto influyó realmente ese cálculo
- Como resultado, unos meses después el equipo de Macintosh redujo el tiempo de arranque en más de 10 segundos, y la persuasión al estilo Jobs quedó como una anécdota humorística
El cuello de botella de la Macintosh era el disquete
- El equipo de Macintosh consideraba que el microprocesador 68000 era, en la práctica, 10 veces más rápido que el Apple II, y por eso pensaban que era una computadora rápida
- Pero como la RAM era limitada, tenía que leer datos con frecuencia desde el disquete, y en ese aspecto no era más rápida que el Apple II
- Cuando las aplicaciones reales empezaron a funcionar, el disquete quedó expuesto como el cuello de botella principal
El tiempo de arranque que Steve Jobs observaba con insistencia
- Una de las cosas que más le molestaban a Jobs era el tiempo de arranque cuando encendía por primera vez la Mac
- Prueba de memoria
- Inicialización del sistema operativo
- Carga del Finder
- Ese proceso podía tardar varios minutos, o incluso más
- Jobs le exigió a Larry Kenyon, responsable del controlador de disco y del sistema de archivos, que el arranque de la Macintosh era demasiado lento y que había que hacerlo más rápido
El cálculo de “reducir 10 segundos salva vidas”
- Larry Kenyon intentó explicar qué partes podían mejorarse, pero a Jobs no le interesó esa explicación
- Jobs supuso que, unos años después, 5 millones de personas arrancarían una Macintosh al menos una vez al día
- Calculó que, si se reducía el tiempo de arranque en 10 segundos, se ahorrarían 50 millones de segundos cada día, lo que en un año equivaldría a decenas de vidas humanas
- Por eso dijo que hacer que el arranque fuera 10 segundos más rápido era tan valioso como “salvar decenas de vidas”
El resultado real
- Como el equipo ya quería hacer que el software fuera lo más rápido posible, no está claro cuánto impacto tuvo la persuasión de Jobs
- Aun así, esa forma de persuadir fue recibida dentro del equipo con bastante humor
- En los meses siguientes, el tiempo de arranque de la Macintosh efectivamente se redujo en más de 10 segundos
1 comentarios
Opiniones en Hacker News
Según una historia que escuché de un ingeniero veterano de Apple, en la época de MacOS 8.x la mayor queja en las encuestas a usuarios era el tiempo de arranque.
En aquel entonces tardaba unos 45 segundos en promedio, y como el sistema ya soportaba suspensión, dicen que preguntaron por qué a la gente le importaba el tiempo de arranque.
Resultó que la gente no reiniciaba simplemente una vez al día o una vez por semana, sino con frecuencia por la inestabilidad; en la nueva versión también mejoraron el arranque, pero se enfocaron más en estabilizar el sistema operativo.
Al final, las quejas por el tiempo de arranque desaparecieron, no porque se hubiera vuelto increíblemente rápido, sino porque la gente tenía que reiniciar mucho menos. La lección es que hay que entender no solo qué piden los clientes, sino también por qué lo piden.
Las reglas para parchear tampoco eran claras; por ejemplo, podía haber una ruta de código que asignara memoria dentro de un parche a una llamada del sistema, algo que no debía hacerse porque el administrador de memoria no era reentrante.
Además, corría código compilado con los compiladores C de la época, y las herramientas para impedir escrituras de memoria fuera de rango eran muy limitadas.
MacOS 8 también introdujo una protección de memoria muy limitada, pero en situaciones reales no ayudaba mucho; en contexto, esta es una historia sobre la capacidad y la voluntad de una organización para racionalizar un problema.
Este problema casi mata a Apple como negocio.
Un amigo le mostró Mac OS X por primera vez a su esposa y, cuando intentó apagarlo, ella hizo una mueca y dijo: “Lo que me gustaba de la Mac era justamente que se apagaba al instante”. Mi amigo respondió: “Entonces tendrás que encontrar otra cosa que te guste de Mac OS”.
Si ahora es más rápido, solo hay que esperar unos años. Los desarrolladores dejarán pasar suficientes regresiones de rendimiento para que vuelva a llegar a ese nivel.
Creo que había escuchado esta historia y luego la olvidé. Cuando dirigía el equipo de instalación, descargas y parches en Blizzard, solía decirle al equipo: “Si 10 millones de personas descargan e instalan este parche, y nosotros hacemos que les tome un minuto más, estamos consumiendo otra porción de vida humana”.
Era exagerado y cursi, pero ayudaba a empujar las mejoras.
La métrica que impulsaba con más importancia era la velocidad de la luz. En la época de instalar desde DVD, la velocidad de giro del disco era la velocidad de la luz de ese entorno, así que había que instalar lo más cerca posible de esa velocidad.
Hay que seguir mejorando la velocidad de trabajo hasta chocar con los límites físicos; el tiempo es valioso y no se puede conseguir más.
Al desplegar una gran mejora de rendimiento de infraestructura, lo importante no es la velocidad ni el ahorro de costos en sí, sino que haya menos CO2 en la atmósfera y que el tiempo humano distribuido entre millones de personas se use en algo distinto a esperar la respuesta de una computadora.
No somos médicos que salvan vidas individuales, pero sí podemos devolverles a las personas una parte de su vida. Algún software lo usan cientos de millones o miles de millones de personas, así que incluso un cambio pequeño puede ahorrar una cantidad de tiempo equivalente a varias “vidas”.
Si no recuerdo mal, la distribución de parches basada en torrents de WoW y otros juegos estaba realmente bien hecha, y era especialmente impresionante en una industria con tanta presión.
He visto muchos ingenieros a los que se podría considerar trabajadores, pero que dedicaban muy poco tiempo a entender el hardware que operaban y lo que era posible hacer con él.
En discusiones de rendimiento escuché demasiadas veces “es lento” o “está bien”, cuando en realidad se estaba ignorando por completo la máquina subyacente y sus límites posibles.
Mi función favorita es el soporte de carga progresiva. WoW es un juego enorme, pero se puede empezar a jugar con solo algunos assets; puede mostrar placeholders y assets de menor calidad, o incluso omitir por completo ciertas zonas.
Incluso con una instalación totalmente nueva, se puede jugar en pocos minutos. Los jugadores suelen darlo por hecho, pero agradezco porque está claro que debió de haber un esfuerzo enorme para reemplazar las ruedas de un tren en movimiento y entregar cantidades gigantescas de datos con alto rendimiento y sin mayores problemas.
Me pregunto si eso es realmente un uso del tiempo tan superior a esperar una descarga.
Steve Jobs siempre inventaba algo para motivar y presionar a la gente, en una especie de campo de distorsión de la realidad
Según Mike Slade, alrededor de 1990 Jobs intentó reclutarlo para NeXT mientras él trabajaba en Microsoft; en ese momento Microsoft estaba por lograr un gran éxito con Windows 95, mientras que NeXT tenía dificultades para vender computadoras
Jobs le dijo a Slade que si se quedaba en Seattle su talento se desperdiciaría, y que Silicon Valley era el centro de la emoción y la actividad, un lugar donde podría florecer
Luego describió Palo Alto como un “lugar especial”, parecido a Florence durante el Renacimiento italiano, e improvisó un discurso apasionado diciendo que había tanto talento que caminando por la calle uno podía encontrarse con un académico en un momento y con un astronauta al siguiente
Slade quedó tan impresionado con esa descripción que decidió mudarse a Palo Alto, pero un año después, mientras cenaba con su esposa en Il Fornaio, una cadena italiana en University Avenue en Palo Alto, vio en la parte de atrás del menú una frase que decía “Palo Alto es como Florence en la época del Renacimiento…”, junto con la misma historia
Al final, Jobs lo había convencido usando el texto del menú de una cadena de restaurantes que le gustaba, y encima un texto publicitario bastante malo; Slade recordó que era “un fanfarrón realmente sin vergüenza”
https://www.cultofmac.com/573753/how-jobs-poached-a-microsof...
Cuando trabajé allí hace unos años, lo único memorable que recuerdo de las calles de Palo Alto era el abrumador olor a orina en el paso subterráneo debajo de Caltrain Station
Es difícil creer que un ingeniero profesional e inteligente, que trabajaba en una de las empresas más grandes y prestigiosas del mundo en ese momento, haya renunciado y trasladado toda su vida a otro estado solo porque un posible empleador le dijo “créeme, es increíble”
Para tomar una decisión así, al menos habría tomado un avión para ver departamentos y visitar la oficina. Es una buena historia, pero seguramente había mucho más contexto
Era el lugar al que uno iba cuando todas las demás opciones estaban reservadas o ya era demasiado tarde para manejar más lejos
Era el centro del mundo de la computación, y realmente pasaba que te encontrabas al azar con personas increíbles en lugares como Fry’s, restaurantes o bares
Creo que la gente joven de hoy no entiende bien que muchas de las cosas que hoy rodean a la tecnología tienen sus raíces en el South Bay y la Peninsula de los 90
Los programadores e ingenieros deberían aplicar esta forma de pensar de manera general. La cantidad total de tiempo que se pierde esperando software lento es enorme, y más equipos de desarrollo deberían darle mayor prioridad al rendimiento
No sumamos conscientemente todo el tiempo que esperamos por software y servicios lentos, pero en esos momentos el sistema nos hace sentir, de forma inconsciente, incómodos e irritados, como si estuviera en nuestra contra
Si uno llega a pensarlo aunque sea un poco conscientemente, termina despreciando a los ingenieros y líderes de proyecto que creyeron que lo que construyeron era lo suficientemente bueno como para lanzarlo
Dada la capacidad de procesamiento de las computadoras modernas, esperar cientos de milisegundos por una solicitud trivial, o mucho más por una apenas más compleja, es evidencia de una negligencia grave por parte de los programadores
Un jueves por la noche mi novia me pidió limpiar una MacBook vieja, y solo eran unos pocos pasos: desvincular cuentas asociadas al hardware, averiguar cómo quitar una clave de firmware que probablemente yo había configurado antes, hacer una instalación nueva y actualizar
Pero como varios pasos o reinicios tardaban más que unos pocos segundos, y el trabajo seguía tentándome, me tomó 6 meses
Después de interrumpirlo varias veces, la dejé sobre el escritorio al lado del teclado y terminé en un total de 30 minutos repartidos a lo largo de 6 horas; fue una victoria
Si alguien me hubiera atado la mano a la laptop, probablemente habría terminado más rápido, pero el sufrimiento de verme obligado a mirar una pantalla en blanco, una barra de progreso y un indicador giratorio habría sido inimaginable
Los trabajos por lotes de larga duración son una excepción
Me pregunto por qué una computadora común podía arrancar en frío en menos de 30 segundos desde un disco duro mecánico de 5400 rpm, pero con un SSD NVMe moderno no puede arrancar en menos de 1 segundo
Windows 95 ocupaba alrededor de 50 MB instalado, incluyendo la mayoría de sus funciones, y Windows 2000 cabía en un solo CD de instalación
Hoy el instalador de Windows 10 ni siquiera cabe en un DVD de una sola capa, y también hay que olvidarse de instalarlo desde una memoria USB FAT32. Algunas UEFI antiguas todavía no manejan exFAT
La computadora más rápida que recuerdo haber usado se sentía como una con doble Pentium 3 866, Rambus y discos SCSI U320 de 15k arrancando XP; era casi telepática
Parece el viejo problema de que, a medida que Windows acumula más basura, el arranque se alarga
Las fuentes del sistema antes tenían unos 200 caracteres, pero ahora contienen decenas de miles
Si extrapolas eso a todo lo demás, queda bastante claro que hay mucho más que cargar
Es lo suficientemente rápido como para que no me moleste
Si tienes que esperar a la computadora, es que no es lo suficientemente rápida
Aquí la lógica de Steve es clásica, aunque se usa mucho en la industria y casi roza el chantaje emocional, en plan “si fallas, eres un asesino”
Es muy fácil culpar al usuario por el software lento, o culpar a los PM o a la organización que presionan por funciones y velocidad de desarrollo por encima de la velocidad del producto
El lema de Steve aquí significa que el rendimiento del software tiene un impacto real en la vida cotidiana, y señalar eso no es chantaje emocional
Dicen que, después del lanzamiento del iPad, Jobs entró a una reunión del equipo de Mac con un iPad, lo despertó y se encendió de inmediato
Luego despertó una Mac, que tardó en salir del modo de reposo, y Jobs preguntó algo como: “¿Por qué esto no puede hacer eso?”
Si no hubiera existido el iPad para demostrar que era posible, habrían seguido las discusiones sobre la velocidad de la memoria y la del disco, y que las Mac durmieran/despertaran más rápido terminó presionando también a Windows para mejorar
Si esa lógica es correcta, me pregunto qué pasa con la gran cantidad de animaciones en las UI de hoy
En muchos casos, aparte de verse bien las primeras decenas de veces, solo hacen perder tiempo
En el teléfono que uso, el selector de apps tarda entre 0.5 y 1 segundo con animaciones, pero si las desactivo el cambio es prácticamente instantáneo
Si la pantalla cambia de golpe a una disposición completamente distinta, el procesamiento visual toma tiempo; en cambio, si los elementos se interpolan y se mueven a sus nuevas posiciones, ese tiempo de procesamiento se reduce a la duración de la animación
Normalmente no es 0.5 o 1 segundo, sino alrededor de 0.25 segundos
Para los obsesionados con la velocidad o usuarios avanzados puede ser un estorbo, así que pueden desactivarlas, pero el usuario objetivo no es la gente que se aprendió cada rincón de la UI por memoria muscular, sino el usuario promedio
Algunas animaciones pueden solaparse con operaciones que toman tiempo, dando al usuario la sensación de que hay respuesta mientras igualmente lo hacen esperar. iOS parece hacer esto al cambiar a una app que fue pasada a swap en disco; como hay tiempo de carga, la animación compensa parte de la demora
Sin animación, el usuario podría pensar que no realizó bien la acción e intentar repetir la entrada, lo que lleva a frustración
Algunas animaciones son necesarias para mantener la orientación del usuario dentro del flujo de la UI. Por ejemplo, la animación de minimizar mueve la ventana hacia el ícono que hay que pulsar para restaurarla, y ayuda a distinguir entre cerrar y minimizar
Algunas animaciones son necesarias para dar retroalimentación adecuada sin perder capacidad de respuesta. Al desplazarse por una lista en una pantalla táctil, sin la animación de resorte al llegar al final, el usuario no tiene forma de saber si llegó al final de la lista o si la pantalla táctil dejó de responder
La UI del sistema de las consolas de videojuegos y algunos menús de juegos parecen especialmente malos en este aspecto
Una animación corta de 200 ms a 25 fps tiene apenas 5 cuadros, así que se ve entrecortada y burda
Si la haces de 1000 ms, se ve fluida y bonita, pero usarla es desesperante
Quizá sea una solución impopular, pero puedes usar un iPhone. El selector de apps funciona tan rápido como el movimiento del dedo y no tiene problemas para mantener 60 fps constantes
No eran tan lentas como para ser inutilizables, pero sí se notaba; resultó que la velocidad de las animaciones venía demasiado baja por defecto
La dupliqué y sentí que todo mejoró 1,000 veces
Windows 11 tarda unos 12 minutos en arrancar desde un HDD. Imagínate intentar arrancar desde un FDD
Después de instalar Windows 11, si esperas a que instale todas las actualizaciones desde un HDD, tarda unos 8 días
https://www.youtube.com/watch?v=MpNagBwWlNk
Hace poco intenté crear un sistema de arranque dual y arruiné las particiones de una iMac 2017 con Fusion Drive; desde entonces la Mac se volvió lenta
Desde el inicio hasta que quedaba más o menos usable probablemente tardaba unos 5 minutos; en cualquier caso, era bastante tiempo
El fin de semana pasado me harté de la lentitud y, buscando, encontré el comando
diskutil resetFusion0, que devuelve las particiones a los valores predeterminadosEjecuté ese comando y reinstalé el OS, y la iMac volvió a ser bastante rápida. No es excelente, pero sí mucho mejor que antes
La lección aprendida es que el arranque dual en un Fusion Drive es una mala idea
Normalmente reinicio mi máquina con Windows 10 una vez cada varios meses, y nuestro departamento de TI prepara una PC con Windows en alrededor de una hora
Parece que algo está muy mal, aunque no soy especialista en TI
Recuerdo haber visto hace tiempo un artículo y una discusión sobre InterBase (ahora FireBase). Trataba sobre cómo el almacenamiento y el modelo de recuperación con autocuración eran importantes en ciertos escenarios, y en ese momento había citas como estas:
“AFATDS está compuesto por 935,000 líneas de código Ada que se ejecutan en estaciones de trabajo HP RISC y en las Light Weight Computer Units del Army”, dijo John Williams, de Magnavox Electronic Systems Company, el contratista principal.
“Necesitábamos una única base de datos que pudiera escalar y funcionar en plataformas Unix y PC. El producto tenía que instalarse rápidamente y ofrecer alta disponibilidad sin acaparar los recursos del sistema”.
“El soporte a la toma de decisiones de esta naturaleza requería una arquitectura modular y flexible que admitiera tanto procesamiento distribuido como bases de datos distribuidas. Por eso elegimos InterBase. Superaba en rendimiento a los productos de la competencia y nos convenció de que era confiable incluso en situaciones de vida o muerte”.
El contexto exacto de la discusión era que, en algunos tanques, al disparar el cañón principal se producía un evento EMP interno que podía reiniciar el sistema, por lo que se necesitaban tiempos de reinicio y recuperación muy rápidos para poder volver a disparar.
Me pregunto qué habría pensado Steve si hubiera sabido cuántos millones de vidas se perderían haciendo scroll interminable sobre una pequeña lámina de vidrio.