@CD: Irgendwie ist dir das Kunststück gelungen, mit zu pauschalen bzw. nicht wirklich richtigen Aussagen unterm Strich eine richtige Aussage zu machen. Ich musste mehere mal drüber lesen, damit ich folgendes zerpflücken konnte.
CD schrieb:
Beim PC musst du durch die Treiber auf die Hardware zugreifen
Das ist eher Sache des OS Designs, weniger der PC Architektur geschuldet. Und auf der Konsole wirst du auch nicht frei jeden Systemaufruf tätigen können. Ein OS, oder technisch gesagt der erste ausgeführte Prozess, sitzt trotz dieser Nähe immer noch davor.
CD schrieb:
und für eine viel größere Anzahl möglicher Konfigurationen programmieren.
Können, aber nicht müssen.
CD schrieb:
Würdest du beispielsweise exklusiv für genau ein Mainboard, genau eine CPU und genau eine Grafikkarte programmieren, dann könntest du viel näher an der Hardware schreiben und auch mehr Leistung rausholen.
Das passt.
CD schrieb:
Wenn ne Konsole mit dutzenden Konfigs und Treibern daherkommen würde dann hättest du dort die selben Nachteile wie beim PC.
Nicht wirklich. Blos wegen mehr Treibern, verbrauche ich nicht
zwangsläufig mehr Tiks für einen Systemaufruf. Das ist bei PCs mit den gängigen OS eher ein layerbedingter Usus.
CD schrieb:
und da hast du beim programmieren einfach den Wahnsinns-Vorteil wenn du der GPU direkt sagen kannst "Shader-Einheit XY soll jetzt genau DAS berechnen"
Was beim PC nicht anders ist. Zumindest ist mir nichts anderes bekannt. Hast du einen (korrekten) Beispiel Quelltext, der sich auf gängiger PC Hardware nicht übersetzen lässt, aber wiederrum auf einer der aktuellen Konsolen?
CD schrieb:
und du weißt zudem genau wie lange die Berechnung dauern wird.
Hier hast du den eigentlichen Knackpunkt nun richtig erwischt. Spieleprogrammierung ist ein riesen Timingaufwand. Da hat man mit einer Schleife und irgendeinem naiven Timer nicht viel gewonnen. Und wenn man das Ganze granular feiner haben möchte, damit die richtigen Berechnungen zum günstigsten Zeitpunkt ausgeführt werden, dann hat die Vorhersagbarkeit auf einer Konsole ihre Stärken.
CD schrieb:
Aufm PC dagegen übergibst diese Aufgaben an den Treiber bzw. DirectX und hoffst halt drauf, dass die Grafikkartentreiber gescheit geschrieben wurden und es einigermaßen hinkriegen die Rechenaufgaben gleichmäßig auf die GPU zu verteilen.
Auf den Konsolen nicht arg viel anders. Die NES Zeiten sind vorbei. Da wird auch alles per OpenGL oder Direct3D in Kombi mit C/C++ und ggf. etwas Inline-Assembler gemacht. Soll aber nicht heißen, dass der letzte Absatz hier nicht gilt. Soll wieder heißen, dass der Programmtext für die Konsolenversion dennoch entsprechend anders ist und optimiert werden kann.
CD schrieb:
wenn du für den PC programmierst dann musst darauf vertrauen, dass eine Schnittstelle dir das alles möglichst effizient auf die Hardware übersetzt, während du bei der Konsole einfach direkt auf der Hardware programmieren kannst.
Das ist für mich eigentlich der zentrale Unsinn. Du weißt schon, dass so ein Compiler in mehreren Ebenen arbeitet? Von der Sprache, zu (Compiler)Tokens, zu Assember zu Opcode. Und den letzten Schritt kannst du unter Linux zB wunderbar mit nasm oder GAS machen. Wirklich maschinennah programmieren ist für mich, wenn du mit den Opcodes der Register rumspielst und Flags etc. selbst setzt, also zB. direkten Einfluss auf arithmetische Operationen vornimmst.
CD schrieb:
Andererseits, und da geb ich dir natürlich recht, wird man aus einem vergleichbaren PC wie du sagst nie die entsprechende Leistung der Konsole rausholen,
Da wäre ich mir eben nicht ganz so sicher. Gut, das wäre eher ein exotischer PC, wo man sich streiten könnte ob das noch PC oder schon eine Konsole ist, aber prinzipiell ist da kaum Grenze zur Spezialisierung gesetzt. Möchte daher nicht bestreiten, dass ein paar Verdrahtungen der Konsolenhardware für gewisse Instruktionen speziell angefertigt sind.
CD schrieb:
ich wollt nur sagen dass es sich dabei nicht um ein Hard- sondern ein Softwareproblem handelt.
So ein Fazit ziehe ich jetzt zumindest teilweise auch, wobei ich hier unterm Strich sage, dass es falsch ist zu behaupten, man könnte am PC nicht hardwarenah programmieren. Aber durch die homogene Hardware auf einer dem PC technisch nahezu identischen Platform, kannst du mit wesentlich weniger Eventualitäten rechnen und - der eigentliche, wie oben beschriebene "Knackpunkt" - wesentlich genauere Vorhersagen deiner Instruktionen treffen, egal ob per Hochsprache oder Assembler. Das ginge eben auch für die PC Platform wenn man, wie du oben schon geschrieben hast, nur für eine bestimmte Hardware Konstellation programmieren würde. Ist nur die Frage welchen Sinn sowas auf einer Allround Platform machen soll. Augenscheinlich eben keinen.
