Jetzt mal langsam
Die alten Konsolen hatten kein x86 und mussten komplett anders Programmiert werden um diese Effizient ausnutzen zu können. Desweiteren hatte die Xbox360 "nur" 3 Kerne mit SMT, von denen wohl einer für das OS + Kinect zuständig ist. Also im Übertragenen Sinne ein i3.
Die PS3 ist nochmal was ganz anderes und mit nem PC mMn. nicht zu vergleichen.
Wieso mussten die Konsolen anders programmiert werden? Ich seh das klar nicht so...
Falls du damit dran anspielen willst, dass ggf. eine andere Programmiersprache zum einsatz kam/kommt, mag sein. Wobei auch das nicht sicher ist... Oder darauf, das womöglich Optimierungen speziell auf die Hardware anders von statten gehen, ja auch das mag sein. Deswegen wird aber nicht anders programmiert...
Was ich dir aber definitiv sagen kann, das sich das Programmieren selbst (in der jeweiligen Programmiersprache) nicht sonderlich voneinander unterscheidet.
Der Programmcode bleibt der Programmcode, und das was irgendwelche Compiler usw. draus machen ist dann auf die jeweilige Hardware zugeschnitten.
Aus "(A + B) / C" wird mit anderer Hardware auch nix Anderes. Und im Endeffekt ist das alles nur Zahlenschubserei, nicht mehr und nicht weniger...
Du kannst also den Code via x86 Hardware abfackeln, genau so wie es potentiell möglich ist, diesen auf anderer Hardware (ARM, PowerPC, whatever) abzufackeln. Was potentiell problematisch ist, sind Librarys, die ggf. nicht verfügbar sind, aber Anwendung finden oder spezielle Befehlserweiterungen, die nicht verfügbar sind. Selbst ne GPU würde das können, wenn man sie anspricht.
Worauf willst du also hinaus?
Aber ja, 3 Kerne + SMT sind bei mir immernoch min. 6 Threads.
Und die PS3 hat 7 SPEs, was wohl durchaus als "Cores" bezeichnet werden kann.
Den Speedvorteil durch Multithreading, den du ansprichst, der ist aktuell auf dem PC durch DX11 limitiert (Masterthread mit DX overhead) durch Mantle und später DX12 wird dieser Flaschenhals beseitigt [siehe diverse Mantle news].
Das ist aber der Marketingquatsch, den die Kunden glauben, der aber eben auch nur die halbe Wahrheit erzählt.
Siehe obiges Beispiel. Aus "(A + B) / C" wird auch mit Mantle oder DX12 keine "Arbeit" die du auf zwei (oder mehr) Threads verteilen kannst.
Was aber heute völlig ohne jegliche DX Geschichten funktioniert ist einfach mehrfach Berechnungen ausführen oder eben Komplexere davon zu nutzen. "(A + B) / C" sowie "(D + E) / F" kannst du wunderschön gleichzeitig abfackeln. Es wird aber nicht schneller! Das ist der Unterschied, den ich oben ansprach. Du bekommst mehr Berechnungen zur gleichen Zeit getätigt. Aber diese werden nicht schneller berechnet.
Was ihr (oder besser, die Leute hier) aber wollen ist nicht nur mehr zur gleichen Zeit, sondern das was berechnet wird, eben schneller. Zwei völlig grundverschiedene paar Schuhe...
Mit was willst du die Threads eigentlich sonst noch füllen? Physik, KI, Pathfinding sind alles dinge, die sich gut Parallelisieren lassen und evtl jetzt etwas übertrieben gesagt der Großteil eines Spiels.
Ansonsten gibts im Hintergrund je nach spiel noch Netzwerk, Wirtschaft und geskriptete Aktionen. Was sich auch alles auf einzelne Threads verteilen lässt.
Aber wirklich interessant wird das ganze erst, wenn die GPU für einen Teil dieser Berechnungen verwendet wird, deswegen kann ich nicht ganz verstehen, warum hier alle eine APU nicht toll finden, die iGPU der APU als Physik Co-Prozessor oder für das Pathfinding verwenden, oder die KI mittles OpenCL.
Deswegen sagte ich ja, die Sachen, die heute primär breite CPUs vorraussetzen bedienen sich eben dem Konstrukt, dass man einfach "mehr" komplexere Berechnungen einbaut.
Und ja, die APU wäre dafür durchaus in der Lage. Für mich bleibt am Ende dabei nur das Problem, dass es auch funktionieren muss. Und vor allem, was ist mit der Leistung? Ne APU ohne dGPU dazu hat sich doch heute schon "schwer" das Spiel als solchen zu stämmen. Noch mehr drauf abladen? Ne... Das kann nicht zielführend sein.
Was ich dabei auch noch äußerst wichtig finde, der Nutzer sollte die Wahl haben
Gutes Beispiel ist TressFX vs. PhysX (auch wenn es nicht ganz vergleichbar ist). Bei PhysX per GPU kannst du die GPU wählen, die die Berechnungen tätigt. Bei TressFX funkt das nicht. Heist, TR läuft halt wie es läuft. Mit ner zweiten GPU aber hätte man die Berechnungen auslagern können um mehr Luft für das eigentliche Spiel zu haben. Geht aber nicht. PhysX kann das als Beispiel...
Zumal diese schön Langsam sind was zur Multithreadoptimierung zwingt. Die PS4 ist ja ne HSA Konsole mit gemeinsamen Speicher.
Was hat das eine mit dem anderen zu tun??
Häufig wird das genommen, was gerade da ist... Und wenn das dann NV ist, schneiden oft die breiteren CPUs besser ab als unter einer AMD GPU 
