De mogelijkheid voor applicaties om echt gebruik te maken van meerdere cores voor individueel gebruik op een desktop was een langdurige spanning met Intel. Heel ver terug, met de introductie van eerst MMX en daarna hyper-threading (virtuele meerdere cores) en vervolgens echte cores, waren er gewoon niet zoveel scenario's voor meerdere cores voor single-user systemen. Een van de grote kritiekpunten die Intel (en veel tech reviewers) gebruikte over ARM toen we aankondigden te verhuizen, was het gebrek aan meerdere cores. Er waren veel theoretische ideeën. Intel ging door Office en kwam met alles van spellingscontrole, videoconferenties, e-mailzoekopdrachten, of beeldcompressie/decompressie (toen JPEG nieuw was), tot sheet recalc. Er waren veel "achtergrond" taken (in wezen handmatig gecodeerd virtueel multi-process model) die we in Office hadden, maar het werk om ze multi-threaded/core te maken versus de idle tijd die we gebruikten was veel en de winst was klein. We zagen ook dat het architectureren voor threads/meerdere processors behoorlijk kostbaar was in geheugen en/of codecomplexiteit. Uiteindelijk konden individuen toch maar zo snel werken. Dingen die echt belangrijk waren, zoals spelling, waren niet super moeilijk. Vaak eindigden de meest interessante scenario's, zoals video-codec of printen, met het worden overgedragen aan gespecialiseerde processors of gewoon minder belangrijk. Browsen (als een applicatie) profiteerde van de beveiliging, isolatie, en zeker de laadtijd voor complexe pagina's (code, afbeeldingen, enz.) werd geoptimaliseerd voor moderne processorarchitectuur. Sommigen zouden kunnen beweren dat die overmatig werden gebruikt voor het voordeel. Dat gebeurt wanneer nieuwe technologieën zich verspreiden. Er waren systeemwijde dingen die profiteerden van de betrouwbaarheid en echte achtergrondverwerking die erg belangrijk werden—zoals lokale contentindexering of browsen. Maar na verloop van tijd werd het doen van deze dingen lokaal minder belangrijk. Zoals met veel dingen, hadden ontwikkelaars veel gebruik voor hun eigen tools en werk, wat de belangrijkheid van dit scenario scheef trok. Onze eigen ontwikkelaars draaiden altijd meerdere builds en tests op de achtergrond terwijl ze ander werk deden (browsen). Hoog I/O gebonden processen zoals die profiteerden aanzienlijk van meerdere cores/processen/threads. Ja, er waren altijd manieren om dit goed te doen, maar uiteindelijk zou het veel beter zijn geweest als al die energie naar graphics was gegaan, wat we Intel bleven vertellen totdat graphics een meer gespecialiseerde processor werd waar Intel niet enthousiast over kon worden.