Na, es ist halt keine große zusammenhängende Maschine von der Softwareseite aus. Und es ist wohl immer noch völlig unmöglich einfach eine klasischen "Code" auf sowas so auszuführen, daß er automatisch optimal so zerlegt und umgebaut wird, daß man die ganzen Recheneinheiten auslastet. Irgendwie wird sowas bis heute "händsich" angepaßt und auch Games hängen wohl immer noch auf der Entwicklungsstufe, daß es einen Hauptsteuerteil gibt und dann Nebenteile, die speziell angepaßt sind auf mehrere Cores, aber eben auch nicht wirklich automatisch rausbekommen, wie sie nun "am Besten" auszuführen sind. Dadurch liegt immer mal eine Ganze Menge Rechenpower brach. (Nur große Datenbanken können das wohl; und wenn man viele Anwendungen parallel offen hat, trägt das auch.)(Auf einer Blademaschine dürfte das Thema nochmal komplizierter sein, als auf einer "einfachen" Multi-Core Maschine, die ja mittlerweile mit 8, 16, 24 Cores daherkommen.)
Ich glaube auch, das hat viel mit Latenzen und der großen Komplexität beim Zerlegen und Verteilen solcher Prozesse/Threads zu tun. Warum sonst versucht man immer mehr Cores möglichst dicht beieinander mit zusätzlichem Cache auf einem Die zu bekommen?
Andererseits haben sich gerade im Big Data- und Container-Umfeld längst Frameworks erfolgreich durchgesetzt, die skalierbare Rechenressourcen mit standard Serverhardware bereitstellen. Diese Frameworks wurden unter anderem von den großen Cloudanbietern wie Google, LinkedIn, Twitter und Co. entwickelt und stehen als Open Source unter der Apache License zur Verfügung. Die darauf laufenden Applikationen sind dann jedoch immer für bestimmte Anwendungsfälle konzipiert. Siehe z.B. Spark als In-Memory Realtime Data Analytics und Streaming Applikation, oder Hbase die spaltenorientierte no-SQL Datenbank aus dem Hadoop Framework. Diese Techniken existieren ja schon recht lange und sie ermöglichen hohe Skalierbarkeit und Ausfallsicherheit durch viele Server(-blades).
Daneben gibt es dann noch die Container Orchestrierungs Tools wie z.B. Kubernetes/OpenShift und Mesos, die die Hardware Ressourcen vieler Server verwalten und sie (Docker)-Containern zur Verfügung stellen. Damit lassen sich Container-Applikationen hoch skalieren und ausfallsicher betreiben. Aber auch hier gilt: Die Ressourcen-Grenzen eines Containers oder Pods sind immer die physischen Grenzen des einzelnen Servers auf dem er läuft. Kubernetes kümmert sich aber bei Bedarf darum viele Container einer Applikation zu starten und zu überwachen. Klassisches Beispiel ist die Web-Applikation, die als Container läuft und von der bei hoher Last einfach mehrere Instanzen gestartet werden, die per Loadbalancer entsprechend angesprochen werden.