JesusOfCool hat geschrieben:jo, das meinte ich.
ich denke den controller haben wir alle verstanden und für mich ist der rest eigentlich fast interessanter... weil wir das noch nicht als bestätigt ansehen können
mich würd hier jetzt natürlich die meinung von yopparai interessieren.
aber erstmal ein bisschen vergleichen mit der xbo und ps4:
takfrequenzen der geräte (in GHz)
PS4: 1,6
PS4 Pro: 2,1
XBO: 1,75
Switch: 2
CPU kerne
PS4/Pro: 8
XBO: 8
Switch: 4
rohe GPU Rechenleistung (in TFlops) (ist ein theoretischer wert)
PS4: 1,84
PS4 Pro: 4,2
XBO: 1,31
Switch: ca 1 (1 GHz * 1024 flops/cycle)
bei wikipedia kann ich irgendwie die shaderdaten nicht richtig interpretieren.
arbeitsspeicher:
PS4: 8GB GDDR5 shared bei 176 GByte/s
PS4 Pro: 8GB GDDR5 shared bei 218 GByte/s
XBO: 8 GB DDR3 shared bei 68,3 GB/s
Switch: 4GB ??? shared bei 25,6 GB/s
also wenn ich ehrlich sein soll... falls das stimmt sehe ich das größte problem beim arbeitsspeicher. falls die speicherbandbreite wirklich nur so niedrig ist, wird sich das sicher negativ auf die leistung auswirken.
hat das etwas mit dem stromverbrauch zu tun?
Oh mann, ich hab den Thread gerade erst entdeckt. Dabei ist das doch quasi MEIN Thread
Also vielleicht erstmal zum CPU-Vergleich. Wie andere schon angemerkt haben sagt die Taktrate inzwischen leider gar nix mehr über die Leistung, selbst nicht im Verbund mit Cache und Kernzahl. Früher mal konnte man noch einigermaßen die Leistungsfähigkeiten zwischen x86-Prozessoren anhand der Taktrate vergleichen, weil das die primäre Stellschraube war, anhand derer man die Leistung erhöht hat. Das ist inzwischen schon deshalb vorbei, weil man inzwischen an den physikalischen Grenzen des Siliziums kratzt. Ein Ausweg dazu ist, den Takt gleich zu halten, aber pro Takt mehr zu tun. Dazu gibt es einen Leistungswert, nämlich den IPC-Wert. Das sind die durchschnittlich verarbeiteten Befehle pro Takt (Instructions per Cycle). Um den zu erhöhen, hat man sich viele lustige Dinge einfallen lassen, wie zum Beispiel die Superskalarität oder Out-of-Order-Execution.
Üblicherweise führt ein Prozessor einen Befehl in mehreren Schritten aus, von denen jeder Schritt einen Takt dauert. Das sind z.B.: 1) Befehl laden 2) Befehl an Funktionseinheit (Addierer z.B.) senden, falls die Operanden schon vorliegen 3) Funktion durch Funktionseinheit ausführen 4) Ergebnis wieder zurück ins Register schreiben. Um das jetzt schneller hinzubekommen kann man z.B. mehrere Befehle gleichzeitig von unterschiedlichen Funktionseinheiten ausführen lassen (Superskalarität, das ist noch längst kein Multicore, das ist immer noch der gleiche Kern, der nur einen einzelnen Thread, also "Befehlsfaden" ausführt!), denn normalerweise hat so ein Prozessor ja eine ganze Batterie von Funktionseinheiten, von denen sich sonst quasi fast alle bis auf eine langweilen würden. Das parallele Abarbeiten führt dann dazu, dass ein Prozessorkern plötzlich mehrere Instruktionen pro Takt verarbeiten kann. Die üblichen Probleme bei Parallelität, nämlich dass manchmal ein Ergebnis benötigt wird um weiterzurechnen, das noch gar nicht vorhanden ist, muss der Prozessor dynamisch überwachen.
Eine weitere Technik ist die Out-of-Order-Execution und sie macht genau das, was der Name andeutet: Sie schert sich nur insoweit um die Reihenfolge der Instruktionen, wie sie nötig ist um das Ergebnis korrekt zu berechnen. Wenn aber z.B. eine unabhängige Instruktion auf Ausführung warten müsste, nur weil die vorhergehende vielleicht noch auf Daten aus dem RAM wartet, dann wäre das ineffizient, daher organisiert OoOE die Instruktionen in einem Befehlspuffer und wer seine Operanden vorliegen hat wird ausgeführt und darf den Puffer verlassen.
Die nächste Technik wäre Speculative Execution und ja, das heisst wirklich, dass ein Prozessor Code ausführt, bevor bekannt ist, ob er das Ergebnis überhaupt braucht, z.B. bei Wenn-Dann-Beziehungen.
All diese Techniken laufen zu allem Überfluss auch noch in einer sogenannten Pipeline, das heißt, dass man die oben aufgeführten Schritte staffelt. Wenn also ein Befehl gerade geladen wurde und bereits an die Funktionseinheiten übermittelt wurde, wird gleichzeitig schon der nächste Befehl geladen, denn die Einheit, die das Laden übernimmt ist ja gerade wieder frei geworden.
Das sind jetzt nur die Dinge, die mir so spontan einfallen, da gibt es noch viel mehr. Jedenfalls soll hier nur eines verdeutlicht werden: Die Leistungsfähigkeit eines Prozessors ist inzwischen nicht mehr am Datenblatt auszumachen. Man braucht Benchmarks oder Leute, die sich auskennen.
Ich habe schon mal vor einiger Zeit nach Benchmarks zu Jaguaren und A57-Kernen gesucht, aber das ist verdammt schwierig da was zu finden. Das liegt vielleicht schon ein bisschen daran, dass beide Kerne in völlig unterschiedlichen Umgebungen eingesetzt werden. Das bisschen was ich allerdings gefunden habe schien deutlich darauf hinzuweisen, dass die A57 tatsächlich mehr als nur konkurrenzfähig gegenüber Jaguar sind, sondern sogar schneller. Chibi hatte hier neulich schon mal einen Post des NeoGAF-Users
Thraktor verlinkt, der das gleiche sagt:
Even a cheap octo-core A53 solution for NX would put them within touching distance of Jaguar, and a combo of A53s and a few A57/A72/A73s could potentially push NX over the top (and we've heard rumours to indicate that this is indeed the case).
Zur Klärung: A53 und A57 sind beide Standard-Prozessorkerne von ARM mit
ARMv8-A-Befehlssatz (64bit). Der kleinere davon ist A53. Der ist langsamer (neudeutsch "energieeffizienter"), braucht aber auch viel weniger Fläche und noch weniger Strom als der dicke A57. Man kombiniert das gern in Smartphones (big.LITTLE-Konzept), damit man im Ruhezustand weniger Stromverbrauch hat und trotzdem Leistung wenn sie gebraucht wird. Hat auch den schrecklich praktischen Vorteil, dass der Marketingmensch gleich sagen kann, man hätte einen 8-Kerner im Telefon. Das stimmt zwar irgendwie auch, aber 4 davon sind halt lahm.
Jedenfalls besteht ein Tegra X2 aus vier A57 und zwei Denver 2, während ein X1 aus vier A57 und vier A53 besteht (eben big.LITTLE). Beides würde den Jaguaren mächtig Konkurrenz machen. Die Frage ist hier, was genau Nintendo sich aus dem bunten Tegra-Baukasten ausgesucht hat.
Meiner Ansicht nach deutet die Verschiebung auf März übrigens neben der Software möglicherweise auch auf den Produktionsprozess. Inzwischen ist nämlich der 16nm FinFET-Prozess verfügbar, und in dem wird der X2 gefertigt.
Zur GPU habe ich folgende Anmerkungen: Die TFlops beim Tegra gibt Nvidia in halber Präzision an. Nvidia macht das, weil die Tegras eben auch für maschinelles Lernen vermarktet werden sollen, und da sind weniger Präzise Zahlenformate (die dafür schneller rechnen) zulässig und auch sehr sinnvoll. Diesen Modus unterstützen AMDs Chips aber gar nicht. Wenn es also heißt, die XBox One leistet 1,31 TFlops Rohleistung, dann müssen wir das mit dem entsprechenden Wert des Tegra vergleichen, nämlich 0,5GFlops Single Precision beim X1 bzw. 0,75GFlops beim X2. Die Gute Nachricht ist: Der Half-Precision Modus kann durchaus auch für Grafik verwendet werden, nur vielleicht nicht gerade für Positionsdaten auf der Riesenkarte von Xenoblade 3. Das heißt "in Echt" wäre der Vergleichswert vom X2 höher, vielleicht so bei 850-900 GFlops, abhängig von der Engine. Und darüber hinaus geht Nvidia etwas geschickter mit seinen Operationen um, weshalb man sagt, dass Nvidia-Flops besser sind als AMD-Flops. Insgesamt kommt das Ding also bei Volltakt und Vollausbau des Prozessors tatsächlich in Sichtweite einer XBox One, auch GPU-seitig.
Aber eben nur unter den günstigsten denkbaren Bedingungen.
Jetzt noch zum Speicher: Ja, die Bandbreite ist nicht der Knaller. Das hat mit Sicherheit auch mit dem Stromverbrauch zu tun (das LP von LPDDR4, was das Teil mit höchster Wahrscheinlichkeit verwendet, heißt schließlich Low Power). Ich würde das aber nicht überbewerten. Pascal hat einige lustige neue Kompressionstechniken an Bord, die sehr dabei helfen, dieses Manko zu umgehen. Ich lass dazu mal diesen Link hier:
http://www.anandtech.com/show/10325/the ... n-review/8 Wir haben es bei Pascal mit einer viel moderneren GPU-Architektur zu tun als bei den beiden AMD-Twins.