- Der Macintosh galt dank des 68000-Mikroprozessors als schneller Computer, doch in der Praxis wurde die Diskette zum Geschwindigkeitsengpass
- Der Punkt, den Steve Jobs besonders problematisch fand, war die Bootzeit nach dem Einschalten: Speichertest, Initialisierung des Betriebssystems und Laden des Finders
- Jobs setzte Larry Kenyon unter Druck: Wenn man den Bootvorgang um 10 Sekunden verkürze, sparten 5 Millionen Nutzer täglich 50 Millionen Sekunden – auf ein Jahr gerechnet entspreche das dem Leben von Dutzenden Menschen
- Da das Team ohnehin bereits motiviert war, die Software-Performance zu verbessern, ist unklar, wie stark diese Rechnung tatsächlich wirkte
- Am Ende verkürzte das Macintosh-Team einige Monate später die Bootzeit um mehr als 10 Sekunden, und Jobs’ Art der Überzeugung blieb als humorvolle Anekdote in Erinnerung
Der Engpass des Macintosh war die Diskette
- Das Macintosh-Team hielt ihn für einen schnellen Computer, weil der 68000-Mikroprozessor praktisch 10-mal schneller war als der Apple II
- Da der RAM jedoch begrenzt war, mussten häufig Daten von der Diskette gelesen werden, und in diesem Punkt war er nicht schneller als der Apple II
- Als die tatsächlichen Anwendungen zu laufen begannen, stellte sich die Diskette als zentraler Engpass heraus
Steve Jobs nahm die Bootzeit hartnäckig ins Visier
- Einer der Punkte, die Jobs am meisten störten, war die Bootzeit, wenn man den Mac zum ersten Mal einschaltete
- Speichertest
- Initialisierung des Betriebssystems
- Laden des Finders
- Dieser Vorgang konnte mehrere Minuten oder sogar länger dauern
- Jobs forderte Larry Kenyon, der für den Disk-Treiber und das Dateisystem zuständig war, auf, den Macintosh schneller booten zu lassen, weil der Start zu langsam sei
Die Rechnung: „10 Sekunden sparen heißt Leben retten“
- Larry Kenyon versuchte zu erklären, wo Verbesserungen möglich waren, doch Jobs interessierte sich nicht für diese Erklärung
- Jobs nahm an, dass einige Jahre später 5 Millionen Menschen mindestens einmal täglich einen Macintosh booten würden
- Wenn man die Bootzeit um 10 Sekunden verkürze, spare man täglich 50 Millionen Sekunden; auf ein Jahr gerechnet entspreche das dem Leben von Dutzenden Menschen
- Deshalb sagte er, den Bootvorgang um 10 Sekunden schneller zu machen, sei so wertvoll wie „Dutzende Leben zu retten“
Das tatsächliche Ergebnis
- Da das Team die Software ohnehin so schnell wie möglich machen wollte, ist nicht sicher, wie groß Jobs’ Einfluss mit dieser Überzeugungsarbeit wirklich war
- Seine Art der Argumentation wurde im Team allerdings als ziemlich humorvoll aufgenommen
- In den folgenden Monaten wurde die Bootzeit des Macintosh tatsächlich um mehr als 10 Sekunden verkürzt
1 Kommentare
Meinungen auf Hacker News
Eine Geschichte, die ich von einem langjährigen Apple-Ingenieur gehört habe: Zu Zeiten von MacOS 8.x war in Nutzerbefragungen die größte Beschwerde die Bootzeit.
Damals dauerte sie im Schnitt etwa 45 Sekunden, und da das System bereits den Ruhezustand unterstützte, fragte man sich, warum die Leute sich überhaupt für die Bootzeit interessierten.
Wie sich herausstellte, starteten die Leute nicht einfach einmal am Tag oder einmal pro Woche neu, sondern wegen Instabilität sehr häufig. Im neuen Release verbesserte man zwar auch den Bootvorgang, konzentrierte sich aber stärker darauf, das Betriebssystem stabiler zu machen.
Am Ende verschwanden die Beschwerden über die Bootzeit nicht, weil sie unglaublich schnell geworden wäre, sondern weil die Leute viel seltener neu starten mussten. Die Lehre war: Man muss nicht nur verstehen, was Kunden verlangen, sondern auch warum sie es verlangen.
Auch die Regeln fürs Patchen waren unklar: Es konnte zum Beispiel Codepfade geben, die innerhalb eines gepatchten Systemaufrufs Speicher allokierten, was man nicht tun durfte, weil der Speichermanager nicht reentrant war.
Dazu lief Code, der mit damaligen C-Compilern gebaut worden war, und Werkzeuge zum Verhindern von Speicherschreibzugriffen außerhalb des gültigen Bereichs waren sehr begrenzt.
Auch MacOS 8 führte einen sehr eingeschränkten Speicherschutz ein, der in der Praxis kaum half. Im Kontext geht es hier darum, wie gut und wie willens eine Organisation ist, ein Problem rational zu erfassen.
Dieses Problem hätte Apple geschäftlich beinahe umgebracht.
Als ein Freund seiner Frau Mac OS X zum ersten Mal zeigte und es herunterfahren wollte, verzog sie das Gesicht und sagte: „Das Gute am Mac war doch gerade, dass er sofort ausging.“ Darauf antwortete er: „Dann musst du wohl etwas anderes finden, das du an Mac OS magst.“
Wenn sie jetzt schneller sind, muss man nur ein paar Jahre warten. Die Entwickler werden genügend Performance-Regressionen durchrutschen lassen, damit es wieder auf dieses Niveau steigt.
Ich glaube, ich hatte diese Geschichte schon einmal gehört und wieder vergessen. Als ich bei Blizzard das Team für Installation, Downloads und Patches leitete, sagte ich dem Team oft: „Wenn 10 Millionen Menschen diesen Patch herunterladen und installieren und wir sie eine Minute länger warten lassen, verbrauchen wir wieder einen Teil menschlicher Lebenszeit.“
Das war übertrieben und kitschig, half aber, Verbesserungen voranzutreiben.
Die wichtigere Kennzahl, die ich forcierte, war die Lichtgeschwindigkeit. In der Zeit, als man von DVD installierte, war die Drehgeschwindigkeit der Disc die Lichtgeschwindigkeit dieser Umgebung; also musste die Installation so nah wie möglich an diese Geschwindigkeit herankommen.
Man sollte die Arbeitsgeschwindigkeit so lange weiter verbessern, bis man an physikalische Grenzen stößt. Zeit ist kostbar, und man bekommt keine zusätzliche.
Wenn man große Performance-Verbesserungen in der Infrastruktur ausrollt, geht es im Kern nicht um Geschwindigkeit oder eingesparte Kosten an sich, sondern darum, dass weniger CO2 in der Atmosphäre landet und die über Millionen Menschen verteilte menschliche Zeit für anderes genutzt wird, als auf Computerantworten zu warten.
Wir sind keine Ärzte, die einzelne Leben retten, aber wir können Menschen einen Teil ihres Lebens zurückgeben. Manche Software wird von Hunderten Millionen oder Milliarden Menschen genutzt, sodass selbst kleine Änderungen Zeit in der Größenordnung mehrerer „Leben“ einsparen können.
Wenn ich mich richtig erinnere, war die torrentbasierte Patch-Verteilung für WoW und Ähnliches wirklich gut gemacht, und das war in einer Branche mit hohem Druck besonders beeindruckend.
Ich habe viele Ingenieure gesehen, die man durchaus als fleißig bezeichnen könnte, die aber kaum Zeit darauf verwendeten, die Hardware, auf der sie liefen, und das, was darauf möglich war, zu verstehen.
In Performance-Diskussionen habe ich viel zu oft „langsam“ oder „in Ordnung“ gehört, obwohl die zugrunde liegende Maschine und ihre möglichen Grenzen völlig ignoriert wurden.
Mein Lieblingsfeature ist die Unterstützung für inkrementelles Laden. WoW ist ein riesiges Spiel, aber man kann schon mit nur einem Teil der Assets zu spielen beginnen; es zeigt dann Platzhalter und Assets niedrigerer Qualität an oder überspringt bestimmte Gebiete ganz.
Selbst nach einer komplett neuen Installation kann man innerhalb weniger Minuten spielen. Spieler halten das meist für selbstverständlich, aber ich bin dankbar, weil der Aufwand enorm gewesen sein muss, die Räder eines fahrenden Zugs zu wechseln und dabei riesige Datenmengen ohne größere Probleme und mit hoher Performance auszuliefern.
Ich frage mich, ob das wirklich eine so viel bessere Nutzung der Zeit ist, als auf den Download zu warten.
Steve Jobs erfand ständig irgendetwas, um Menschen zu motivieren und anzutreiben – ganz im Stil des sogenannten Reality Distortion Field.
Laut Mike Slade versuchte Jobs ihn um 1990 herum von Microsoft zu NeXT zu holen. Microsoft stand damals kurz vor dem Riesenerfolg Windows 95, während NeXT Schwierigkeiten hatte, Computer zu verkaufen.
Jobs sagte Slade, in Seattle würde sein Talent verschwendet, und das Silicon Valley sei das Zentrum von Aufbruch und Aktivität, ein Ort, an dem er aufblühen könne.
Dann beschrieb er Palo Alto als einen „besonderen Ort“, ähnlich wie Florence zur Zeit der italienischen Renaissance, und hielt spontan eine flammende Rede darüber, wie sehr es dort vor Talent wimmele – man könne auf der Straße in einem Moment einem Gelehrten begegnen und im nächsten einem Astronauten.
Slade war von dieser Beschreibung so überwältigt, dass er beschloss, nach Palo Alto zu ziehen. Ein Jahr später aß er mit seiner Frau im Il Fornaio, einem italienischen Kettenrestaurant auf der University Avenue in Palo Alto, und sah auf der Rückseite der Speisekarte den Satz „Palo Alto ist wie Florence in der Renaissance …“ samt derselben Geschichte stehen.
Am Ende hatte Jobs ihn also mit dem Text einer Speisekarte einer von ihm gemochten Restaurantkette überzeugt, noch dazu mit einem ziemlich schlechten Werbespruch; Slade erinnerte sich daran, Jobs sei ein „wirklich schamloser Aufschneider“ gewesen.
https://www.cultofmac.com/573753/how-jobs-poached-a-microsof...
Als ich vor ein paar Jahren dort arbeitete, blieb mir von den Straßen Palo Altos vor allem der überwältigende Uringestank in der Unterführung unter der Caltrain Station in Erinnerung.
Es ist schwer zu glauben, dass ein kluger, professioneller Ingenieur, der damals bei einem der größten und angesehensten Unternehmen der Welt arbeitete, nur wegen eines „Vertrau mir, es ist großartig“ eines potenziellen Arbeitgebers kündigte, sein ganzes Leben umkrempelte und in einen anderen Bundesstaat zog.
Für so eine Entscheidung wäre er vermutlich zumindest hingeflogen, hätte sich Wohnungen angesehen und das Büro besucht. Eine schöne Geschichte, aber es muss sicher deutlich mehr Kontext gegeben haben.
Das war eher ein Restaurant, in das man ging, wenn alle anderen Optionen ausgebucht waren oder es zu spät war, noch weiter zu fahren.
Es war das Zentrum der Computing-Welt, und man traf bei Fry’s, in Restaurants oder Bars tatsächlich zufällig erstaunliche Leute.
Ich glaube, viele junge Leute heute verstehen nicht richtig, wie viel von der heutigen Techniklandschaft seine Wurzeln in den 90ern in der South Bay und auf der Peninsula hat.
Programmierer und Ingenieure sollten diese Denkweise insgesamt anwenden. Die Gesamtmenge an Zeit, die mit Warten auf langsame Software vergeudet wird, ist enorm, und mehr Entwicklungsteams sollten Performance höher priorisieren.
Man addiert die ganze Wartezeit durch langsame Software und Services nicht bewusst, aber in diesen Momenten fühlt es sich unbewusst so an, als arbeite das System gegen einen, unangenehm und nervig.
Sobald man auch nur ein wenig bewusst darüber nachdenkt, verachtet man die Ingenieure und Projektleiter, die glaubten, das von ihnen Gebaute sei gut genug für die Veröffentlichung.
Angesichts der Rechenleistung moderner Computer sind Hunderte Millisekunden Wartezeit für triviale Anfragen – oder deutlich längere Wartezeiten für etwas komplexere Anfragen – ein Beleg für grobe Fahrlässigkeit von Programmierern.
Am Donnerstagabend bat mich meine Freundin, ein altes MacBook aufzuräumen. Es waren nur ein paar Schritte: hardwaregebundene Account-Verknüpfungen lösen, herausfinden, wie man einen von mir früher gesetzten Firmware-Schlüssel entfernt, neu installieren, Updates einspielen.
Aber einige Schritte oder Neustarts dauerten länger als eine einstellige Zahl von Sekunden, und die Arbeit lockte mich ständig weg; deshalb brauchte es 6 Monate.
Nachdem ich mehrfach unterbrochen hatte, stellte ich es neben die Tastatur auf den Schreibtisch, und über 6 Stunden hinweg erledigte ich es in insgesamt 30 Minuten – ein Sieg.
Hätte mir jemand die Hand an den Laptop gebunden, wäre es schneller gegangen, aber der Schmerz, gezwungen zu sein, auf leere Bildschirme, Fortschrittsbalken und Spinner zu starren, wäre unvorstellbar gewesen.
Ausnahmen sind Dinge wie lange laufende Batch-Jobs.
Schon ein gewöhnlicher Computer konnte von einer rotierenden 5400-rpm-Festplatte in unter 30 Sekunden kalt booten; da fragt man sich, warum moderne NVMe SSDs nicht in unter einer Sekunde booten können.
Windows 95 brauchte mit den meisten Funktionen etwa 50 MB Installationsplatz, und Windows 2000 passte auf eine einzige Installations-CD.
Der aktuelle Windows-10-Installer passt nicht einmal mehr auf eine Single-Layer-DVD, und die Installation von einem FAT32-USB-Stick kann man ebenfalls vergessen. Einige ältere UEFI-Systeme können immer noch nicht mit exFAT umgehen.
Der gefühlt schnellste Computer, den ich je benutzt habe, war eine Maschine, die XP auf einem Dual Pentium 3 866, Rambus und 15k-U320-SCSI-Platten bootete; das fühlte sich fast wie Telepathie an.
Das wirkt wie das alte Problem, dass der Bootvorgang länger wird, je mehr Gerümpel Windows ansammelt.
Systemschriften umfassten früher etwa 200 Zeichen, heute enthalten sie Zehntausende.
Wenn man das auf alles andere hochrechnet, wird ziemlich klar, dass heute viel mehr geladen werden muss.
Schnell genug, dass es mich nicht stört.
Wenn man auf den Computer warten muss, ist er nicht schnell genug
Steves Logik hier ist in der Branche weit verbreitet, und weil sie nach dem Muster „wenn es scheitert, seid ihr Mörder“ funktioniert, kommt sie fast einer emotionalen Erpressung gleich, ist aber trotzdem klassisch
Es ist sehr leicht, die Verantwortung für langsame Software den Nutzern zuzuschieben oder PMs bzw. Organisationen, die Features und Entwicklungstempo über die Produktgeschwindigkeit stellen
Steves Parole bedeutet hier, dass Software-Performance reale Auswirkungen auf den Alltag hat, und darauf hinzuweisen ist keine emotionale Erpressung
Nach der Einführung des iPad soll Jobs mit einem iPad in ein Meeting des Mac-Teams gekommen sein, das iPad aufgeweckt haben, und es sei sofort an gewesen
Danach habe er einen Mac aufgeweckt, der zum Aufwachen aus dem Ruhezustand eine Weile brauchte, worauf Jobs gefragt haben soll: „Warum kann das hier nicht so sein?“
Ohne das iPad, das zeigte, dass es möglich ist, wären wohl Debatten über Speichergeschwindigkeit und Festplattengeschwindigkeit weitergegangen; schnelleres Sleep/Wake beim Mac wurde dann auch zu einem Druckmittel, damit Windows besser wird
Wenn diese Logik stimmt, frage ich mich, was mit den vielen Animationen überall in heutigen UIs ist
Abgesehen davon, dass sie die ersten paar Dutzend Male hübsch aussehen sollen, verschwenden sie oft nur Zeit
Der App-Umschalter auf meinem Smartphone braucht mit Animation 0,5 bis 1 Sekunde, ohne Animation wechselt er praktisch sofort
Wenn der Bildschirm sofort zu einem völlig anderen Layout springt, braucht die visuelle Verarbeitung Zeit; wenn sich Elemente interpoliert an ihre neue Position bewegen, wird diese Verarbeitungszeit auf die Länge der Animation reduziert
Normalerweise sind das nicht 0,5 oder 1 Sekunde, sondern eher etwa 0,25 Sekunden
Für Speed-Freaks oder Power-User kann das störend sein, dann kann man es abschalten; die Zielnutzer sind aber durchschnittliche Nutzer, nicht Menschen, die jede Ecke der UI per Muskelgedächtnis gelernt haben
Manche Animationen können sich mit einer zeitaufwendigen Operation überlappen und dem Nutzer das Gefühl geben, dass eine Reaktion erfolgt, während er trotzdem warten muss. So wirkt es etwa, wenn iOS zu einer App wechselt, die auf die Festplatte ausgelagert wurde; da es Ladezeit gibt, kompensiert die Animation einen Teil der Verzögerung
Ohne Animation könnte der Nutzer denken, die Aktion sei nicht richtig ausgeführt worden, und versuchen, sie wiederholt einzugeben, was zu Frust führt
Manche Animationen sind nötig, um im UI-Fluss die Orientierung des Nutzers zu erhalten. Eine Minimieren-Animation bewegt ein Fenster zum Beispiel zu dem Icon, das man zum Wiederherstellen anklicken muss, und hilft, Schließen und Minimieren zu unterscheiden
Manche Animationen sind nötig, um bei erhaltener Reaktionsfähigkeit angemessenes Feedback zu geben. Wenn man auf einem Touchscreen durch eine Liste scrollt, wüsste der Nutzer ohne die Feder-Animation am Ende nicht, ob er am Ende der Liste ist oder ob der Touchscreen nicht mehr reagiert
Die System-UIs von Videospielkonsolen und manche Spielmenüs scheinen in dieser Hinsicht besonders schlimm zu sein
Eine kurze 200-ms-Animation bei 25 fps hat nur fünf Frames und wirkt ruckelig und billig
Macht man sie 1000 ms lang, sieht sie flüssig und gut aus, ist aber beim Benutzen eine Katastrophe
Es mag eine unpopuläre Lösung sein, aber man kann ein iPhone verwenden. Der App-Umschalter reagiert so schnell wie die Fingerbewegung, und konstante 60 fps sind kein Problem
Es war nicht unbenutzbar langsam, aber spürbar; wie sich herausstellte, war die Animationsgeschwindigkeit standardmäßig viel zu niedrig eingestellt
Nachdem ich sie verdoppelt hatte, fühlte sich alles 1.000-mal besser an
Windows 11 braucht auf einer HDD etwa 12 Minuten zum Booten. Man kann sich vorstellen, es würde versuchen, von einer FDD zu booten
Wenn man Windows 11 installiert und dann auf einer HDD wartet, bis alle Updates installiert sind, dauert das etwa 8 Tage
https://www.youtube.com/watch?v=MpNagBwWlNk
Vor einiger Zeit habe ich beim Versuch, ein Dual-Boot-System einzurichten, die Partitionen eines 2017er iMac mit Fusion Drive zerschossen, und danach wurde der Mac langsam
Vom Start bis zu einem halbwegs brauchbaren Zustand dauerte es vermutlich etwa 5 Minuten, jedenfalls ziemlich lange
Letztes Wochenende hatte ich die Langsamkeit satt und suchte nach einer Lösung; dabei fand ich den Befehl
diskutil resetFusion0, der die Partitionierung auf die Standardwerte zurücksetztNachdem ich diesen Befehl ausgeführt und das OS neu installiert hatte, war der iMac wieder recht schnell. Nicht großartig, aber deutlich besser als vorher
Die Lehre daraus ist, dass Dual Boot auf einem Fusion Drive eine schlechte Idee ist
Normalerweise boote ich meine Windows-10-Maschine alle paar Monate neu, und unsere IT-Abteilung richtet Windows-PCs innerhalb von etwa einer Stunde ein
Da scheint etwas gründlich schiefzulaufen, aber ich bin kein IT-Experte
Ich erinnere mich, früher einen Artikel und eine Diskussion über InterBase (heute FireBase) gesehen zu haben. Es ging darum, dass das Speichermodell und das selbstheilende Wiederherstellungsmodell in bestimmten Szenarien wichtig seien; damals gab es dieses Zitat:
„AFATDS besteht aus 935.000 Zeilen Ada-Code, der auf HP-RISC-Workstations und den Light Weight Computer Units der Army läuft“, sagte John Williams von der Hauptauftragnehmerin Magnavox Electronic Systems Company.
„Wir brauchten eine einzelne Datenbank, die über Unix- und PC-Plattformen hinweg skalieren und funktionieren konnte. Das Produkt musste schnell zu installieren sein und hohe Verfügbarkeit bieten, ohne die Systemressourcen zu monopolisieren.“
„Entscheidungsunterstützung dieser Art erforderte eine modulare, flexible Architektur, die sowohl verteilte Verarbeitung als auch verteilte Datenbanken unterstützt. Deshalb haben wir uns für InterBase entschieden. Es war leistungsfähiger als Konkurrenzprodukte und überzeugte uns, dass man sich auch in Situationen, in denen es um Leben und Tod geht, darauf verlassen kann.“
Der genaue Kontext der Diskussion war, dass bei manchen Panzern beim Abfeuern der Hauptkanone ein internes EMP-Ereignis auftreten konnte, wodurch das System neu startete; damit man erneut feuern konnte, waren daher sehr schnelle Neustart- und Wiederherstellungszeiten nötig.
Ich frage mich, was Steve gedacht hätte, wenn er gewusst hätte, wie viele Millionen von Leben durch endloses Scrollen auf einer kleinen Glasscheibe verschwinden würden.