- Le Macintosh était considéré comme un ordinateur rapide grâce au microprocesseur 68000, mais en usage réel, la disquette devenait le goulot d’étranglement des performances
- Le point qui gênait particulièrement Steve Jobs était le temps de démarrage après la mise sous tension : test mémoire, initialisation du système d’exploitation, puis chargement du Finder
- Jobs mit Larry Kenyon sous pression en expliquant que réduire le démarrage de 10 secondes permettrait à 5 millions d’utilisateurs d’économiser chaque jour 50 millions de secondes, soit, sur un an, l’équivalent de dizaines de vies humaines
- Comme l’équipe était déjà motivée pour améliorer les performances logicielles, il n’est pas certain que ce calcul ait réellement eu beaucoup d’influence
- Au final, quelques mois plus tard, l’équipe Macintosh réduisit le temps de démarrage de plus de 10 secondes, et la persuasion façon Jobs resta comme une anecdote amusante
Le goulot d’étranglement du Macintosh était la disquette
- L’équipe Macintosh considérait l’ordinateur comme rapide, estimant que le microprocesseur 68000 était en pratique 10 fois plus rapide que l’Apple II
- Mais la RAM étant limitée, il fallait lire fréquemment des données depuis la disquette, et sur ce point il n’était pas plus rapide que l’Apple II
- Quand les vraies applications ont commencé à fonctionner, la disquette s’est révélée être le principal goulot d’étranglement
Le temps de démarrage que Steve Jobs scrutait avec obsession
- L’un des aspects qui agaçaient le plus Jobs était le temps de démarrage au premier allumage du Mac
- test mémoire
- initialisation du système d’exploitation
- chargement du Finder
- Ce processus pouvait prendre plusieurs minutes, voire davantage
- Jobs demanda à Larry Kenyon, responsable du pilote de disque et du système de fichiers, de rendre le démarrage du Macintosh plus rapide, car il était beaucoup trop lent
Le calcul selon lequel « gagner 10 secondes, c’est sauver des vies »
- Larry Kenyon essaya d’expliquer où des améliorations étaient possibles, mais Jobs ne s’intéressa pas à cette explication
- Jobs partit de l’hypothèse que, quelques années plus tard, 5 millions de personnes démarreraient un Macintosh au moins une fois par jour
- Il calcula qu’en réduisant le temps de démarrage de 10 secondes, on économiserait 50 millions de secondes chaque jour, soit, sur un an, l’équivalent de dizaines de vies humaines
- Il affirma donc que rendre le démarrage 10 secondes plus rapide avait une valeur comparable au fait de « sauver des dizaines de vies »
Le résultat concret
- Comme l’équipe voulait déjà rendre les logiciels aussi rapides que possible, il n’est pas certain que la persuasion de Jobs ait eu un impact déterminant
- En revanche, cette manière de convaincre fut accueillie au sein de l’équipe comme plutôt amusante
- Dans les mois qui suivirent, le temps de démarrage du Macintosh fut effectivement réduit de plus de 10 secondes
1 commentaires
Avis de Hacker News
D’après une histoire racontée par un ancien ingénieur d’Apple, à l’époque de MacOS 8.x, la principale plainte dans les études utilisateurs était le temps de démarrage.
Il fallait alors environ 45 secondes en moyenne, et comme le système prenait déjà en charge la mise en veille, ils ont demandé pourquoi les gens se souciaient du temps de démarrage.
Il s’est avéré que les gens ne redémarraient pas simplement une fois par jour ou par semaine, mais souvent à cause de l’instabilité ; dans la nouvelle version, ils ont amélioré le démarrage, mais se sont surtout concentrés sur la stabilisation du système d’exploitation.
Au final, les plaintes sur le temps de démarrage ont disparu, non pas parce qu’il était devenu extrêmement rapide, mais parce qu’on avait moins besoin de redémarrer ; la leçon est qu’il faut comprendre non seulement ce que les clients demandent, mais aussi pourquoi ils le demandent.
Les règles de patch étaient aussi peu claires : par exemple, il pouvait y avoir un chemin de code qui allouait de la mémoire depuis un patch d’appel système, ce qu’il ne fallait pas faire puisque le gestionnaire de mémoire n’était pas réentrant.
À cela s’ajoutait du code compilé avec les compilateurs C de l’époque, et les outils pour empêcher les écritures mémoire hors limites étaient très limités.
MacOS 8 a lui aussi introduit une protection mémoire très limitée, mais dans les situations réelles elle n’a pas beaucoup aidé ; dans ce contexte, c’est une histoire sur la capacité et la volonté d’une organisation de rationaliser un problème.
Ce problème a failli tuer Apple en tant qu’entreprise.
Un ami montrait Mac OS X à sa femme pour la première fois et, au moment de l’éteindre, elle a fait la grimace en disant : « Ce que j’aimais avec le Mac, justement, c’était qu’il s’éteignait instantanément » ; mon ami a répondu : « Alors il va falloir trouver autre chose à aimer dans Mac OS. »
S’ils sont plus rapides aujourd’hui, il suffit d’attendre quelques années. Les développeurs laisseront passer assez de régressions de performance pour revenir à ce niveau.
Je crois avoir déjà entendu cette histoire, puis l’avoir oubliée. Quand je dirigeais l’équipe installation, téléchargement et patchs chez Blizzard, je disais souvent à l’équipe : « 10 millions de personnes vont télécharger et installer ce patch ; si on leur fait perdre une minute de plus, on consomme une autre partie de la durée de vie humaine. »
C’était exagéré et un peu ringard, mais ça aidait à pousser les améliorations.
La métrique sur laquelle j’insistais encore plus était la vitesse de la lumière. À l’époque où l’installation se faisait depuis un DVD, la vitesse de rotation du disque était la vitesse de la lumière de cet environnement ; il fallait donc installer aussi près que possible de cette vitesse.
Il faut continuer à améliorer la vitesse d’exécution jusqu’à se heurter aux limites physiques ; le temps est précieux et on ne peut pas en obtenir davantage.
Quand on déploie de grosses améliorations de performance d’infrastructure, l’essentiel n’est pas la vitesse ni les économies en soi, mais le fait qu’il y ait moins de CO2 dans l’atmosphère et que du temps humain, réparti entre des millions de personnes, soit consacré à autre chose qu’à attendre la réponse d’un ordinateur.
Nous ne sommes pas des médecins qui sauvent des vies individuelles, mais nous pouvons rendre aux gens une partie de leur vie. Certains logiciels sont utilisés par des centaines de millions, voire des milliards de personnes ; de petits changements peuvent donc économiser un temps équivalent à plusieurs « vies ».
Si mes souvenirs sont bons, la distribution des patchs basée sur les torrents pour WoW et autres était vraiment bien conçue, ce qui était particulièrement impressionnant dans un secteur soumis à une forte pression.
J’ai vu beaucoup d’ingénieurs qu’on pouvait considérer comme travailleurs, mais qui consacraient très peu de temps à comprendre le matériel sur lequel ils faisaient tourner leurs systèmes et ce qu’il était possible d’en tirer.
Dans les discussions sur la performance, j’ai trop souvent entendu « c’est lent » ou « ça va », alors que la machine sous-jacente et ses limites possibles étaient totalement ignorées.
Ma fonctionnalité préférée est la prise en charge du chargement progressif. WoW est un jeu énorme, mais on peut commencer à jouer avec seulement une partie des assets ; il affiche des placeholders et des assets de moindre qualité, ou saute même complètement certaines zones.
Même avec une installation entièrement neuve, on peut jouer en quelques minutes. Les joueurs considèrent généralement cela comme acquis, mais je suis reconnaissant du travail qui a manifestement dû être immense pour remplacer les roues d’un train en marche tout en livrant d’énormes volumes de données avec de bonnes performances et sans gros problèmes.
Je me demande si c’est vraiment une utilisation du temps tellement meilleure que d’attendre le téléchargement.
Steve Jobs inventait constamment des choses pour motiver les gens et les pousser, dans une sorte de champ de distorsion de la réalité
Selon Mike Slade, vers 1990, Jobs avait tenté de le recruter chez NeXT alors qu’il travaillait chez Microsoft ; à l’époque, Microsoft se préparait à l’immense succès de Windows 95, tandis que NeXT peinait à vendre ses ordinateurs
Jobs a dit à Slade qu’à Seattle son talent serait gâché, et que la Silicon Valley était le centre de l’effervescence et de l’activité, l’endroit où il pourrait s’épanouir
Il a ensuite décrit Palo Alto comme un « lieu spécial », comparable à Florence à la Renaissance italienne, improvisant une tirade passionnée sur le fait qu’on y croisait tant de talents qu’en marchant dans la rue on pouvait tomber à un moment sur un universitaire, puis l’instant d’après sur un astronaute
Slade a été tellement impressionné par cette description qu’il a décidé de déménager à Palo Alto ; un an plus tard, alors qu’il dînait avec sa femme chez Il Fornaio, une chaîne de restaurants italiens sur University Avenue à Palo Alto, il a regardé le dos du menu et y a vu la même histoire, avec une phrase du type « Palo Alto est comme Florence à la Renaissance… »
Au final, Jobs l’avait donc convaincu avec le texte du menu d’une chaîne de restaurants qu’il aimait, en plus un slogan publicitaire assez médiocre, et Slade se souvient de lui comme d’un « hâbleur vraiment sans honte »
https://www.cultofmac.com/573753/how-jobs-poached-a-microsof...
Quand j’y travaillais il y a quelques années, la seule chose mémorable dont je me souvienne dans les rues de Palo Alto, c’était l’odeur écrasante d’urine dans le passage souterrain sous la station Caltrain
Il est difficile de croire qu’un ingénieur professionnel intelligent, travaillant alors dans l’une des entreprises les plus grandes et prestigieuses au monde, ait quitté son emploi et déplacé toute sa vie dans un autre État simplement parce qu’un employeur potentiel lui avait dit « fais-moi confiance, ça va être génial »
Pour prendre une telle décision, il aurait au moins pris l’avion pour voir des appartements et visiter les bureaux. C’est une belle histoire, mais il y avait sûrement beaucoup plus de contexte
C’était le genre d’endroit où l’on allait quand toutes les autres options étaient réservées ou qu’il était trop tard pour conduire plus loin
C’était le centre du monde de l’informatique, et on pouvait réellement croiser au hasard des gens incroyables chez Fry’s, dans des restaurants ou des bars
J’ai l’impression que les jeunes d’aujourd’hui ne comprennent pas bien à quel point beaucoup de choses autour de la tech actuelle trouvent leurs racines dans le South Bay et la Peninsula des années 90
Les programmeurs et les ingénieurs devraient appliquer ce raisonnement de façon générale. Le temps total passé à attendre des logiciels lents est énorme, et davantage d’équipes de développement devraient donner une priorité plus élevée aux performances
On n’additionne pas consciemment tout le temps perdu à cause de logiciels et de services lents, mais sur le moment, cela donne inconsciemment l’impression que le système est hostile, inconfortable et agaçant
Dès qu’on y pense un peu consciemment, on en vient à mépriser les ingénieurs et les chefs de projet qui ont cru que ce qu’ils avaient construit était suffisamment bon pour être lancé
Compte tenu de la puissance de calcul des ordinateurs modernes, devoir attendre des centaines de millisecondes pour une requête triviale, ou bien plus longtemps pour une requête un peu complexe, est la preuve d’une négligence grave de la part des programmeurs
Un jeudi soir, ma copine m’a demandé de remettre en ordre un vieux MacBook, et il n’y avait que quelques étapes : dissocier des comptes liés au matériel, retrouver comment retirer une clé de firmware que j’avais sans doute configurée autrefois, faire une nouvelle installation, des mises à jour, etc.
Mais certaines étapes ou redémarrages prenaient plus que quelques secondes, et comme le travail ne cessait de me tenter ailleurs, cela a pris 6 mois
Après plusieurs interruptions, je l’ai posé sur le bureau à côté du clavier, et j’ai fini en 30 minutes au total réparties sur 6 heures ; c’était une victoire
Si quelqu’un m’avait attaché les mains au portable, j’aurais sans doute terminé plus vite, mais je n’aurais pas pu imaginer la souffrance de devoir regarder de force des écrans vides, des barres de progression et des indicateurs qui tournent
Les traitements par lots qui tournent longtemps font exception
Des ordinateurs ordinaires pouvaient démarrer à froid en moins de 30 secondes depuis un disque dur mécanique à 5400 tr/min ; je me demande donc pourquoi, avec les SSD NVMe modernes, ils ne démarrent pas en moins d’une seconde
Windows 95, avec la plupart de ses fonctionnalités, occupait environ 50 Mo à l’installation, et Windows 2000 tenait sur un seul CD d’installation
Aujourd’hui, l’installateur de Windows 10 ne tient même pas sur un DVD simple couche, et il faut renoncer à l’installer depuis une clé USB en FAT32. Certains anciens UEFI ne savent toujours pas gérer l’exFAT
L’ordinateur le plus rapide que j’aie eu à l’usage était une machine qui démarrait XP sur un double Pentium 3 866, de la Rambus et des disques SCSI U320 15k ; c’était presque télépathique
Ça ressemble au vieux problème de Windows dont le démarrage s’allonge à mesure qu’il accumule de plus en plus de bric-à-brac
Les polices système comptaient autrefois environ 200 caractères, contre des dizaines de milliers aujourd’hui
Si l’on extrapole cela à tout le reste, il devient assez évident qu’il y a beaucoup plus de choses à charger
C’est assez rapide pour que ça ne me dérange pas
Si l’on doit attendre l’ordinateur, c’est qu’il n’est pas assez rapide
Ici, le raisonnement de Steve est largement utilisé dans l’industrie et, avec son côté « si ça échoue, vous êtes des meurtriers », il frôle presque le chantage émotionnel, mais il n’en reste pas moins classique
Il est très facile de rejeter la responsabilité d’un logiciel lent sur l’utilisateur, ou sur les PM et les organisations qui privilégient les fonctionnalités et la vitesse de développement plutôt que la rapidité du produit
Le slogan de Steve signifie ici que les performances logicielles ont un impact concret sur la vie quotidienne, et le rappeler n’est pas du chantage émotionnel
Après le lancement de l’iPad, Jobs serait entré dans une réunion de l’équipe Mac avec un iPad, l’aurait sorti de veille, et celui-ci se serait allumé immédiatement
Il aurait ensuite sorti un Mac de veille, ce qui avait pris du temps, puis Jobs aurait demandé quelque chose comme : « Pourquoi celui-ci ne peut-il pas faire pareil ? »
Sans l’iPad pour montrer que c’était possible, les débats sur la vitesse de la mémoire ou du disque auraient continué, et la mise en veille/réveil plus rapide des Mac a aussi mis la pression sur Windows pour s’améliorer
Si ce raisonnement est juste, on peut se demander ce qu’il faut penser des innombrables animations présentes partout dans les UI d’aujourd’hui
Dans bien des cas, hormis pour être agréables à regarder les premières dizaines de fois, elles ne font que faire perdre du temps
Sur le téléphone que j’utilise, le sélecteur d’apps prend 0,5 à 1 seconde avec les animations, alors que si on les désactive, le changement est pratiquement instantané
Si l’écran passe instantanément à une disposition complètement différente, il faut du temps pour traiter visuellement le changement ; si les éléments se déplacent par interpolation vers leur nouvelle position, ce temps de traitement est réduit à la durée de l’animation
En général, on parle plutôt d’environ 0,25 seconde, pas de 0,5 ni de 1 seconde
Pour les obsédés de la vitesse ou les utilisateurs avancés, cela peut être gênant, donc autant leur permettre de les désactiver ; mais la cible, ce sont les utilisateurs moyens, pas ceux qui ont appris chaque recoin de l’UI par mémoire musculaire
Certaines animations peuvent se superposer à une opération qui prend du temps, donnant à l’utilisateur l’impression qu’il y a une réaction tout en le faisant patienter. iOS semble fonctionner ainsi lorsqu’il bascule vers une app qui a été swapée sur disque : comme il y a un temps de chargement, l’animation compense une partie du délai
Sans animation, l’utilisateur peut croire que son action n’a pas été correctement prise en compte et tenter de la répéter, ce qui mène à de la frustration
Certaines animations sont nécessaires pour préserver le sens de l’orientation de l’utilisateur dans le flux de l’UI. Par exemple, l’animation de minimisation déplace la fenêtre vers l’icône sur laquelle il faudra cliquer pour la restaurer, et aide à distinguer fermeture et minimisation
Certaines animations sont nécessaires pour fournir un retour approprié tout en conservant la réactivité. Lorsqu’on fait défiler une liste sur écran tactile, sans l’animation de ressort en bout de liste, l’utilisateur n’a aucun moyen de savoir s’il a atteint la fin ou si l’écran tactile s’est bloqué
Les interfaces système des consoles de jeux vidéo et certains menus de jeux me semblent particulièrement mauvais sur ce point
À 25 fps, une courte animation de 200 ms ne comporte que 5 images, ce qui donne un rendu saccadé et grossier
Si on la porte à 1000 ms, elle paraît fluide et agréable, mais elle devient désespérante à utiliser
La solution sera peut-être impopulaire, mais il suffit d’utiliser un iPhone. Le sélecteur d’apps réagit aussi vite que le mouvement du doigt, et maintenir un 60 fps constant ne pose pas problème
Ce n’était pas lent au point d’être inutilisable, mais c’était perceptible ; en fait, la vitesse des animations était réglée beaucoup trop bas par défaut
En la doublant, tout a donné l’impression d’être 1 000 fois mieux
Windows 11 met environ 12 minutes à démarrer depuis un HDD. Imaginez qu’on essaie de démarrer depuis un FDD
Après avoir installé Windows 11, attendre l’installation de toutes les mises à jour depuis un HDD prend environ 8 jours
https://www.youtube.com/watch?v=MpNagBwWlNk
Il y a quelque temps, en essayant de créer un système en dual boot, j’ai abîmé les partitions d’un iMac 2017 équipé d’un Fusion Drive, et depuis, le Mac était devenu lent
Du démarrage jusqu’au moment où il devenait à peu près utilisable, il fallait probablement 5 minutes, en tout cas c’était assez long
Le week-end dernier, lassé de cette lenteur, j’ai cherché et découvert la commande
diskutil resetFusion0, qui permet de remettre les partitions à leur état par défautAprès avoir exécuté cette commande et réinstallé l’OS, l’iMac est redevenu assez rapide. Pas excellent, mais bien meilleur qu’avant
La leçon apprise : le dual boot sur un Fusion Drive est une mauvaise idée
En général, je redémarre mes machines Windows 10 une fois tous les quelques mois, et notre service IT prépare les PC Windows en environ une heure
Quelque chose semble très mal fonctionner, mais je ne suis pas spécialiste IT
Je me souviens avoir lu autrefois un article et des discussions sur InterBase (aujourd’hui FireBase). Il y était question de l’importance, dans certains scénarios, du modèle de stockage et de restauration auto-réparatrice, avec à l’époque cette citation :
« AFATDS se compose de 935 000 lignes de code Ada exécutées sur des stations de travail HP RISC et sur les Light Weight Computer Units de l’Army », avait déclaré John Williams, de Magnavox Electronic Systems Company, le maître d’œuvre.
« Il nous fallait une base de données unique capable de s’étendre et de fonctionner sur les plateformes Unix et PC. Le produit devait s’installer rapidement et offrir une haute disponibilité sans monopoliser les ressources système. »
« Pour une aide à la décision de cette nature, il fallait une architecture modulaire et flexible prenant en charge à la fois le traitement distribué et les bases de données distribuées. C’est pourquoi nous avons choisi InterBase. Il surpassait les produits concurrents et nous a convaincus qu’on pouvait s’y fier dans des situations où des vies étaient en jeu. »
Le contexte exact de la discussion était que, dans certains chars, le tir du canon principal pouvait provoquer un événement EMP interne susceptible de redémarrer le système, et qu’il fallait donc un temps de redémarrage et de restauration très rapide pour pouvoir tirer à nouveau.
Je me demande ce qu’aurait pensé Steve s’il avait su combien de millions de vies disparaîtraient à force de faire défiler sans fin du contenu sur une petite plaque de verre.