Technische Komponenten für Konsolen
-
Warum haben Konsolen-CPUs (PS3, xBox) andere Architekturen und unterscheiden
sich von der PC Version ?
-
Was ist denn das für eine Frage? Weil du ganz andere Anforderungen hast! Insbesondere hat man eben nicht die Anforderung, i386-kompatibel sein zu müssen.
-
SeppJ schrieb:
Was ist denn das für eine Frage? Weil du ganz andere Anforderungen hast! Insbesondere hat man eben nicht die Anforderung, i386-kompatibel sein zu müssen.
Dass man ganz andere Anforderungen hat ist doch logisch, aber ich hätte
hier schon über die technischen Unterschiede (oder Links wo diese aufgelistet sind)
erfahren, warum architektur xy besser ist oder schlechter. Aber wenn man schon den Sinn der Frage in frage stellt,
werde ich wohl hier keine Antwort mehr bekommen...
trotzdem thx für den versuch
-
Wenn du eine andere Frage stellst, als du eigentlich meinst, dann brauchst du dich auch nicht über unpassende Antworten wundern.
-
weil die konsolen chips billiger sind, da sie, im gegensatz zu x86 cpus, nicht darauf ausgelegt sind jeden erdenklichen code, moege er noch so schlecht sein, schnell auszufuehren, sondern es die aufgabe der entwickler ist sauber zu programmieren.
beispiel:
virtual functions sind bei c++ sehr langsam:
x86 loeasung: intel baut eine spiezielle optimierung in die cpus die solche spruenge ueber tables wie normale function calls aussehen laesst.
konsolen loesung: benutz es nicht.beispiel 2:
atomics sind langsam, insbesondere wenn mehrere atomic variablen auf einer cacheline liegen.
x86 loesung: 3rd level cache der shared ist zwischen den cores, damit selbst das schlechteste was man an code abliefern kann noch mit <50 cycles wegkommt.
konsolen loesung: align atomics auf cachelines, da du sonst pro zugrif mit bis zu 600cycles rechnen darfstbeispiel 3:
unaligned reads sind langsam, trifft auf alle datentypen zu die nicht auf einer natuerlichen address liegen, insbesondere bei 128bit SIMD typen.
x86 loesung: intel optimiert die unaligned read operation, wenn die daten aligned sind, hast du nun die performance wie bei dem aligned-load operator, liegen sie unaligned, ist es nun dennoch ziemlich schnell, dafuer sorgt eine neue shuffle einheit.
konsolen loesung: du bekommst 1. einen interrupt wenn du das machst, 2. die cpu ignoriert die untersten x-bit bei addressen sodass immer aligned gelesen wird, 3. der compiler emuliert unaligned reads, indem er mittels langsammer memcpy aufrufe die bytes auf eine aligned addresse kopiert und dann mit aligned operationen weiter arbeitet.hier z.B. ein paar benchmarks fuer nicht ganz so schlechten c++ code
http://forum.beyond3d.com/showthread.php?t=36058du kannst auch benchmarks raussuchen, wo z.b. ein intel atom single core mit arm dual/quad cores abrechnet, und dabei ist die atom cpu bei weitem nicht so stark wie die desktop cpus. auf der anderen seite gibt es software 3d engines die auf GBAs laufen deren arm V7 mit nur 16MHz arbeitet.
aber wir sind an einer saturierung angekommen,
1. wird niemand mehr eine GPU aus dem handgelenk schuetteln die mit denen auf dem desktopmarkt ansatzweise mithalten kann -> alle konsolen werden ne art desktop GPU haben
2. sind die leute mit der graphik zufrieden, es stoert niemanden wirklich wie es hier und dort flimmert und sie begehren nicht wirklich photorealistischerere graphik, weil spiele wie uncharted 3 nunmal schon recht gut aussehen, das meiste ist arbeit der graphiker. von daher kommt es auf das entwicklungstempo an, nicht auf das ausquetschen der letzten performance particle aus jedem prozessor -> konsolen entwicklung naeherst sich dem niveau von desktop spielen und daher wird man wohl auch wieder desktop CPUs als gute kandidaten ansehen (meine persoenliche meinung).
