Wie es richtig geht, sieht man an den Konsolenspielen, was da aus der doch eher lahmen APU rausgeholt wird, ist schon beachtlich.
Dort haben die Entwickler aber auch das Wissen, wie das Environment aus sieht. Naemlich bei allen gleic, oder maximal 2 Environments (normal und Pro/X Konsole). Damit kann man halt genau darauf optimieren und muss nicht fuer verschiedene Leistungsklassen noch mit verschiedenen Settinglevels arbeiten.
Parallelisierung ist wirklich ein weites Feld. Am wichtigsten wird bei Spielen sein, ob die API, der die Daten am, Ende uebergeben werden, parallel aufgerufen werden kann und diese dann (z.B.) das Bild daraus im Zeitlimit zusammensetzen kann oder ob dabei die Daten alle aus einem Thread kommen muessen.
Oder kann das benutzte Modell fuer das Spiel (Raeume, Figuren, ...) sinnvoll parallel von verschiedenen Threads berechnet werden, damit Aufteilung und Zusammenfuehrung der Daten am Ende nicht die gleiche oder mehr Zeit benoetigen.
Und natuerlich noch, bleibt das Spiel dann bei den Mindestanforderungen, wenn z.B. nur ein DualCore genutzt wird, spielbar. Oder muesste der Entwickler verschiedene Implementierungen, abhaenig von der Anzahl der Cores bauen, was am Ende Fehleranfaelligkeit und Testaufwand erhoeht.
Bei wissenschaftlichen Sachen gibt es halt teilweise nicht ein Zeitlimit (z.B. 16ms pro Frame), um das Ergebniss zu erzeugen (stark vereinfacht). Da kann halt ein Rechner 1 Ergebnis pro Tag berechnen und 24 Rechner damit 24 Ergebnisse. Oder 24 Rechner erstellen ein Ergebnis nach ner Stunde und kommen am Ende auch auf 24 Ergebnisse am Tag.
Ich gehe einfach immer davon aus, dass die Entwickler entsprechend ihren Frameworks, Wissen und Vorgaben (techn. und finanziell) die beste Loesung abliefern. Als Kunde kann ich dann an der Kasse entscheiden, ob mir das gelieferte Ergebnis passt.