Die Fähigkeit von Anwendungen, wirklich von mehreren Kernen für die individuelle Nutzung auf einem Desktop zu profitieren, war ein langanhaltender Konflikt mit Intel. Schon lange zurück, mit der Einführung von MMX und dann Hyper-Threading (virtuelle Mehrkernprozessoren) und dann echten Kernen, gab es einfach nicht so viele Szenarien für mehrere Kerne in Einbenutzersystemen. Eine der großen Kritiken, die Intel (und viele Technik-Rezensenten) über ARM äußerten, als wir die Umstellung ankündigten, war der Mangel an mehreren Kernen. Es gab viele theoretische Ideen. Intel durchlief Office und kam mit allem von Rechtschreibprüfung, Videokonferenzen, E-Mail-Suche oder Bildkompression/-dekompression (als JPEG neu war) bis hin zu Tabellenneuberechnungen. Es gab viele "Hintergrund"-Aufgaben (essential hand coded virtual multi-process model), die wir in Office hatten, aber die Arbeit, um sie mehrkernfähig zu machen, im Vergleich zur Leerlaufzeit, die wir verwendeten, war groß und der Gewinn war gering. Wir sahen auch, dass die Architektur für Threads/mehrere Prozessoren ziemlich kostspielig in Bezug auf Speicher und/oder Codekomplexität war. Letztendlich konnten Einzelpersonen sowieso nur so schnell arbeiten. Dinge, die wirklich wichtig waren, wie Rechtschreibung, waren nicht besonders schwierig. Oft endeten die interessantesten Szenarien wie Video-Codecs oder Drucken damit, dass sie auf spezialisierte Prozessoren ausgelagert wurden oder einfach weniger wichtig waren. Das Browsen (als Anwendung) profitierte von der Sicherheit, Isolation und sicherlich wurde das Laden von Seiten für komplexe Seiten (Code, Bilder usw.) für moderne Prozessorarchitekturen optimiert. Einige könnten argumentieren, dass diese überbeansprucht wurden, um den Nutzen zu maximieren. Das passiert, wenn neue Technologien sich verbreiten. Es gab systemweite Dinge, die von der Zuverlässigkeit und der echten Hintergrundverarbeitung profitierten, die sehr wichtig wurden – wie die lokale Inhaltsindizierung oder das Browsen. Aber im Laufe der Zeit wurde es weniger wichtig, dies lokal zu tun. Wie bei vielen Dingen hatten Entwickler viele Verwendungsmöglichkeiten für ihre eigenen Werkzeuge und Arbeiten, was die Bedeutung dieses Szenarios verzerrte. Unsere eigenen Entwickler führten immer mehrere Builds und Tests im Hintergrund durch, während sie andere Arbeiten (Browsing) erledigten. Stark I/O-gebundene Prozesse wie diese profitierten erheblich von mehreren Kernen/Prozessen/Threads. Ja, es gab immer Möglichkeiten, dies gut zu machen, aber letztendlich wäre es viel besser gewesen, all diese Energie in die Grafik zu stecken, was wir Intel immer wieder sagten, bis die Grafik zu einem spezialisierteren Prozessor wurde, für den Intel sich nicht begeistern konnte.