Wie viel Leistung verbraucht das Betriebssystem vs. direkt auf Hardware? [Archiv]

Gissmo

2006-04-23, 12:03:29

Unsere Spielekonsolen erreichen ja ihr großen Vorteil gegenüber dem PC meist durch sehr Hardwarenahe Programmierung und die Tatsache, dass es keine verschiedene Hardware gibt.

Nun dürft ihr mal wild spekulieren, wieviel Leistung einerseits dadurch verloren geht, dass man für "allgemeine" Schnittstellen programmiert, als direkt für eine spezielle Hardware und wieviel Leistung, das quasi immer mit laufende Windows für sich selbst und die Verwaltung aufbraucht (müsste ja auch einen gewissen Rechenaufwand bedeuten).

Welche Auswirkung hätten wir also, wenn wir einen immer gleichen PC benutzen und z.B. ein Spiel, ein Bildbearbeitungsprogramm und einen Video Encoder oder vllt den Seti Client einmal (nehmen wir uns einfahc die Zeit ;-)) perfekt in Assembler auf die Hardware zugeschnitten und ein ander mal, wie derzeit üblich für ein Betriebssystem in einer höheren Sprache?

Laufen der Seti Client, unser Video Encoder, das Spiel sowie das Bildbearbeitungsprogramm merklich schneller oder flüssiger?

Wishnu

2006-04-23, 12:43:07

Welche Auswirkung hätten wir also, wenn wir einen immer gleichen PC benutzen und z.B. ein Spiel, ein Bildbearbeitungsprogramm und einen Video Encoder oder vllt den Seti Client einmal (nehmen wir uns einfahc die Zeit ;-)) perfekt in Assembler auf die Hardware zugeschnitten und ein ander mal, wie derzeit üblich für ein Betriebssystem in einer höheren Sprache?

In irgendeiner c't hatten sie ähnliches einmal mit dem c't-Apfelmännchen getestet.

Der handoptmierte Assembler-Code war glaube ich um den Faktor 13 schneller (habe damals auch nicht schlecht gestaunt).

Coda

2006-04-23, 13:08:24

Wer sagt denn bitte dass auf Konsolen in Assembler programmiert wird? :crazy2:

Tyson

2006-04-23, 13:44:33

Niemand, aber auf Konsolen ist nunmal die Hardware bekannt und man muss keine "allgemeine" API verwedenen, die auf zig Hardware funktioniert.

Gruß Tyson

Controller Khan

2006-04-23, 14:04:25

In irgendeiner c't hatten sie ähnliches einmal mit dem c't-Apfelmännchen getestet.

Der handoptmierte Assembler-Code war glaube ich um den Faktor 13 schneller (habe damals auch nicht schlecht gestaunt).

c't-Apfelmännchen ist ein absolutes Extrem Beispiel und nicht verallgemeinbar.

Es nutzt z.B 3D-Now Befehle, die nur der Athlon kennt z.B PSWAPD

Welcher Mensch unterscheidet, wenn er überhaupt auf 3D-Now optimiert auch noch zwischen Athlon und K6-2/3 ?

beos

2006-04-23, 14:22:33

Welche Auswirkung hätten wir also, wenn wir einen immer gleichen PC benutzen und z.B. ein Spiel, ein Bildbearbeitungsprogramm und einen Video Encoder oder vllt den Seti Client einmal (nehmen wir uns einfahc die Zeit ;-)) perfekt in Assembler auf die Hardware zugeschnitten und ein ander mal, wie derzeit üblich für ein Betriebssystem in einer höheren Sprache?

Auch wenn Du in Assembler programmierst brauchst Du ein Betriebssystem...
das dann den vom Assembler erzeugten Maschinencode abarbeitet....

Man könnte aber jetzt programm - oder software - auch direkt in hardware "giessen"......DAS wäre dann ein echter performancesprung

AnPapaSeiBua

2006-04-23, 15:21:34

Auch wenn Du in Assembler programmierst brauchst Du ein Betriebssystem...
das dann den vom Assembler erzeugten Maschinencode abarbeitet....

Ähm...
Den Maschinencode arbeitet immer noch die CPU ab und nicht das Betriebssystem. Wer würde denn den Maschinencode des Betriebssystems ausführen? Das Betriebssystem selbst? Und wer führt dann...

GloomY

2006-04-23, 15:34:19

[...] und wieviel Leistung, das quasi immer mit laufende Windows für sich selbst und die Verwaltung aufbraucht (müsste ja auch einen gewissen Rechenaufwand bedeuten).Jeder Task-Switch kostet natürlich etwas Performance. Das Sichern und Wiederherstellen des Programmstatuses und das Ausführen des Schedulers im Kernel sind dabei die direkt anfallenden Kosten durch Verzögerung. Dazu kommen noch die indirekt anfallenden Kosten indem ein neuer Task durch den Kontextwechsel meistens erstmal eine Reihe von Cache- und TLB-Misses produziert, bis diese beiden Zwischenspeicher "warm" sind.

Ich erinnere mich daran, dass im Tutorium zur Vorlesung über Systemarchitektur an meiner Uni der Punkt angesprochen wurde, wie lange denn nun eine Zeitscheibe dauern sollte - sprich: Wie oft die direkten Kosten auftreten. In Abhängigkeit der Länge dieser Verzögerung sollte man die Länge der Zeitscheibe so wählen, dass nicht mehr als 5% Overhead ensteht. Zusammen mit den indirekten Kosten würde man dann wohl gut im Bereich von unter 10% bleiben.

edit: Bezüglich Assembler vs. Compiler gibt es auch einen Thread im Programmierforum: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=291648

beos

2006-04-23, 16:05:33

Ähm...
Den Maschinencode arbeitet immer noch die CPU ab und nicht das Betriebssystem. Wer würde denn den Maschinencode des Betriebssystems ausführen? Das Betriebssystem selbst? Und wer führt dann...

vielleicht habe ich das falsch formuliert..

Wenn Du mit einem Assembler programmierst benutzt Du immer betriebsystem spez Aufrufe....ohne das os, das diese unterstützt läuft dein programm nicht...

sonst könntest du ja ein für ein dos assembler geschreibenes programm unter linux laufen lassen....

du müßtest also ein programm schreiben, dass z.b. das laden seines eigenen codes erledigt, bevor es in den speicher geladen ist ....

(del)

2006-04-23, 16:28:17

Niemand, aber auf Konsolen ist nunmal die Hardware bekannt und man muss keine "allgemeine" API verwedenen, die auf zig Hardware funktioniert
Welche "zig Hardware"? Es wird für OpenGL/D3D programmiert. An sich anschliessend auf NV/ATI getestet und fertig. Um den Rest kümmert sich der Grakatreiber.

Eine PS2 hat sehr wohl eine allgemeine API ;) Genauso wie sie ein OS hat. Imho gibt es nur sehr wenige - ich sage nicht: keine - Spiele die direkt die Hardware hacken. So wie das zB. in der letzten Phase des C64/Amiga der Fall war.

Demirug

2006-04-23, 16:57:54

Welche "zig Hardware"? Es wird für OpenGL/D3D programmiert. An sich anschliessend auf NV/ATI getestet und fertig. Um den Rest kümmert sich der Grakatreiber.

Das funktioniert aber nur wenn man sich auf den kleinsten gemeinsamen nennern beschränkt.

OpenGL und D3D9 definieren zwar wie Features genutzt werden aber sie sichern nicht zu das sie vorhanden sind.

RoKo

2006-04-23, 18:01:02

So wie das zB. in der letzten Phase des C64/Amiga der Fall war.
War dort von Anfang an so.
du müßtest also ein programm schreiben, dass z.b. das laden seines eigenen codes erledigt, bevor es in den speicher geladen ist ....
Nö, das BIOS (bzw. das Äquivalent auf einem anderen System) läd zu Beginn einen Batzen Code von einer bestimmten Stelle eines bestimmten Datenträgers. So startet ein Betriebssystem und so startet klassischerweise ein Konsolenspiel. Inwieweit sich das jetzt bei den aktuellen Konsolen in Richtung Betriebssystem geändert hat, weiß ich nicht, aber erst bei der X360 habe ich wirklich etwas davon bemerkt. Die "allgemeine API" der PS2 ist meines Wissens nichts anderes als ganz normale, optionale Libraries, die von Sony bereitgestellt werden und die man mit auf seine Spiele-DVD packt. Eine richtige Hardwaredoku zum Grafikchip mit den ganzen Registern und tralala gibt's da auf jedem Fall auch noch.

beos

2006-04-23, 20:06:56

[QUOTE=RoKo]War dort von Anfang an so.

Nö, das BIOS (bzw. das Äquivalent auf einem anderen System) läd zu Beginn einen Batzen Code von einer bestimmten Stelle eines bestimmten Datenträgers. So startet ein Betriebssystem und so startet klassischerweise ein Konsolenspiel. [ /QUOTE]

Das ist teils richtig....das Bios lädt ein festgelegte Adresse als ausführbaren Code...

Trotzdem müßte ein angenommenes Programm den größten Teil seines Codes selbst nachladen (wie dies auch Betriebssysteme tun) - da das Bios nur wenige Byte lädt....

Übrigens haben alle modernen Konsolen auch ein OS...

RoKo

2006-04-24, 00:59:12

Trotzdem müßte ein angenommenes Programm den größten Teil seines Codes selbst nachladen (wie dies auch Betriebssysteme tun) - da das Bios nur wenige Byte lädt....
Jup, aber das ist dann ja kein Problem, zumal die Konsolenhersteller sicher Libraries dafür zur Verfügung stellen und die Firmware ohnehin gleich mehr reinläd als ein PC-BIOS.
Übrigens haben alle modernen Konsolen auch ein OS...
Im Sinne von einem Programm, das bei jedem Spiel noch im Hintergrund läuft? Wo kann ich was darüber lesen?

Gast

2006-04-24, 16:39:13

Auf Konsolen wird nicht viel hardwarenaeher programmiert als auf dem PC.
Abstraktion der Hardware dient dazu, diese ueberhaupt praktisch nutzbar zu machen.

Wenn du darauf bestehen wuerdest, dein Lieblingsspiel ausschliesslich in Assembler, ohne Betriebssystemhilfe programmiert zu bekommen, wuerdest du genau 0 FPS bekommen.
Denn keine Entwicklerfirma der Welt wuerde dies machen koennen.

Das ist genauso wie die Frage der Leihen ob das Spiel nicht schneller waehre, wenn es in C anstatt C++ geschrieben wird.
Pustekuchen ... falsche Fragestellung.
Das ist wie die Frage an nen Baumeister, ob er dein Haus aus einem Felsblock und Streichhoelzern bauen koennte.

stickedy

2006-04-25, 09:39:07

Im Sinne von einem Programm, das bei jedem Spiel noch im Hintergrund läuft? Wo kann ich was darüber lesen?
Ja. Bei der Dreamcast kommt Windows CE zum Einsatz und bei der XBOX afaik ne modifizierte Version von Windows XP. Bei der XBOX wird auch eine modifizierte Version von DirectX als API genutzt.

Aber das ist eigentlich ne Geisterdiskussion denn selbst ein simpler CD-Player hat im Prinzip ein Betriebssystem, nur halt keine GUI. Und ich glaub, das ist das was du eigentlich meinst. Weil ein Elektronik-Gerät ohne Betriebssystem ist nicht möglich.

Avalox@Gast

2006-04-25, 13:35:56

Wenn man das Betriebssystem als universelles Softwaresystem zur Verwaltung der Hardware und einigen Grundlegenden System Programmen zur dessen Verwaltung sieht. Dann gibt es sehr wohl Computer ohne Betriebssystem. Dann haben Computer auch mal in der Vergangenheit gänzlich ohne Betriebssystem angefangen. Der Luxus ein Betriebssystem zu benutzen wurde erst später "erfunden".

Ich denke die Frage des Topics geht doch vielmehr in die Richtung, in welcher Hinsicht die Abstraktionsebenene heutiger Betriebssysteme Performance fressen.

RoKo

2006-04-25, 14:22:22

Ja. Bei der Dreamcast kommt Windows CE zum Einsatz
Das lief aber nur bei sehr wenigen Spielen mit (Sega Rally 2).
und bei der XBOX afaik ne modifizierte Version von Windows XP. Bei der XBOX wird auch eine modifizierte Version von DirectX als API genutzt.
Aber läuft dieses OS noch, wenn das Spiel gestartet wurde?
Aber das ist eigentlich ne Geisterdiskussion denn selbst ein simpler CD-Player hat im Prinzip ein Betriebssystem, nur halt keine GUI. Und ich glaub, das ist das was du eigentlich meinst. Weil ein Elektronik-Gerät ohne Betriebssystem ist nicht möglich.
Als Betriebssystem verstehe ich etwas, das im Ring 0 (oder wie auch immer man das beim jeweiligen Prozessor nennt) läuft und andere Anwendungen ausführt und diesen Dienste zur Verfügung stellt. Aber auf einer Konsole ist das eben unnötig, da eh immer nur genau eine Anwendung läuft, dann kann man den allgemein benötigten Kram auch einfach als Library mitgeben - außer man bietet auch während des Spiels zusätzliche Funktionalität an, die ständig im Hintergrund läuft (Nachrichten empfangen u.s.w.), das kenne ich aber bisher nur von der X360. Mit einer GUI hat das alles überhaupt nix zu tun.

beos

2006-04-25, 14:32:48

Das lief aber nur bei sehr wenigen Spielen mit (Sega Rally 2).

Aber läuft dieses OS noch, wenn das Spiel gestartet wurde?

Als Betriebssystem verstehe ich etwas, das im Ring 0 (oder wie auch immer man das beim jeweiligen Prozessor nennt) läuft und andere Anwendungen ausführt und diesen Dienste zur Verfügung stellt. Aber auf einer Konsole ist das eben unnötig, da eh immer nur genau eine Anwendung läuft, dann kann man den allgemein benötigten Kram auch einfach als Library mitgeben - außer man bietet auch während des Spiels zusätzliche Funktionalität an, die ständig im Hintergrund läuft (Nachrichten empfangen u.s.w.), das kenne ich aber bisher nur von der X360. Mit einer GUI hat das alles überhaupt nix zu tun.

Wenn wir uns ganz kurz nochmal ins Gedächnis rufen, was ein Betriebsystemkern so macht - wird klar, dass es auch laufen muss - wenn das Spiel gestartet wurde:

- E/A Funktionen
- Virtueller Speicher
- Paging
- Semaphoren zur Synchonisation von Prozessen
- Prozessverwaltung
usw...

RoKo

2006-04-25, 14:45:01

Gast

2006-04-25, 14:54:16

Zu diesem Thema fällt mir gerade ein, dass man zumindest auf der PS2 nach vielen Spielen neu booten muss, da man nicht mehr in das Betriebssystem zurück kommt. Auch bei HeftCDs erscheint häufig der Hinweis "Bitte starten Sie nach dem Spielen der Demo Ihre Konsole neu". Das würde doch darauf hinweisen, dass selbst so ein simples Betriebssystem, wie das der PS2 mehr oder weniger vom Spiel zur Laufzeit entfernt oder zumindest nicht gebraucht wird.

Die einzige Konsole, die ich kenne, bei der das nicht so ist, ist die XBox 360. Da kann man ja jederzeit während eines Spiels zurück ins Betriebssystem.

beos

2006-04-25, 15:17:53

- E/A Funktionen

Kann man leicht per Library erledigen.

- Virtueller Speicher
- Paging

Das will man auf einer Konsole gar nicht haben.

- Semaphoren zur Synchonisation von Prozessen
- Prozessverwaltung

Nur auf Multi-CPU/Core-Systemen interessant. Könnte man aber auch genau so gut selber machen.

- Semaphoren + Prozessverwaltung brauchst Du immer
- Virtueller Speicher + Paging auch
- über die E/A funktionen könnte man reden ...

beos

2006-04-25, 15:20:55

Welche Auswirkung hätten wir also, wenn wir einen immer gleichen PC benutzen und z.B. ein Spiel, ein Bildbearbeitungsprogramm und einen Video Encoder oder vllt den Seti Client einmal (nehmen wir uns einfahc die Zeit ;-)) perfekt in Assembler auf die Hardware zugeschnitten und ein ander mal, wie derzeit üblich für ein Betriebssystem in einer höheren Sprache?

Laufen der Seti Client, unser Video Encoder, das Spiel sowie das Bildbearbeitungsprogramm merklich schneller oder flüssiger?

Dieser Fred und Gissmo's Frage bezog sich klar auf einen PC - warum bringt ihr immer die Konsolen ins Spiel???

Gast

2006-04-25, 15:31:54

Dieser Fred und Gissmo's Frage bezog sich klar auf einen PC - warum bringt ihr immer die Konsolen ins Spiel???Nun, weil hier die Aussage aufgetaucht ist, auch Konsolen hätten ein Betriebssystem, welches immer im Hintergrund laufen würde. Der Threadstarter sagt aber:Unsere Spielekonsolen erreichen ja ihr großen Vorteil gegenüber dem PC meist durch sehr Hardwarenahe Programmierung und die Tatsache, dass es keine verschiedene Hardware gibt. Wenn nun aber Konsolen auch ein ständig im Hintergrund agierendes Betriebssystem hätten, dann wäre die Vermutung des Threadstarters, dass das Betriebssystem auf dem PC für Leistungsverlust, im Gegensatz zur Konsole, verantwortlich wäre, doch unsinnig.

Coda

2006-04-25, 15:32:47

Das "Betriebssystem" bei einer Konsole ist eher eine Library. Es findet ja keinerlei Task-Switching o.Ä. statt.

RoKo

2006-04-25, 15:37:56

- Semaphoren + Prozessverwaltung brauchst Du immer

Wieso weshalb warum?

- Virtueller Speicher + Paging auch

Ich kenne sogar richtige Betriebssysteme, die das nicht haben (AmigaOS zum Beispiel). Bei einem Konsolenspiel wäre es sogar äußerst hinderlich.

beos

2006-04-25, 15:39:06

Das "Betriebssystem" bei einer Konsole ist eher eine Library. Es findet ja keinerlei Task-Switching o.Ä. statt.

Ohne mehrere Tasks oder Threads stelle ich mir die Programmierung der verschiedenen Custum Chips der aktuellen + vergangenen Konsolen und die mehreren CPU's kommenden Konsolen aber ganz schön schwer vor :confused:

beos

2006-04-25, 15:44:48

- Semaphoren + Prozessverwaltung brauchst Du immer

Wieso weshalb warum?

Virtueller Speicher + Paging auch

Ich kenne sogar richtige Betriebssysteme, die das nicht haben (AmigaOS zum Beispiel). Bei einem Konsolenspiel wäre es sogar äußerst hinderlich.

Du darfst Virtueller Speicher nicht mit dem bekannten Swapfile von Windows oder der Swappartition unter Unix verwechseln...

Programme rechnen immer mit virtuellen Adressen...(zumindest auf allen CPU's die eine MMU besitzen)

Semaphoren + Prozessverwaltung brauchst du immer, wenn nur ein Betriebsmittel - aber mehrere Betriebsbeansprucher da sind - um die Zugriffe auf das BM zu syncronisieren und zu verwalten..

Coda

2006-04-25, 15:50:42

RoKo

2006-04-25, 16:48:25

Ohne mehrere Tasks oder Threads stelle ich mir die Programmierung der verschiedenen Custum Chips der aktuellen + vergangenen Konsolen und die mehreren CPU's kommenden Konsolen aber ganz schön schwer vor :confused:
Der vergangenen Konsolen: Ich nicht. Ein Spiel funktioniert üblicherweise mittels einer Art kooperativem Multithreading - wobei man auf Konsolen natürlich auch eigene Interruptroutinen schreibt, dafür sind aber auch keine Threads notwendig.

Der kommenden Konsolen: Ich auch. Ginge aber natürlich auch. Wie auf dem Saturn, wo glaube fast keiner die zweite CPU überhaupt genutzt hat ;)

Programme rechnen immer mit virtuellen Adressen...(zumindest auf allen CPU's die eine MMU besitzen)
Wenn sie unter einem Betriebssystem im Usermode laufen, das die MMU entsprechend eingestellt hat. Das bringt einem aber auf einer Konsole nix.
Und wie Du richtig anmerkst, gibt es auch CPUs ohne MMU. Auf Konsolen ist mir dadurch kein Unterschied aufgefallen.

Semaphoren + Prozessverwaltung brauchst du immer, wenn nur ein Betriebsmittel - aber mehrere Betriebsbeansprucher da sind - um die Zugriffe auf das BM zu syncronisieren und zu verwalten..
Das ist aber doch der Unterschied, auf einer Konsole läuft immer nur ein einziges Spiel, deswegen kann selbiges alles selber regeln.

Gissmo

2006-04-25, 17:19:28

HOT

2006-04-25, 17:24:41

Als wenn Windows soviel Performance fressen würde. So ein Schwachsinn. Das was beim Spielen wirklich Performance frisst sind unoptimierte Bibliotheken und eine vielzahl an aufeinander aufbauenden APIs. Die Performance von DirectX hat einen Einfluss auf die Leistungsfähigkeit eines Spiels, das OS erledigt nur rudimentäre Aufgaben die auf jedem Computer (eine Konsole ist letztendlich nichts anderes) erledigt werden muss. Sehen kann man das übrigens sehr gut, wenn man die Leistung mit Win98 mit heutigem XP oder später Vista vergleicht, es gibt keinen Unterschied in der Performance beim Spielen, ganz einfach weil nur Aufgaben erledigt werden, die immer erledigt werden müssen.
Windows hat einen höheren Speicherverbrauch als eine Konsole, weil hier mehr (allerdings beim Spielen inaktive) Prozesse im Speicher gehalten werden.

beos

2006-04-25, 17:36:30

Der vergangenen Konsolen: Ich nicht. Ein Spiel funktioniert üblicherweise mittels einer Art kooperativem Multithreading - wobei man auf Konsolen natürlich auch eigene Interruptroutinen schreibt, dafür sind aber auch keine Threads notwendig.

Der kommenden Konsolen: Ich auch. Ginge aber natürlich auch. Wie auf dem Saturn, wo glaube fast keiner die zweite CPU überhaupt genutzt hat ;)

Wenn sie unter einem Betriebssystem im Usermode laufen, das die MMU entsprechend eingestellt hat. Das bringt einem aber auf einer Konsole nix.
Und wie Du richtig anmerkst, gibt es auch CPUs ohne MMU. Auf Konsolen ist mir dadurch kein Unterschied aufgefallen.

Das ist aber doch der Unterschied, auf einer Konsole läuft immer nur ein einziges Spiel, deswegen kann selbiges alles selber regeln.

Du vergißt dass es ja z.B. schon für das SNES Customchips gab (Starfox - 3D Coprozessor im Spielmodul)

Es wäre sehr uneffizient, wenn ein Teil des Programmcodes auf die Verarbeitung des andern warten müßte.

Auch die PS1 hat einen Vektorcoprozessor der parallel arbeitet und nicht auf die anderen Chips warten muss.

Die MMU wird übrignes NIE im Usermode verwaltet.....zumindest nicht bei den OS's die ich kenne....(aber man lernt ja nie aus)

Ergo hast Du auch bei Konsolen und einem Spiel mehrere Programmthreads oder Prozesse, die z.b. per Semaphore syncronisiert werden muessen...(allein um die Einhaltung der Ergebnissreihenfolgen zu gewährleisten)

HOT

2006-04-25, 17:43:14

Zu meinem ersten Post:

Dort hab ich mehrere Fragen durcheinander geworfen.

Frage Nummer eins: Wieviel Leistung geht uns durch allgemeines Programmieren/Abstraktion verloren.

Beispiel: Wir schreiben uns Betriebssystem/Programm so, dass es auf allen möglichen Rechnern lauffähig ist gegenüber z.B. nur auf eine CPU, ein Mainboard, eine Grafikkarte angepasst.

Das kommt darauf an, wieviele APIs dazwischenliegen und wie gut die Bibliotheken optimiert sind, die auch benutzt werden. Bei DirectX Bilbiotheken (welche ja da ist um den grossteil der Betriebssystemeigenen Langsamkeiten wie z.B. die GUI zu umgehen) kannst du dir sicher sein, dass diese ähnlich gut optimiert sind wie Bibliotheken die auf Konsolen genutzt werden. APIs, die das OS anbietet aber nicht genutzt werden, fressen auch keine Performance.

Frage Nummer zwei: Wieviel Leistung "opfern" wir dadurch, dass wir ein Betriebsysytem "neben" unseren Programmen am laufen haben? (meine Damit Linux/Windows o.ä kein Bios ^^)

Beispiel: Ein Spiel oder Programm hat nur dabei, was es für sich zum laufen braucht und kann ohne weiteres Betriebsysystem direkt nach dem Bios geladen werden.

Zur Konsole, die hab ich als Beispiel genommen, da es bei Konsolen wohl kein "stark ausgebautes" Betriebsystem (vergleichbar mit einem Windows) gibt sondern (so stell ich es mir zmd vor) nur grundlegnde Funktionen zum Laden des Spiels bereitsgestellt werden.
Desweiteren Konsolenspiele eben nur auf einer zuvor festgelegten Hardware laufen müssen und somit besser angepasst werden können.
Der Großteil der Spiele wird dort sicherlich wie üblich in den höheren Programmiersprachen geschrieben, ich meine jedoch mal in einem Bericht über irgend ein PS2 Spiel gelesen zu haben, dass besonders Kritische Teile der Engine teils in Assembler verfasst wurden und dabei zusätzlich optimiert, um also ein Maximum an Leistung aus der Hardware zu holen.

Konsolen nutzen ähnliche Bibliotheken wie Windows mit DirectX anbietet. Die XBox hat z.B. einen Windows Kernel, der fast ausschliesslich mit DirectX arbeitet an Bord. Die PS2 und GC haben etwas ähnliches, aber ohne geht es nunmal einfach nicht. Der Vorteil an diesen angepassten OS Versionen ist lediglich, dass sie sehr wenig RAM benötigen und sehr klein sind, sodass sie in Flash Speicher passen. Die Funktionen, die erledigt werden müssen (Speicherverwaltung, Threading, Laufwerkszugriffe usw.) unterscheiden sich nicht vom PC. Windows wird an diesen Stellen nicht weniger optimiert sein. Wenn Assembler genutzt wird, dann höchstens, weil Konsolen nur eine sehr beschränkte Menge an RAM zur Verfügung stellen und man hier von Hand Speicher sparen kann (war vor allem bei der PS2 oftmals nötig). Spielen werden nur deshalb mehr auf Konsolen optimiert, weil eine Konsole nicht aufrüstbar gehalten ist und man zum EOL der Konsole hin immer komplexere Spiele auf schlechter Hardware zum laufen bringen muss.

Zusammengefasst also, wieviel Leistung geht uns verloren, dadurch, dass wir für Schnittstellen (zb DX 9/Treiber) und nicht für de spezielle Grafikarte Programmieren.. und wieviel Rechenleistung benötigt z.B. Windows XP für die Verwaltung.

Im Nachhinein kam mir noch die Frage (geht auch in Richtung Abstraktion und wurde teils bereits angesprochen), wie gut sind Compiler.. wieviel besser könnte man sein (wir nehmen uns einfahc mal die Zeit ;-)), wenn man ganze Programm in perfektem Assembler schreiben könnte?

Assembler lohnt sich nur an sehr kritischen Stellen, da Assemblerprogrammierung schlichtweg Zeit benötigt. Es wird fast nirgendwo mehr eingesetzt, nur dann, wenn sich der Aufwand überhaupt lohnt und Speichermangel vorherrscht.

Weitere Beispiele noch...
.. wir haben ein DOS Programm.. einmal läuft es direkt in DOS, das andere Mal wird es aus Windows heraus ausgeführt.. wieviel ist es langsamer?

garnicht. Denn vom DOS Programm wird lediglich der Befehlsinterpreter angesprochen, dessen Leistungsverbrauch ändert sich nicht. Im Gegenteil, vielleicht sind neuere Versionen sogar optimierter. Andere Prozesse sind nicht aktiv, wenn du nur das DOS Programm benutzt und andere APIs werden nicht angesprochen.

.. oder ein zweites Betriebssystem, dass in einer Virtual Machine läuft und dabei, wiel eben nicht auf Hardware/noch ein Betriebssystem dazwischen? teils deutlich langsamer läuft

Eine VMWare emuliert und ist deshalb langsamer. Das hat nichts mit unserem Thema zu tun.

.. und Windows XP, welches um halbwegs flott bedienbar zu sein einen sagen wir Pentium 200Mhz braucht (natürlich nur Modellhaft) also von meiner jetzigen CPU die "Leistung" von 100Mhz für sich selbst benötigt (ja, die Rechnung hinkt ein bisschen :P )

XP benötigt vor allem Speicher, welchen du auf dem P200 sicherlich nicht in ausreichender Menge hast. Ist genügend Speicher vorhanden, läuft XP nicht viel langsamer als ein Windows98.

beos

2006-04-25, 17:47:54

Zusammengefasst also, wieviel Leistung geht uns verloren, dadurch, dass wir für Schnittstellen (zb DX 9/Treiber) und nicht für de spezielle Grafikarte Programmieren.. und wieviel Rechenleistung benötigt z.B. Windows XP für die Verwaltung.

Im Nachhinein kam mir noch die Frage (geht auch in Richtung Abstraktion und wurde teils bereits angesprochen), wie gut sind Compiler.. wieviel besser könnte man sein (wir nehmen uns einfahc mal die Zeit ;-)), wenn man ganze Programm in perfektem Assembler schreiben könnte?

Sicherlich geht durch Abstraktion der Hardware (wie z.b. DX) Leistung verloren.
Man muss nur in die Vergangenheit schauen, als es Spiele für die Voodoo Karte unter Dos unter Nutzung der Glide Schnittstelle gab und für Windows.

Die Dos Versionen liefen alle schneller (kann mich noch gut an Mechwarrior 2 errinnern)

Die andere Frage und zugleich feststellung ist doch - wenn wir noch heute alles in assembler schreiben müßten...würde es nie so komplexe software geben....ergo kann man nur kleine softwareprojekte vergleichen und dazu zählt die heutige nun mal gar nicht.

RoKo

2006-04-25, 23:19:01

Du vergißt dass es ja z.B. schon für das SNES Customchips gab (Starfox - 3D Coprozessor im Spielmodul)
Du meinst Zusatz-CPUs. Klar weiß ich das, hab doch sogar den Saturn erwähnt.
Es wäre sehr uneffizient, wenn ein Teil des Programmcodes auf die Verarbeitung des andern warten müßte.
Für die paar SNES-Spiele mit Coprozessor im Modul (neben Super-FX1 und 2 gab es noch was von Capcom) hat man deswegen trotzdem kein eigenes OS geschrieben. Einfach die zweite CPU arbeiten lassen und wenn sie mit irgendwas fertig ist hat sie an Speicheradresse X ein Y geschrieben, was dann soundsooft gepollt wurde. Dementsprechend monoton hat man die Zusatz-CPUs auch betrieben, damit das einfach klappt. Für StarFox war der Super-FX ja quasi der Grafikchip.
Welches Betriebssystem kann einem eigentlich beim Umgang mit zwei ganz verschiedenen CPUs helfen?
Auch die PS1 hat einen Vektorcoprozessor der parallel arbeitet und nicht auf die anderen Chips warten muss.
Und die PS2 hat sogar zwei Vektorcoprozessoren. Das funktioniert aber mehr so, wie man heutzutage die Grafikchips programmiert oder die SPUs im Cell.
Auch so ein Spezialfall, in dem einem eh kein OS aushelfen kann. Die Dinger haben ja auch ganz eigenen Speicher, eigenen Minibefehlssatz und tralala.

Die MMU wird übrignes NIE im Usermode verwaltet.....zumindest nicht bei den OS's die ich kenne....(aber man lernt ja nie aus)
Richtig. Bei Konsolen gibt es aber keinen Grund, überhaupt in den UserMode zu wechseln.

Ergo hast Du auch bei Konsolen und einem Spiel mehrere Programmthreads oder Prozesse, die z.b. per Semaphore syncronisiert werden muessen...(allein um die Einhaltung der Ergebnissreihenfolgen zu gewährleisten)
Genausoviele Prozesse wie CPUs (oder weniger). Und wenn das immer noch > 1 war (selten), hat man das trotzdem selber ohne OS geregelt. Bis zur X360 wohl.

beos

2006-04-26, 00:37:33

Das Problem - aus meiner Sicht - besteht darin dass ich (wie sieht es mit Dir aus) noch nie ein Konsole programmiert habe....

Deswegen kann ich nur spekulieren wie es dort funkioniert.

Aber wenn man sich so umsieht - steckt in vielen Konsolen eine MIPS PU als CPU drin.

Diese Cpus habe ich mit C code und ein klein bißchen mit Assembler gefüttert.
(Kernelmodule für Embedded Systeme)

Als Entwickerkits für die Konsolen gibt er sehr häufig C Cross Compiler - mit derer Hilfe man seine Soft programmieren kann.

Alle benutzen aber Betriebsystembibliotheken....

Das bedeutet - aus meiner Sicht - dass diese Konsolen wohl ein Betriebsystem besitzten müssen.

Avalox@Gast

2006-04-26, 18:10:40

Eine der erste Abstraktionsebenen findet sich im Prozessor selbst.
Microcode ist eine Abstraktionsebene. Es wäre sicherlich interessant mal alle Abstraktionsebenen zu zählen, bis letztendlich das geschieht, was der Benutzer möchte.

Schon der einfache Weg Spiel -> Spieleengine -> Middleware ->API -> OS-> Geräte Treiber -> (sicherlich noch mal vom Hersteller vorhandene lowlevel Abstraktion) -> Ausgabe
sieht ja schon unrühmlich aus und ist nur ein sehr grober Weg. Wie viel Performance gewonnen werden kann, wenn Funktionen auf Treiberebene realisiert sind zeigen doch viele Beispiele.

RoKo

2006-04-26, 18:27:39

Das Problem - aus meiner Sicht - besteht darin dass ich (wie sieht es mit Dir aus) noch nie ein Konsole programmiert habe....
Ein klein wenig GBA mal.
Bei solchen kleineren oder älteren Geräten kann man aber sowieso relativ einfach selber prüfen, ob ein OS läuft: Kleines Demo mit Assemblerquellcode nehmen und in einen Emulator laden, mit dem man durch den ausgeführen Code singlesteppen kann.
Bei den neueren Geräten (PS2, Cube, XBox) spekuliere ich auch, aber gegenüber den älteren sehe ich eben einfach keinen Unterschied, der auf ein OS hinweisen würde.
Alle benutzen aber Betriebsystembibliotheken....
Was verstehst Du unter Betriebssystembibliothek?

Coda

2006-04-26, 18:30:48

Das bedeutet - aus meiner Sicht - dass diese Konsolen wohl ein Betriebsystem besitzten müssen.
Die C-Lib braucht kein Betriebssystem, aber bei den neuen Konsolen denke ich das es auf jedenfall eins gibt. Bei der PS2 bin ich mir da aber z.B. nicht so sicher.

beos

2006-04-26, 21:07:35

Was verstehst Du unter Betriebssystembibliothek?

Das bestimmte Bibiotheken - wie z.b. open und close usw....auf untere Betriebssytem Funktionen zugreifen müssen...

Steht gut beschreiben hier drin:

http://www.vieweg.de/index.php;do=show/sid=1538865623444fc48d8cb74900453776/site=v/book_id=261

RoKo

2006-04-26, 21:18:34

Das bestimmte Bibiotheken - wie z.b. open und close usw....auf untere Betriebssytem Funktionen zugreifen müssen...
Wenn ein Programm in einem ausgewachsenen Betriebssystem läuft, muß es über dieses gehen, wenn es auf irgendwelche Hardware zugreift. Aber ganz ohne geht's genau so, weil wenn kein Betriebssystem da ist, blockiert es auch nix ;)
Steht gut beschreiben hier drin:
Laut dem Link geht es in dem Buch darum, wie sowas in Unix funktioniert. Das ist doch nicht von Belang.

beos

2006-04-26, 21:24:13

Wenn ein Programm in einem ausgewachsenen Betriebssystem läuft, muß es über dieses gehen, wenn es auf irgendwelche Hardware zugreift. Aber ganz ohne geht's genau so, weil wenn kein Betriebssystem da ist, blockiert es auch nix ;)

Laut dem Link geht es in dem Buch darum, wie sowas in Unix funktioniert. Das ist doch nicht von Belang.

Das vermutest Du aber nur :wink:

Eine Funktion z.b. open - müßte dann alle I/O und Dateisystemfunktionen implementieren.

Das Buch bezieht sich auf den Posixstandart - der wohl - von Windows mal abgesehen - fast überall gültig ist.

RoKo

2006-04-26, 22:07:14

Eine Funktion z.b. open - müßte dann alle I/O und Dateisystemfunktionen implementieren.
Und? Wird einfach in einer ganz normalen Library zur Verfügung gestellt.
Das Buch bezieht sich auf den Posixstandart - der wohl - von Windows mal abgesehen - fast überall gültig ist.
In Windows hat er noch relativ viel Bedeutung. In anderen Betriebssystemen weniger. Auf Konsolen gar keine.

beos

2006-04-26, 22:25:27

In Windows hat er noch relativ viel Bedeutung. In anderen Betriebssystemen weniger. Auf Konsolen gar keine.

OT: In Windows sind KEINE Posix Funktionen mehr enthalten (zuletzt Teile in Windows NT)

Coda

2006-04-27, 00:56:56

In Windows 2000 war das auch noch da.

Was die C-API-Seite angeht hat sich aber gar nichts geändert, da ist ziemlich viel Posix-kompatibel.

beos

2006-04-27, 01:19:25

In Windows 2000 war das auch noch da.

Was die C-API-Seite angeht hat sich aber gar nichts geändert, da ist ziemlich viel Posix-kompatibel.

http://support.microsoft.com/default.aspx?scid=kb;en-us;308259

Aber Du hast recht - in 2000 waren Teile noch vorhanden ...aber keine komplette Implementierung

Gasthaus

2006-04-27, 01:40:49

...perfekt in Assembler auf die Hardware zugeschnitten...

Nur mal soviel,ein Kumpel von mir hat vor Äonen eine 2D-Scroll-Rutine entwickelt die damals sogar auf den auslaufenden i286er in sauberen 60FPS lief.Ich erinere mich noch an Ultima7 auf meinem 486er,was für eine Ruckelorgie dieses geil(st)e RPG doch war.

Das gabs bis dato noch nicht,nur Rruckelei-ähnlich heute:)

Das dazugehörende 2D-Ballergame war selbstverständlich in ASSEMLER geschrieben.

Gasthaus

2006-04-27, 02:02:27

Wer sagt denn bitte dass auf Konsolen in Assembler programmiert wird? :crazy2:

Da wär ich mir mal nicht so sicher.

Auf PC-Engine,SNES,NEO-GEO,MD,MS,PS1,Saturn gibt es eine Menge von Spielen die sich technisch gehörig von ihren"Kollegen"unterscheiden.

Schau dir mal Pulstar auf dem Neo-Geo,oder MAME,an und erkläre mir wie zur Hölle solch pausenlos perfekt animierte RenderSprites/Backrounds aus einem Motorola68000 12MHz Prozessor entspringen?

In C schwer vorstellbar...Eher Assembler.Nach 5Jahren HW-Gewöhnungszeit wäre reines C nicht angemessen.

Ich schätze durch OS/D3D/PC-Architektur an sich,verliert man an die Hälfte der Leistung.

OutRun2 auf XBox(GF3)verblüfft auch mit einer Grafik,die eigentlich so gar nicht sein sollte auf der armen GF3.Hmmm...Und TMSunrise(GF6)ruckelt daher wenn ich all die tollen Effekte einschalte,welche bei OutRun2 schon"default"sind,natürlich immer brav mit 60FPS:)Wenn da nicht mit hardwarenahen Programmierung gekocht wird,dann weiss ich auch nicht.

Gasthaus

2006-04-27, 02:18:34

Auf Konsolen wird nicht viel hardwarenaeher programmiert als auf dem PC.

Falsch!*reiflichüberlegt*

Nachsitzen!RidgeRacer 1,2,3,4 auf PS1 zocken und deine Behauptung das auf Konsolen nicht....revidieren:)

Klar EA und Konsorten sind programmiertechnich LOSER wie die meissten.Die können halt nur Basic.Die haben auch nix mit Konsolen zu tun,die kamen damals vom PC-Markt angekrochen und haben massgeblich die Konsolenlandschaft mit feinstem Basic versaut.Wieviele Konsolengames hast du überhaupt schon gezockt,deinem Statement nach nicht viele.

Warum glaubst du sind(waren)Namco Games immer die besten auf PS1+2??Die sind mit der Hardware verheiratet.
Und bei meinem Mädel gehe ich doch auch sehr hardwarenah ran:)

TheGoD

2006-04-27, 02:26:25

Gasthaus

2006-04-27, 02:31:16

Ja. Bei der Dreamcast kommt Windows CE zum Einsatz...

Jetzt haben wir einem guten Vergleich.

WinCE kam nur zu einem Bruchteil zum Einsatz.Und eben jener geringer Teil war technisch eine Katastrophe!SegaRally2 hat Sega damals mit WinCE total versaut.Naturlich hat die DC ein eigenes OS,wo kämen wir da hin?

Gasthaus

2006-04-27, 02:41:59

Hab vor X Jahren mal in der Maniac gelesen das v-rally 1 das erste Spiel auf der PS 1 war das teilweise in Assembler geschrieben wurde. Alles was davor kam (inkl. Ridge Racer 1 - x ;)) nutzte ausschließlich die von Sony bereitgestellten C++ Bibiotheken.

RageRacer und R4 kamen nach V-Rally raus.Und ich halte es für ein Gerücht das Sony Namco irgendwelche Sachen zur Verfügung stellen muss.Das macht Namco schon selbst und dafür sollte Sony Namco die Füsse lecken,denn ohne Namco gäbe es keine PS1,2,3,definitiv!!!Viele Libs sind bestimmt Namco Ursprungs.

Ich stelle mal das Gerücht in die Welt das Die PSX auf grafischer Seite ein abgespecktes System22 von Namco ist.Denn die Ähnlichkeiten und Schwächen/Stärken sind zu gross.Ironischerweise taufte Namco ihre PSX Arcade-HW in System11.

beos

2006-04-27, 12:09:08

Schau dir mal Pulstar auf dem Neo-Geo,oder MAME,an und erkläre mir wie zur Hölle solch pausenlos perfekt animierte RenderSprites/Backrounds aus einem Motorola68000 12MHz Prozessor entspringen?

Du vergißt, dass das NeoGeo - und auch alle anderen Arcade Systeme sehr viele Customs Chips besitzen - die die ganze Arbeit machen...

Beim NeoGeo würde der MC68k nur als Bridgeverteiler benutzt....der sorgte für die Koordination und Vertreilung der Rechnenaufgaben.

Avalox@Gast

2006-04-27, 12:33:10

Weil hier immer so viel über Assembler und C++ gesprochen wird.

Ich bin fest der Meinung, dass heutige C++ Compiler auf einem PC schnelleren Code erzeugen, als es einem Menschen am Assembler möglich ist. Das mag im Detail nicht zutreffen, sieht man sich aber Lösungen im gesamten an, wird das ganz sicher so sein.

Coda

2006-04-27, 15:01:07

Das würde ich so nicht sagen. Der Aufwand dafür ist nur sehr groß. Am meisten ist noch rauszuholen wenn man Innerloops mit SSE vektorisiert.

Klar EA und Konsorten sind programmiertechnich LOSER wie die meissten.Die können halt nur Basic.Die haben auch nix mit Konsolen zu tun,die kamen damals vom PC-Markt angekrochen und haben massgeblich die Konsolenlandschaft mit feinstem Basic versaut.Wieviele Konsolengames hast du überhaupt schon gezockt,deinem Statement nach nicht viele.
Ich hoffe mal das mit Basic ist nicht so ganz ernst gemeint :|

Gast

2006-04-27, 16:10:48

Klar EA und Konsorten sind programmiertechnich LOSER wie die meissten.Die können halt nur Basic.Die haben auch nix mit Konsolen zu tun,die kamen damals vom PC-Markt angekrochen und haben massgeblich die Konsolenlandschaft mit feinstem Basic versaut.Wieviele Konsolengames hast du überhaupt schon gezockt,deinem Statement nach nicht viele.Was hast du denn alles schon geleistet um dir so ein arrogantes Urteil zu erlauben?

Schon alleine die Behauptung "die können halt nur Basic" zeugt eher davon dass du absolut Keine Ahnung von Programmieren hast.
Du Heuchler!

Demirug

2006-04-27, 16:46:12

Ich schätze durch OS/D3D/PC-Architektur an sich,verliert man an die Hälfte der Leistung.

Die Leistung geht in der für den PC notwendigen Flexibilisierung verloren. Dazu tragen natürlich auch die zusätzlichen Abstraktionslayer des OS bei aber bei weitem nicht so stark wie die Layer im eigentlichen Spiel.

hofmetzger

2006-04-28, 00:34:40

Ich finde zunächst müssen wir definieren ab wann wir von einem Betriebssystem sprechen. Ich stelle mir mal 4 fälle vor.
a) Gerät verwaltet alle Hardwareressourcen mit eigenem Betriebssystem, Spiel wird eingelegt und greift über das BS auf die Ressourcen zu.
(Vergleiche übliches Wintelsystem)

b) Das Gerät selbst enthält kein BS. Das BS wird mit dem Spiel auf den Datenträger gebrannt.

c) wie b) nur, dass das BS soweit abgespeckt wurde, dass es nur noch das beiliegende Spiel "bedienen" kann.

d) das BS wie das Spiel sind soweit verschmolzen, dass kaum erkannt werden kann, ob bestimmte Funktionen nun primär zum BS oder zum Spiel gehören.

Die Übergänge sind fließend, und imho ist es wirklich Definitionssache "ob eine Konsole ein BS besitzt". Ich würde sagen dass im Zweifelsfall das Spiel selbst auch das BS ist.

In jedem Fall ist es der Performance zuträglich unnötigen Ballast abzuwerfen. Dass allerdings die xbox360 ein festes BS besitzt ist, welches (afaik) nicht zu "umgehen" ist, ist wohl eher eine Sicherheitstechnische Überlegung.

Gast

2006-04-28, 09:39:11

In jedem Fall ist es der Performance zuträglich unnötigen Ballast abzuwerfen. Dass allerdings die xbox360 ein festes BS besitzt ist, welches (afaik) nicht zu "umgehen" ist, ist wohl eher eine Sicherheitstechnische Überlegung.

Dass Konsolen heute ein BS besitzen, liegt in erster Linie an der Komplexität und den zunehmenden Anforderungen. Stell dir mal vor der Netzwerkzugriff erfolgt bei jedem Spiel durch eigenen Bibliotheken, die auf die HW zugreifen. Dann gibt es wohlmöglich zig unterschiedliche potentielle Fehlerquellen, die nicht einfach so mit einem Update behoben werden können. Die HW einheitlich zu abstrahieren, ist doch der einzig richtige Weg. Außerdem müssen heutige Konsolen schon etwas mehr bringen, wenn man den Powerknopf Knopf drückt, als den Nutzer zu bitten irgend ein Spiel einzulegen.
Der PC stellt einen ganz anderen Anspruch, als die Konsole und muss auch viel meh nebenbei machen.

Neomi

2006-04-28, 11:31:20

Dass Konsolen heute ein BS besitzen, liegt in erster Linie an der Komplexität und den zunehmenden Anforderungen. Stell dir mal vor der Netzwerkzugriff erfolgt bei jedem Spiel durch eigenen Bibliotheken, die auf die HW zugreifen.

Warum sollte die Hardware abstrahiert werden, wenn sie bekannt ist? Hardwareunabhängige APIs ja, aber das muß doch nicht zur Laufzeit aufgelöst werden. Es reicht völlig, wenn statische Bibliotheken beim Linken eingebunden werden, die dann die Hardware direkt ansprechen. Diese direkte Hardwareansteuerung kann man sogar als Inline-Funktionen in die Headerdateien einbinden, über die der Programmierer seine API bekommt. Letztendlich kann das Spiel direkt auf die Hardware zugreifen, obwohl nur die vorgegebenen Bibliotheken aus dem SDK genutzt wurden. Treiber und einen abstrahierten Hardwarezugriff zur Laufzeit gibt es bei echten Konsolen nicht, genau deshalb ist ja z.B. die Emulation von XBox-Spielen auf der XBox 360 teilweise so problematisch.

GBWolf

2006-04-28, 11:36:02

Gast

2006-04-28, 11:50:24

Warum sollte die Hardware abstrahiert werden, wenn sie bekannt ist? Hardwareunabhängige APIs ja, aber das muß doch nicht zur Laufzeit aufgelöst werden.

Der Entscheidende Punkt stand nach dem gequoteten Satz. Und dynamisches Binden halte ich für notwendig, wenn man mal updaten will. Was machst du denn, wenn sich plötzlich ein paar Leute durch irgendwelche Schwachstellen in deine Konsole hacken und zum Absturz bringen, während du gerade zockst. Kein Problem, wenn man den Code einfach austauschen kann. Es ist aber ein Problem, wenn man es statisch bindet und einkompiliert.

Treiber und einen abstrahierten Hardwarezugriff zur Laufzeit gibt es bei echten Konsolen nicht, genau deshalb ist ja z.B. die Emulation von XBox-Spielen auf der XBox 360 teilweise so problematisch.

Die Konsole entwickelt sich aber immer mehr zu Mutitasking Maschine, so schwer das vorauszusehen ist es nun nicht. Das hat zwangsweise zur Folge, dass ein OS die Task verwaltet und die Programme im Usermode laufen müssen. Bei der XBOX 360 soll es doch mal ein Update geben, wo im Hintergrund während dem Spielen die Konsole sich updatet. Das wäre ein erstes Bsp. Wenn man dann mal das weiterdenkt, fällt einen dann zukünftig Musikdownloads und anderes ein, während man spielt.

Neomi

2006-04-28, 11:55:34

die xbox ist doch son pc, und da laufen trotz deutlich schwächerer hw, noch sachen drauf, die auf einem gleich ausgestatteten PC nicht mal starten würden ;)

Nicht die Hardware ist es, was einen PC zum PC macht, sondern das modulare Konzept. Auch eine (theoretische) Konsole, die nur typische PC-Hardware verwendet und in einem Towergehäuse daherkommt, ist kein PC. Einheitliche Hardware (mit genau spezifizierten Fähigkeiten) und die dadurch resultierende direkte Ansteuerung machen den Unterschied.

Neomi

2006-04-28, 12:11:07

Der Entscheidende Punkt stand nach dem gequoteten Satz. Und dynamisches Binden halte ich für notwendig, wenn man mal updaten will. Was machst du denn, wenn sich plötzlich ein paar Leute durch irgendwelche Schwachstellen in deine Konsole hacken und zum Absturz bringen, während du gerade zockst. Kein Problem, wenn man den Code einfach austauschen kann. Es ist aber ein Problem, wenn man es statisch bindet und einkompiliert.

OK, in dem Fall ist eine statische Bindung wirklich nachteilig, aber ein OS ist deshalb noch nicht nötig. Es reicht in dem Fall, wenn Code von einer updatebaren Stelle in der Konsole nachgeladen werden kann. Das kann das Spiel dann auch selbst erledigen, ganz ohne OS.

Die Konsole entwickelt sich aber immer mehr zu Mutitasking Maschine, so schwer das vorauszusehen ist es nun nicht. Das hat zwangsweise zur Folge, dass ein OS die Task verwaltet und die Programme im Usermode laufen müssen. Bei der XBOX 360 soll es doch mal ein Update geben, wo im Hintergrund während dem Spielen die Konsole sich updatet. Das wäre ein erstes Bsp. Wenn man dann mal das weiterdenkt, fällt einen dann zukünftig Musikdownloads und anderes ein, während man spielt.

Multitasking ist auch ein Grund für ein OS. Unter DOS hatte ich schon Multithreading, indem ich mich in den Timerinterrupt reingehängt und von da aus zwischen einzelnen Threads gewechselt habe. Sowas kann man genauso gut in eine statische Bibliothek packen.

Gast

2006-04-28, 13:08:22

Es reicht in dem Fall, wenn Code von einer updatebaren Stelle in der Konsole nachgeladen werden kann. Das kann das Spiel dann auch selbst erledigen, ganz ohne OS.

Und wer garantiert dir das, bei dann x möglichen Bibliotheken für die selbe Funktion, wo dann noch jedes Spiel eine andere verwendet? Vielleicht verkauft sich ja Spiel x mit lib y schlecht und es besteht kein Interesse da zu fixen. Dann schauen plötzlich alle Spieler von Spiel x dumm in die Wäsche. Da kann man sich noch viel mehr ausmalen, warum das nicht sinnvoll ist und einer die Hand drüber halten sollte.

[/QUOTE]
Unter DOS hatte ich schon Multithreading, indem ich mich in den Timerinterrupt reingehängt und von da aus zwischen einzelnen Threads gewechselt habe. Sowas kann man genauso gut in eine statische Bibliothek packen.[/QUOTE]

Du kannst auch kooperatives Multitasking verwenden und alles läuft im Kernelmode. Aber das ist jetzt nicht ernst gemeint oder? Ein Consumer Produkt sollte schon stabil laufen und das OS selbst ist hier vernachlässigbar, was die Performance angeht. Beim PC ist das Problem, dass viel mehr Geräte dranhängen, viel mehr Programme ablaufen und alles viel generischer und fexibler sein muss. Schon mal das ganze IRQL/DPC Handling ist bei einem PC Consumer OS i.d.R. ganz anders ausgelegt und nimmt höhere Latenzen zu Gunsten der Insgesamt besserer Multitaskingfähigkeit/Kommunikation mit der gesammten HW in Kauf als z.B. ein Echtzeit OS mit marginalen Funktionen und einer festen HW. Ich weiß zwar nicht, ob die XBOX/XBOX 360 ein Echtzeit OS hat, aber eine Konsole wäre sicher geeignet. Aber auch das ist wohl vernachlässigbar, man braucht sich nämlich nur mal im Taskmanager die zig Task und somit zig Threads ansehen. Und wenn hier ein Großteil auf der Konsole entfällt, weil sie nicht benötigt werden, erklärt das schon sehr die teils bessere Performance bei gleichen Aufgaben. Nur bleibt abzuwarten wie komplex Konsolen in Zukunft werden.

hofmetzger

2006-04-28, 13:44:14

Dass Konsolen heute ein BS besitzen, liegt in erster Linie an der Komplexität und den zunehmenden Anforderungen. Stell dir mal vor der Netzwerkzugriff erfolgt bei jedem Spiel durch eigenen Bibliotheken, die auf die HW zugreifen. Dann gibt es wohlmöglich zig unterschiedliche potentielle Fehlerquellen, die nicht einfach so mit einem Update behoben werden können. Die HW einheitlich zu abstrahieren, ist doch der einzig richtige Weg. Außerdem müssen heutige Konsolen schon etwas mehr bringen, wenn man den Powerknopf Knopf drückt, als den Nutzer zu bitten irgend ein Spiel einzulegen.
Der PC stellt einen ganz anderen Anspruch, als die Konsole und muss auch viel meh nebenbei machen.

Das ist natürlich richtig.
Pure Spekulation: hätte die PS2 eine stärkere Abstraktion ggü der Software, gäb es heute keine PS2-Spiele, die zur aktuellen Slim-PS2 inkompatibel sind.

Coda

2006-04-28, 16:30:18

Wieso? Die Hardware-Spezifikation ist die gleiche geblieben.

#44

2006-04-28, 17:12:47

Was machst du denn, wenn sich plötzlich ein paar Leute durch irgendwelche Schwachstellen in deine Konsole hacken und zum Absturz bringen, während du gerade zockst. Kein Problem, wenn man den Code einfach austauschen kann. Es ist aber ein Problem, wenn man es statisch bindet und einkompiliert.

rofl und wieviele böhse haxxxx0rz wollen eine ps3 oä zum absturz bringen? oder gar deine achsowertvollen saves löschen? ^^ ne das ist schon mehr als lächerlich.

ausserdem wäre das spielspezifisch (je nach verwendeten dateien) und es würde nur "hackbar" sein wenn ein spiel mit alten libs gespielt wird... (eine console hat keinen autostart... da viren einzuschleusen die geladen werden (nach einem neustart) sollte durchaus schwierig sein (wenn überhaupt möglcih))

hofmetzger

2006-04-28, 17:15:12

Wieso? Die Hardware-Spezifikation ist die gleiche geblieben.

Man nutzte ja Eigenschaften/Verhalten der Hardware, die/das nicht offiziell spezifiziert waren/war. Mit Änderung der Hardware hat sich auch manches unspezifiziertes Verhalten geändert.

Durch eine stärkere Abstraktion, bieten sich solche unspezifizierten Funktionen erst garnicht an.

Coda

2006-04-28, 17:34:56

Das wurde gleich gelassen. Auf der PS2 wird verdammt hardwarenah programmiert, bis hinunter zum manuellen ansprechen der DMA-Controller.

Gast

2006-04-29, 00:23:26

#44[/POST]']rofl und wieviele böhse haxxxx0rz wollen eine ps3 oä zum absturz bringen? oder gar deine achsowertvollen saves löschen? ^^ ne das ist schon mehr als lächerlich.

Woher willst du das wissen? Die PS3 wird sicher auch ein OS haben, Sony will doch auch irgend einen tollen Onlineservice bieten, wo man Musik, Filme runterladen kann. Stell dir mal vor, du bezahlst mit Kreditkarte und die Daten würden auf Festplatte gespeichert werden oder man will ganz einfach deinen Content von Festplatte stehlen. Motive gibt es für alles, genau so gut könnte man die Konsolen nur zum Spass abschießen.

ausserdem wäre das spielspezifisch (je nach verwendeten dateien) und es würde nur "hackbar" sein wenn ein spiel mit alten libs gespielt wird...

Was meinst du mit nur? Bei welchen Konsolen wurden denn bisher schon groß Libs nachgeschoben? Bisher war das auch nicht so wichtig, weil die Onlinefunktionalität immer nur nebensächlich war (außer bei der XBOX vielleicht).

(eine console hat keinen autostart... da viren einzuschleusen die geladen werden (nach einem neustart) sollte durchaus schwierig sein (wenn überhaupt möglcih))

Natürlich kann das möglich sein. Man könnte ja einen modifizierten Spieleserver verwenden und dann durch eine eventuelle Schwachstelle den Datentransfer so manipulieren, dass vielleicht ein Buffer Overrun ausgenutzt wird oder irgend etwas anderes. Im einfachsten Fall könnte man vielleicht die Konsole abschließen, im schlimmsten Fall die Konsole übernehmen.

Neptun

2006-04-29, 12:26:39

Wishnu[/POST]']In irgendeiner c't hatten sie ähnliches einmal mit dem c't-Apfelmännchen getestet.

Der handoptmierte Assembler-Code war glaube ich um den Faktor 13 schneller (habe damals auch nicht schlecht gestaunt).

woher bekomme ich das c't-Apfelmännchen Porgramm ?
Gibt es irgendwo einen Link ?

beos

2006-04-29, 12:56:51

Wishnu[/POST]']In irgendeiner c't hatten sie ähnliches einmal mit dem c't-Apfelmännchen getestet.

Der handoptmierte Assembler-Code war glaube ich um den Faktor 13 schneller (habe damals auch nicht schlecht gestaunt).

Die handoptimierten Assembler Versionen setzen aber (meines wissen) gleich auf
SIMD befehle....und dass das dann, mit dem mandelbrotalgo x-mal schneller wird
ist eigentlich normal

beos

2006-04-29, 12:57:32

Neptun[/POST]']woher bekomme ich das c't-Apfelmännchen Porgramm ?
Gibt es irgendwo einen Link ?

http://www.heise.de/ct/ftp/result.xhtml?url=/ct/ftp/98/15/186/default.shtml&words=Apfelm%E4nnchen

Demirug

2006-04-29, 13:01:32

Coda[/POST]']Das wurde gleich gelassen. Auf der PS2 wird verdammt hardwarenah programmiert, bis hinunter zum manuellen ansprechen der DMA-Controller.

Das liegt aber eher daran das Sony es versämmt hatte ordentliche Hochsprachen-Tools und APIs zu schaffen.

Gasthaus

2006-04-29, 23:53:22

Coda[/POST]']Das würde ich so nicht sagen. Der Aufwand dafür ist nur sehr groß. Am meisten ist noch rauszuholen wenn man Innerloops mit SSE vektorisiert.

Ich hoffe mal das mit Basic ist nicht so ganz ernst gemeint :|

Na ja,wenn ich mir das erste EA Hockey auf MegaDrive anschaue wäre ich mir nicht mal so sicher...

...schade,denn es war sehr gut.

Ansonsten ists klar übertrieben.Doch nehmen wir das erste SSX auf PS2.Die Pal-Version ruckelte fürchterlich und ich dachte,EA halt...
Dann ist mir die NTSC-Version in die Finger geraten,feinste 60FPS.Also hält EA den PAL-Consumer für so dumm,das sie eine Verschlechterung eines guten Titels in Kauf nimmt.

Gasthaus

2006-04-29, 23:57:07

Gast[/POST]']Was hast du denn alles schon geleistet um dir so ein arrogantes Urteil zu erlauben?

Schon alleine die Behauptung "die können halt nur Basic" zeugt eher davon dass du absolut Keine Ahnung von Programmieren hast.
Du Heuchler!

Hab auch keine Ahnung vom coden.Doch genug Vergleiche um die"Leistungen"div.Hersteller abzuwägen.

Gasthaus

2006-04-30, 00:10:39

beos[/POST]']Du vergißt, dass das NeoGeo - und auch alle anderen Arcade Systeme sehr viele Customs Chips besitzen - die die ganze Arbeit machen...

Beim NeoGeo würde der MC68k nur als Bridgeverteiler benutzt....der sorgte für die Koordination und Vertreilung der Rechnenaufgaben.

Das ist natürlich richtig.Doch Pulstar hat öfters Slowdowns(da wirkich an der Grenze),wenn ich bei MAME die CPU-Power um ca.30% erhöhe verschwinden die Slowdowns.

Ich denke Solche Systeme werden oft an ihre Grenzen getrieben sodas alles,auch die CPU,zum limitierenden Faktor wird.

Was mich besonders am Neo-Geo interessiert wie man mit 64kB Video-Ram so gute Grafik zaubert.Das SNES hatte doppelt soviel V-Ram,war dem NG aber deutlich unterlegen.

Auch sehr interessant,die Moduldaten waren soweit ich weiss nicht komprimiert,bei allen anderen damals erhältlichen Konsolen schon.Dadurch waren die Module wegen den grossen Rom-Kapazitäten sehr sehr teuer.Warum dies?Könnte es vielleicht sein dass das NG auf die maximalen 330Mbit Rom direkt zugreifen kann und somit den kleinen VideoSpeicher ständig und verzögerungsfrei mit Daten versorgen kann?

RoKo

2006-04-30, 00:19:45

Gasthaus[/POST]']Könnte es vielleicht sein dass das NG auf die maximalen 330Mbit Rom direkt zugreifen kann und somit den kleinen VideoSpeicher ständig und verzögerungsfrei mit Daten versorgen kann?
Exakt so funktioniert das. Bei SNES, Mega Drive und co. aber auch, sonst hätten die nämlich alle mit ihrem Mager-RAM nix reissen können, sprich da wurde normalerweise auch gar nix an Grafik komprimiert.

beos

2006-04-30, 00:27:36

Gasthaus[/POST]']

Auch sehr interessant,die Moduldaten waren soweit ich weiss nicht komprimiert,bei allen anderen damals erhältlichen Konsolen schon.Dadurch waren die Module wegen den grossen Rom-Kapazitäten sehr sehr teuer.Warum dies?Könnte es vielleicht sein dass das NG auf die maximalen 330Mbit Rom direkt zugreifen kann und somit den kleinen VideoSpeicher ständig und verzögerungsfrei mit Daten versorgen kann?

Ich denke mal - du liegst richtig.

die cd version des neo geo hatte ja extra speicher - die daten der modul konsole wurden wohl direkt aus den modulen gelesen.

was mich etwas stutzig macht....wie bekomme ich ein fertiges bild mit 320*240*2 byte in 64 kbyte videospeicher ???

Gast

2006-04-30, 13:53:06

RoKo[/POST]']Ich kenne sogar richtige Betriebssysteme, die das nicht haben (AmigaOS zum Beispiel). Bei einem Konsolenspiel wäre es sogar äußerst hinderlich.

Besseres Beispiel: MS-DOS. Zitat:"640K should be enough for anybody" ;)

Gasthaus

2006-04-30, 21:57:06

beos[/POST]']Ich denke mal - du liegst richtig.

die cd version des neo geo hatte ja extra speicher - die daten der modul konsole wurden wohl direkt aus den modulen gelesen.

was mich etwas stutzig macht....wie bekomme ich ein fertiges bild mit 320*240*2 byte in 64 kbyte videospeicher ???

GENAU diese Frage stelle ich mir immer wieder.Habe extra mein NG aufgegaut um dieses Feeling im Original zu geniessen.Witzig im Vergleich zum NG fallen mir Ladeteiten bei den übrigen Modulsystemen auf.Das Ein-und Ausblenden von Screens(FinalFantasy)diente nur zur Kaschierung der Ladezeiten(die sich unterhalb einer Sekunde befanden).Wenn ich das NG einschalte ist das Game sofort da,und bei keinen anderen Modulsystem kann ich mich so schnell ins Spiel"reinbashen".

Meine Vermutung ist,der Videospeicher hat kompletten Zugriff auf alle Videodaten und somit kann das Modul wie eine Film-DVD alles abspulen mit den Vorteil von echtem"Branching".Anders ist der mehrsekündige in Full-Screen leufende Rendervorpann von Strikers1945Plus nicht erklärbar!

Ich finde die heutige 3D-Technologie kann einiges von alter Arcade-Tech lernen,was Effizienz und Intelligenz angeht.Ich finde das Niveau der heutigen 3D-Grafik ist niedriger als das Niveau eines NeoGeos zB,natürlich auf 2D uminterpretiert.Das ist leicht beweisbar!Wenn ich mir Raiden3 anschaue,welches ein wirklich guter 2D-Shooter auf Basis von 3D-Grafik ist,fällt mir auf wie schwer es ist eine schön aussehende Landschaft,welche verikal von oben gezeigt wird und scrollt,zu erschaffen.Und das sind keine noobs oder so...

Nun schaue ich mir einen Cave-Shooter an zB.Guwange(1999),und komme aus dem Staunen nicht mehr heraus wieviel Detailliebe 2D-Grafik aufweisen kann.Um das gescheit mit Polygonen zu realisieren,bedarf es genausoviel von denen,wie beim Rendern der 2D-Backgrounds/Sprites nötig waren.Und das sind für heutige 3D-Verhälnisse immer noch zu viele.....Nicht zu vergessen das heutige 3D-Systeme nicht unbedingt darauf ausgelegt sind hunderte sich voneinander unabhängige Objekte inklusve"Spritekollision"fliessend zu berechnen.

Bei Ibara(Cave2005)gibt es Szenen wo so viel Objekte über den Screen sprudeln das der Background nicht mehr sichtbar ist.In 3D hab ich solche Dynamik-Explosionen leider noch nicht gesehen.

Auch warren Multiprozessor-Systeme in der Arcadevergangenheit keine Seltenheit,zum Teil mit bis zu fünf(oder mehr)unterschiedlichen Prozessoren.Dual-Core heute???

Coda

2006-04-30, 22:55:34

Gast[/POST]']Besseres Beispiel: MS-DOS. Zitat:"640K should be enough for anybody" ;)
Das hat Bill Gates nie gesagt.

Coda

2006-04-30, 23:04:26

Gasthaus[/POST]']Nun schaue ich mir einen Cave-Shooter an zB.Guwange(1999),und komme aus dem Staunen nicht mehr heraus wieviel Detailliebe 2D-Grafik aufweisen kann.Um das gescheit mit Polygonen zu realisieren,bedarf es genausoviel von denen,wie beim Rendern der 2D-Backgrounds/Sprites nötig waren.
Dafür gibts ja Normalmaps. Du kannst ja wohl nicht behaupten dass die Models aus den Unreal-Engine-3-Demos "undetailiert" sind.

Gasthaus[/POST]']Und das sind für heutige 3D-Verhälnisse immer noch zu viele.....Nicht zu vergessen das heutige 3D-Systeme nicht unbedingt darauf ausgelegt sind hunderte sich voneinander unabhängige Objekte inklusve"Spritekollision"fliessend zu berechnen.
Physikbeschleuniger.

Gasthaus[/POST]']Auch warren Multiprozessor-Systeme in der Arcadevergangenheit keine Seltenheit,zum Teil mit bis zu fünf(oder mehr)unterschiedlichen Prozessoren.Dual-Core heute???
Multiprozessorsysteme sind immer eine Notlösung wenn sich Leistung nicht mehr herkömmlich steigern lässt. An dem Punkt sind wir jetzt (leider) auch beim PC angelangt.

Sorry, aber dieses "bei Konsolen ist alles besser" ist etwas arg blauäugig.

Gast

2006-05-01, 00:44:29

Coda[/POST]']Das hat Bill Gates nie gesagt.

Stimmt, kommt nämlich von Intel. Aber gewisse Mythen halten sich eben starr.

Gasthaus

2006-05-01, 23:41:05

Coda[/POST]']Dafür gibts ja Normalmaps. Du kannst ja wohl nicht behaupten dass die Models aus den Unreal-Engine-3-Demos "undetailiert" sind.

Physikbeschleuniger.

Multiprozessorsysteme sind immer eine Notlösung wenn sich Leistung nicht mehr herkömmlich steigern lässt. An dem Punkt sind wir jetzt (leider) auch beim PC angelangt.

Sorry, aber dieses "bei Konsolen ist alles besser" ist etwas arg blauäugig.

Es ist nicht alles besser an Konsolen...Doch wird es langsam Zeit auf dem PC besser optimieren zu können.Die total offene Architektur hindert Optimierungen und sehr viel Potenzial geht verloren.

Physikbeschleuniger sind natürlich erste Sahne wenns um viele Objekte geht mit korrekter Berechnung geht.Doch Softwaremässig gehen heutige High-End-Karten zu schnell in die Knie wenn mal wirklich viel los ist-Bei damaligen 2DHigh-End nicht.So ein PC besteht leider aus sehr vielen Flaschenhälsen,auf HW-sowie auf Softwareseite.Diese gilt es soweit als möglich zu beseitigen.

Ein erster Schritt wäre eine direkte GPU-Anbindung an die CPU mittels zweitem CPU-Sockel(Hypertransport3.0).

Oder wie sieht es aus mit den heute völlig unnützen Dual-Cores?(Im Spielebereich)Da wird seit langer Zeit was verkauft was praktisch wenig Nutzen hat,und wieviele encoden und zocken gleichzeitig?

Coda

2006-05-02, 00:26:39

Gasthaus[/POST]']Es ist nicht alles besser an Konsolen...Doch wird es langsam Zeit auf dem PC besser optimieren zu können.Die total offene Architektur hindert Optimierungen und sehr viel Potenzial geht verloren.
Das ist pauschalisiert und wird überall gebetsmühlenartig wiederholt. Ich glaube nicht daran.

Es geht ein bestimmter Anteil verloren, aber ich denke dass die Konsolen vor allem besser ausgenützt werden weil Wissen von heute auf Technik von damals angewendet wird was es beim PC einfach nicht gibt.

Gasthaus[/POST]']Physikbeschleuniger sind natürlich erste Sahne wenns um viele Objekte geht mit korrekter Berechnung geht.Doch Softwaremässig gehen heutige High-End-Karten zu schnell in die Knie wenn mal wirklich viel los ist-Bei damaligen 2DHigh-End nicht.So ein PC besteht leider aus sehr vielen Flaschenhälsen,auf HW-sowie auf Softwareseite.Diese gilt es soweit als möglich zu beseitigen.
2D und 3D sind nunmal grundlegend unterschiedliche Dinge. Der Vergleich hinkt gewaltig.

Der PC hat keine Flaschenhälse. Das einzige was wirklich limitiert ist die CPU an sich oder die GPU an sich, nichts dazwischen.

Gasthaus[/POST]']Ein erster Schritt wäre eine direkte GPU-Anbindung an die CPU mittels zweitem CPU-Sockel(Hypertransport3.0).
Eine GPU kannst du nicht sockeln. Das Speicherinterface würde das nicht mitmachen. Bringen würde es zudem auch nicht viel.

Gasthaus

2006-05-03, 00:04:35

Coda[/POST]']Das ist pauschalisiert und wird überall gebetsmühlenartig wiederholt. Ich glaube nicht daran.

Es geht ein bestimmter Anteil verloren, aber ich denke dass die Konsolen vor allem besser ausgenützt werden weil Wissen von heute auf Technik von damals angewendet wird was es beim PC einfach nicht gibt.

2D und 3D sind nunmal grundlegend unterschiedliche Dinge. Der Vergleich hinkt gewaltig.

Der PC hat keine Flaschenhälse. Das einzige was wirklich limitiert ist die CPU an sich oder die GPU an sich, nichts dazwischen.

Eine GPU kannst du nicht sockeln. Das Speicherinterface würde das nicht mitmachen. Bringen würde es zudem auch nicht viel.

Natürlich ist 2D und 3D zweierlei.

Doch den Normalo juckts nicht.Der hat damals auf 2D"Objektexplosionen"gesehen und denkt sich heute,wieso das nicht mehr möglich ist.Gerade durch die technische Evolution dürfen keine Kompromisse a la GF6 und der Flimmerei zugunsten mehr FPS mehr sein.

Die heutige 3D-Grafik kann es in Sachen Dynamik nicht mit damaligem 2D aufnehmen.Wie auch wenn schon bei einer grösseren Explosion die Framerate ins Wanken gerät.Ich möcht in FarCry auf 30 Fässer schiessen OHNE das die Framerate bei 60Hz/FPS auch nur einen Mucks macht.Ohne teuren Physikbeschleuniger natürlich.Dieses Feeling bin ich gewöhnt,wenn auch"nur" von 2D,doch nur eine bessere grafische Umgebung beindruckt mich nicht wenns ne Kaffeefahrt ist....Und solange 30FPS als OK gesehen wird bleibts ne Kaffeefahrt.Für die 20FPS bei Age3 häts bei mir ne Tracht Prügel gegeben,selbst SLI holts nicht raus,lächerlich.

Zu den Flaschenhälsen,das ganze PCI-System ist ein Flaschenhals,Platten,GKs,Sound...hängt da dran wenn ich mich nicht täusche.Über Win fäng ich erst gar nicht an...Die lächerlichen Datenübertragungsraten vom RAM zur CPU wollen auch erwähnt werden.Im Vergleich zu einer geschlossenen Architektur ist der PC naturgemäss ein einziger Flaschenhals,war schon zu 386er Zeiten so und ist heute noch so.Nur mit viel mehr Rohperformance,welche dann auch noch zum Teil sinnlos versiegt.

Gasthaus

2006-05-03, 00:10:56

Da kommt mir gerade so ein Gedanke...
Wäre es möglich Win in Module zu zerstückeln,welche je nach Gebrauch aktiviert/hochgefahren werden?Das hiesse,wenn ich zocke wäre nur das"Gamingmodul"plus"Basismodul"aktiv.Somit würden doch viel weniger unnötiger Hintergrundgeschichten laufen und Win wäre schneller.Nur so ein Gedanke...

Coda

2006-05-03, 00:16:40

Gasthaus[/POST]']Zu den Flaschenhälsen,das ganze PCI-System ist ein Flaschenhals,Platten,GKs,Sound...hängt da dran wenn ich mich nicht täusche.
Das limitiert bei Spielen aber alles nicht. Wenn dann ganz leicht die Soundkarte, und selbst dort lässt sich das mit Onboard-Speicher lösen.

Gasthaus[/POST]']Über Win fäng ich erst gar nicht an...
Was ist mit "Win"?

Gasthaus[/POST]']Die lächerlichen Datenübertragungsraten vom RAM zur CPU wollen auch erwähnt werden.
Eine CPU braucht eine gute Speicherlatenz. Bandbreite ist dort nicht besonders wichtig. Sieht man doch am Wechsel zu DDR2. Hat sogut wie nichts gebracht.

Gasthaus[/POST]']Im Vergleich zu einer geschlossenen Architektur ist der PC naturgemäss ein einziger Flaschenhals,war schon zu 386er Zeiten so und ist heute noch so.Nur mit viel mehr Rohperformance,welche dann auch noch zum Teil sinnlos versiegt.
Das sind Ammenmärchen.

Gasthaus[/POST]']Da kommt mir gerade so ein Gedanke...
Wäre es möglich Win in Module zu zerstückeln,welche je nach Gebrauch aktiviert/hochgefahren werden?Das hiesse,wenn ich zocke wäre nur das"Gamingmodul"plus"Basismodul"aktiv.Somit würden doch viel weniger unnötiger Hintergrundgeschichten laufen und Win wäre schneller.Nur so ein Gedanke...
Das ist doch völlig Unnötig. Was nicht läuft wird schlimmstenfalls ausgelagert und kratzt die CPU in dem Moment doch überhaupt nicht

Schau dir die Performancefolien von ATi und nVIDIA an, dort wird sehr genau darauf eingegangen was die Spieleperformance wirklich limitiert. Und das ist ganz sicher nicht das von dir propagierte Zeug.

Gasthaus

2006-05-03, 00:19:01

Coda[/POST]']

Eine GPU kannst du nicht sockeln. Das Speicherinterface würde das nicht mitmachen. Bringen würde es zudem auch nicht viel.

Mir schwebte eher eine Steckkarte mit RAM/GPU vor,die dann einfach in den zweiten CPU-Sockel kommt.Die Grafik sollte endlich abgekoppelt werden von den anderen"Sachen".Eine GPU+RAM gehört direkt neben den Prozessor+RAM und die Northbridge gleich dazu.

Gasthaus

2006-05-03, 00:23:31

Coda[/POST]']Das limitiert bei Spielen aber alles nicht. Wenn dann ganz leicht die Soundkarte, und selbst dort lässt sich das mit Onboard-Speicher lösen.

Was ist mit "Win"?

Eine CPU braucht eine gute Speicherlatenz. Bandbreite ist dort nicht besonders wichtig. Sieht man doch am Wechsel zu DDR2. Hat sogut wie nichts gebracht.

Das sind Ammenmärchen.

Das ist doch völlig Unnötig. Was nicht läuft wird schlimmstenfalls ausgelagert und kratzt die CPU in dem Moment doch überhaupt nicht

Schau dir die Performancefolien von ATi und nVIDIA an, dort wird sehr genau darauf eingegangen was die Spieleperformance wirklich limitiert. Und das ist ganz sicher nicht das von dir propagierte Zeug.

Hmm,wieso laufen EMUs,also reine CPU Auslastung,unter DOS viel schneller als unter Windows.Und hat MS nicht selbst zugegeben das der WinExplorer alleine schon soviel frisst(das es verboten gehört),denn Vista macht dann alles besser:)

Coda

2006-05-03, 00:23:38

Gasthaus[/POST]']Mir schwebte eher eine Steckkarte mit RAM/GPU vor,die dann einfach in den zweiten CPU-Sockel kommt.Die Grafik sollte endlich abgekoppelt werden von den anderen"Sachen".Eine GPU+RAM gehört direkt neben den Prozessor+RAM und die Northbridge gleich dazu.
Und weshalb? Die Latenz von PCIe ist absolut performanceunkritisch, weil 3D-Grafik sowieso einen bis mehrere Frame aus der Vergangenheit gerendert wird. Das wird alles gebuffert.

Bei der Bandbreite gibts auch kein Problem, die 4GB/s in jede Richtung reichen locker aus. Statische Daten (Texturen, Geometry) liegen eh im VRAM.

Sorry, aber du laberst Bullshit.

Im Gegenteil ist es eigentlich äußerst sinnvoll für GPU und CPU getrennte Speicher zu haben, da die CPU gute Latenzen aber relativ wenig Bandbreite und einer GPU die Latenzen so gut wie scheiß egal sind sie dafür Bandbreite braucht ohne Ende.

Das unified-memory bei den Konsolen hat einen guten Grund: Kostensenkung.

Gasthaus[/POST]']Hmm,wieso laufen EMUs,also reine CPU Auslastung,unter DOS viel schneller als unter Windows.
Weil sie verpfuscht programmiert sind?

Gasthaus[/POST]']Und hat MS nicht selbst zugegeben das der WinExplorer alleine schon soviel frisst(das es verboten gehört),denn Vista macht dann alles besser:)
Vista macht in der Tat einiges besser was das Grafiksubsystem angeht, was aber nicht heißt dass es unter XP unglaublich schrecklich wäre.

Gasthaus

2006-05-03, 00:46:01

Coda[/POST]']Und weshalb? Die Latenz von PCIe ist absolut performanceunkritisch, weil 3D-Grafik sowieso einen bis mehrere Frame aus der Vergangenheit gerendert wird. Der Rest ist gebuffert.

Bei der Bandbreite gibts auch kein Problem, die 4GB/s in jede Richtung reichen locker aus. Statische Daten (Texturen, Geometry) liegen eh im VRAM.

Sorry, aber du laberst Bullshit.

Weil sie verpfuscht programmiert sind?

Vista macht in der Tat einiges besser was das Grafiksubsystem angeht, was aber nicht heißt dass es unter XP unglaublich schrecklich wäre.

Kanntse auch bisschen netter ausdrücken.Lerne ja grad dazu woran es liegt das mein persönliches Gefühl mich nicht in dem bestätigt was ich aus Erfahrung kenne.Kann es vieleicht nicht immer auf technischer Basis erklären,aber wenn etwas suckt,dann suckt es halt.Wo ist das Problem?Und über meinen persönlichen Eindruck den ich von heutigen PC Games habe,diskutier ich nicht.Das ist nunmal eine persönliche Sache die nicht auf irgendein Fanboytum stützt,sondern auf dem was ich sehe.Und auf dem Bildschirm haben Folien oder sonstwelche theoretischen Daten keinen Bestand mehr.

Wenn nämlich alles so toll und cool wäre,wieso ärgern sich die Leute über dies und das.Auf ner PS2 ärgere ich mich höchstens mit dem schlechten LW.

Ein Beispiel:Ich glaub Starlancer hies dieser tolle und flüssige Weltraumshooter.Supergeile Mousesteurung und flinke Handhabung,alles wunderbar...solange KEINE Funksprüche gehen!Sobald einer der vielen pausenlosen und atmosphärischen Funksprüche aktiviert wird ZUCKELT es ganz kurz und somit die ganze Zeit.Sorry aber mich interessiert in letzter Instanz herzlich wenig,auf welchen technischen Grundlagen dies passiert.

Für mich ruckelt es einfach und nervt gewaltig!Auf Konsolen ist mir so ein SCHEISS noch nicht passiert,zumindest nicht bei einem so hochwertigen Game wie oben genannt.Das ist nunmal PC,ob du willst oder nicht.
Warum sonst gibt es nur aufs Spielen zugeschnittene Systeme,welche kein beklopptes OS mit sich führen und kein D3D-Kram haben(XBox ausgeschl.)usw usw.Also kein PC.

Coda

2006-05-03, 00:47:52

Evlt. liegt es daran dass das Spiel einfach scheiße programmiert oder (insbesondere) portiert ist? Dafür kann doch der PC nix.

Ein Beispiel:Ich glaub Starlancer hies dieser tolle und flüssige Weltraumshooter.Supergeile Mousesteurung und flinke Handhabung,alles wunderbar...solange KEINE Funksprüche gehen!Sobald einer der vielen pausenlosen und atmosphärischen Funksprüche aktiviert wird ZUCKELT es ganz kurz und somit die ganze Zeit.Sorry aber mich interessiert in letzter Instanz herzlich wenig,auf welchen technischen Grundlagen dies passiert.
Du willst doch nicht ernsthaft von deinem System auf sämtliche anderen schließen? :|
Es gibt durchaus auch Systeme (meins z.B. *hint*) wo sowas nicht vorkommt.

Übrigens gibts auch durchaus Konsolenspiele die manchmal ruckeln.

Gasthaus

2006-05-03, 01:00:54

@Coda
Um mich vielleich ein wenig besser einschätzen zu können.Mein Grossteil an technischen Verständniss habe ich hier in 1,5Jahren im 3DCenter gelernt.

Doch mein Erfahrungsschatz übertrifft dies bei weitem.Also nicht böse sein wenn ich es nicht immer richtig ausdrücke.Dazu gibts ja euch.
Tombman erzählich ich besser auch nichts über SLI-nur hat er im Gegensatz zu mir und zu seiner Erfahrung auch das nötige technische Verständnis um das zum Ausdruck zu bringen.

BTW.Durch meine damalige GehtNedWard(G)oldener(S)hit Ultra Freeze-Problematik habe ich auf einen Tip hin hier reingeschaut.Und siehe da,wenige Tage später tauchte hier die Erklärung dafür auf-zu scharfe V-Ram Timings.Seit dem bilde ich mich hier weiter:)Übrigens Arlt selbst war der Tipgeber,mensch haben die dumm geguckt als ich die auf den 3DC-Artikel hinwies und sie die Karte nach 2monatigen Hickhack dann doch zurücknahmen.

Gasthaus

2006-05-03, 01:12:12

Coda[/POST]']Evlt. liegt es daran dass das Spiel einfach scheiße programmiert oder (insbesondere) portiert ist? Dafür kann doch der PC nix.

Du willst doch nicht ernsthaft von deinem System auf sämtliche anderen schließen? :|
Es gibt durchaus auch Systeme (meins z.B. *hint*) wo sowas nicht vorkommt.

Übrigens gibts auch durchaus Konsolenspiele die manchmal ruckeln.

Also für so erwachsen darfst du mich ruhig halten.Habs auf fast allen meiner Kumpel-PCs gesehen,also GF3,GF4,9500Pro@9700,GF6,FX5900... und alle CPUs dies so gibt bishin zu einem Opteron.Über all das gleiche.Es muss wohl daran liegen das die Funksprüche nätürlich in der jeweiligen Situation geladen werden müssen,aber wies krieg ich das mit?Es ruckelt halt...Glaub mir mir entgeht kein Ruckeln,das wird mir oft zum Vorwurf:)gemacht weil ich immer was finde was andere garnicht sehen,bis ich sie darauf hinweise worauf man zu achten hat.

Klar gibts ne Menge Konsolenspiele die ruckeln(Ohhh meine schwarze Liste ist sehr lang)Doch HighEnd-Games ruckeln halt nicht.Auf dem PC ruckeln HighEnd-Games nicht immer weil die Programmierer zu doof sind,sondern weil irgendwas im PC nicht mit ein paar lächerlichen Funksprüchen zurande kommt.Kein Wunder gigt es keine Namco-Games auf PC

StefanV

2006-05-03, 01:25:26

Gasthaus[/POST]']Ein Beispiel:Ich glaub Starlancer hies dieser tolle und flüssige Weltraumshooter.Supergeile Mousesteurung und flinke Handhabung,alles wunderbar...solange KEINE Funksprüche gehen!Sobald einer der vielen pausenlosen und atmosphärischen Funksprüche aktiviert wird ZUCKELT es ganz kurz und somit die ganze Zeit.Sorry aber mich interessiert in letzter Instanz herzlich wenig,auf welchen technischen Grundlagen dies passiert.

Hö?!

Sag mal, hast du schonmal in Betracht gezogen, das dein PC-System ziemlicher Mist ist und du irgendwas verbockt haben könntest, an deinem System?!

Denn das, was du hier sagtest, konnte ich, als ich Starlancer spielte, nicht nachvollziehen.
Mag vielleicht daran gelegen haben, das mein System im besten Zustand war...

Gasthaus[/POST]']
Für mich ruckelt es einfach und nervt gewaltig!Auf Konsolen ist mir so ein SCHEISS noch nicht passiert,zumindest nicht bei einem so hochwertigen Game wie oben genannt.
1. Bei mir nicht.
2. Da gibts auch bei einigen Games geruckel...
Ich glaub bei NFSU hakts ab und an mal, aber auch bei anderen Games...

Coda

2006-05-03, 01:30:31

Gasthaus[/POST]']Klar gibts ne Menge Konsolenspiele die ruckeln(Ohhh meine schwarze Liste ist sehr lang)Doch HighEnd-Games ruckeln halt nicht.Auf dem PC ruckeln HighEnd-Games nicht immer weil die Programmierer zu doof sind,sondern weil irgendwas im PC nicht mit ein paar lächerlichen Funksprüchen zurande kommt.Kein Wunder gigt es keine Namco-Games auf PC
Das liegt mit ziemlicher Sicherheit an den Soundkarten-Treibern oder pfusch am Code vom Spiel. Das würde ich schon den einen oder den anderen Programmieren zuschreiben ;)

Gasthaus

2006-05-03, 01:39:09

StefanV[/POST]']Hö?!

Sag mal, hast du schonmal in Betracht gezogen, das dein PC-System ziemlicher Mist ist und du irgendwas verbockt haben könntest, an deinem System?!

Denn das, was du hier sagtest, konnte ich, als ich Starlancer spielte, nicht nachvollziehen.
Mag vielleicht daran gelegen haben, das mein System im besten Zustand war...

1. Bei mir nicht.
2. Da gibts auch bei einigen Games geruckel...
Ich glaub bei NFSU hakts ab und an mal, aber auch bei anderen Games...

Den Mist den du mir vorwirfst(übrigens ein A64@2,45/GF68U/1GigRam)erübrigt sich wenn du meine weiteren Posts liest.

Und über NFS diskutiere ich nicht-denn ich sprach auch von hochwerigen Games zu welchem NFSxyz devinitiv NIE gezählt hat,oder wie war das damals aufm 3DO mit dem ersten NFS überhaupt und RidgeRacer daneben auf der PS1?Das Ding(vor allem Underground)KACKT das es knallt.Lustig noch zu erwähnen das das erste Underground bis zum 50erNV-Treiber keine Nachladerucklerhatte,ab50 schon(dankeNV)
Zock mal ein paar SegaArcadeRacer oder noch besser F-Zero aufm GameCube,welches an die grenze des sichtbar machbaren in Sachen Geschwindigkeit unter 60Hz geht.Glaub mir dann relativiert sich auch deine Anicht was flüssig ist und was nicht.

StefanV

2006-05-03, 01:44:28

Gasthaus[/POST]']Den Mist den du mir vorwirfst(übrigens ein A64@2,45/GF68U/1GigRam)erübrigt sich wenn du meine weiteren Posts liest.
Nur weil man auf dem Papier ein tolles System hat, muss es nicht toll sein, insbesondere wenn du keine Angaben zur Tonausgabe machst :rolleyes:

Gasthaus[/POST]']Lustig noch zu erwähnen das das erste Underground bis zum 50erNV-Treiber keine Nachladerucklerhatte,ab50 schon(dankeNV)
Hm, hat dann vielleicht der nV Treiber schuld an dem, was du bei Starlancer beobachtet hast?! :uponder:

Gasthaus[/POST]']
Zock mal ein paar SegaArcadeRacer oder noch besser F-Zero aufm GameCube,welches an die grenze des sichtbar machbaren in Sachen Geschwindigkeit unter 60Hz geht.Glaub mir dann relativiert sich auch deine Anicht was flüssig ist und was nicht.
Nö, warum sollte ich das?!
Meine Meinung werd ich nicht ändern, auch wenn ich heut GT4 gezockt hab...

Gasthaus

2006-05-03, 01:45:02

Coda[/POST]']Das liegt mit ziemlicher Sicherheit an den Soundkarten-Treibern oder pfusch am Code vom Spiel. Das würde ich schon den einen oder den anderen Programmieren zuschreiben ;)

Ok,das mag so sein...Doch möcht ich einfach mal zur Abwechslung einschalten,installieren,kurz optimieren(also Res.Detail etc.was auf PC klar ein Vorteil ist!)und spielen.Doch irgendwie klappt das zu selten:(

FarCry unter HDR absolut geil!Doch wieso der Infrarotbug?Sorry Crytek das gehört bestraft,wenn man so ein wichtiges Game mit so"wichtigem"HDR ausstattet,so einen Fehler zu machen.

Ja die Treiber,siehe NFSU1....

Gasthaus

2006-05-03, 01:53:20

StefanV[/POST]']Nur weil man auf dem Papier ein tolles System hat, muss es nicht toll sein, insbesondere wenn du keine Angaben zur Tonausgabe machst :rolleyes:

Hm, hat dann vielleicht der nV Treiber schuld an dem, was du bei Starlancer beobachtet hast?! :uponder:

Nö, warum sollte ich das?!
Meine Meinung werd ich nicht ändern, auch wenn ich heut GT4 gezockt hab...

Nee und vielleicht doch ja,wie Coda schon sagte zwecks SoundK-Treiber.Habe selber ne popelige SBLive5.1 drinne.

Schade wegen deiner festgefahrenen Meinung,somit entgeht dir sehr viel.Und bitte sag jetzt nich NFS läuft so wie GT4,sonst lach ich und hol aths:)der sich reichlich mit GT4 befasst hat und frag ihn mal.

Gasthaus

2006-05-03, 02:03:22

Tu dir FZero trotzdem mal genauer an.So ne GC gibts mit MarioKart für 70Euro und FZero kostet auch son dreissiger.Und RGB-Kabel ned vergessen.Wenn du nicht gegen Rennspiele dieser Art allergisch bist,wird es dich sicher begeistern.Klar gibst bessere Grafik,doch das Ding ist wirklich perfekt rund.Und 29 verschiedene Gegner gibts in einem RacingGame selten:)Welche natürlich auch alle selber gefahren werden können.Wow und Pseudo-HDR(dynymisch!)gibts da auch schon(2003)

Gasthaus

2006-05-03, 02:13:21

Und der Multiplayermodus(4Player)erst,zwar gesplittet aber auf 72cm voll zockbar und KILLER.Der Storymodus hingegen ist eine innere Prüfung der Selbstbeherrschung.Aussedem ist das Ding eine wahre Meisterleistung in Sachen Loadingmanegement.Ich hör jetzt besser auf sonst missioniere ich noch die Welt auf FZ:)

sloth9

2006-05-03, 04:15:36

Was will der Konsolero uns sagen?
Hab auch was: Ich find AutoAim blöd, genau wie diese blöden, grellen, gern pinkfarbenen Zielpersonenmarkierungen a la Der Pate und GTA.
Und dieses Ominuscha 3 (oder wie auch immer), welches gerade auf PC veröffentlicht wurde, spielt sich wie Double Dragon.
Aber Konsolen sind schon toll.

Demirug

2006-05-03, 13:06:52

Coda[/POST]']Vista macht in der Tat einiges besser was das Grafiksubsystem angeht, was aber nicht heißt dass es unter XP unglaublich schrecklich wäre.

Aber verdammt dicht dran. Ein eingekauftes Provisorium das einfach nicht tot zu bekommen war und dabei auch noch mutiert ist.

Gasthaus

2006-05-06, 01:48:35

sloth9[/POST]']Was will der Konsolero uns sagen?
Hab auch was: Ich find AutoAim blöd, genau wie diese blöden, grellen, gern pinkfarbenen Zielpersonenmarkierungen a la Der Pate und GTA.
Und dieses Ominuscha 3 (oder wie auch immer), welches gerade auf PC veröffentlicht wurde, spielt sich wie Double Dragon.
Aber Konsolen sind schon toll.

Ich will das sagen was ich sagte:)

Hab nie was von PC is shit gesagt.Oder wie war das mit den vorteilhaften Optimierungen auf gegenüber festen Konsoleneinstellungen....
...und ja,Autoaiming ist ned so toll.Deshalb spielt man Egoshooter prinzipiell auf PC!PerfektDark(N64)ist die einzige Ausnahme.

Doch RacingGames gehören wohl eher in den Konsolenbereich,da hier nicht die Maus von Vorteil ist sondern eine konstante Framerate und ein gescheites Pad.Ach ja,wenn man einen PC-Racer doch mittels V-Sync auf 60FPS zwingt/schafft,verzögert sich die Steuereingabe.

Und nur von Onimusha,welches den Weg auf den PC geschaft hat,auszugehen ist auch nicht sonderlich toll.Hast wohl nicht viele(gute)Konsolenspiele(auf Konsolen)gesehen,sonst würdest du nie im Leben soetwas einseitiges und undifferenziertes von dir geben:)

Jede Plattform hat ihre Vorteile,sogar die Konsolenplattformen untereinander.

GameCube-MultiplayerFun und Nintendo-only Kracher(nicht alle)

X-Box1-ganz klar Racing,oder all die PC-Ruckler in 60FPS in 640,dafür auf 72cm.

PS2-3D-Prügler,Racing,JapanoRPGs

Also,wer da noch sagt er findet da nix(zusätzlich zu seinem PC)ist selber schuld.

Luke Undtrook

2008-03-22, 15:09:31

Das hat Bill Gates nie gesagt.
Und wer hat das dementiert: Bill Gates

Gast

2008-03-22, 15:23:19

Und wer hat das dementiert: Bill Gates

Weshalb holst du diesen alten Thread wieder hervor, speziell mit einem so nichtsnützigen Beitrag?

Demogod

2008-03-22, 15:31:09

Hab grad nicht alle Seiten hier gelesen aber nach meiner Erfahrung war der distributed.net client auf DOS und WINXP gleichschnell. Mag man nicht glauben, da DOS ja keine timeslices usw unterstützt aber kann ja nochmal jemand nachbenchen.

sputnik1969

2008-03-28, 19:57:40

- E/A Funktionen

Kann man leicht per Library erledigen.
Korrekt...

- Virtueller Speicher
- Paging

Das will man auf einer Konsole gar nicht haben.
Da wär ich mir nicht so sicher...

- Semaphoren zur Synchonisation von Prozessen
- Prozessverwaltung

Nur auf Multi-CPU/Core-Systemen interessant. Könnte man aber auch genau so gut selber machen.
Also im Prinzip bei allen aktuellen Systemen. Mehrere Prozessoren (nicht CPUs, früher eher Coprozessoren) sind doch schon lange "normal"...

Ich habe das Gefühl, du denkst Konsolen sind in der Computer-Steinzeit stecken geblieben.
Schon wegen der Tatsache, das der Hersteller sich vorbehalten will in Zukunft kleinere Änderungen an der Konsole vorzunehmen wird er immer ein Betriebssystem und APIs für die wichtigsten Funktionen mitliefern.
Wie stark das genutzt wird von den Spielen bzw. durch die Programmierer ist unterschiedlich. Früher eher weniger, heute jedoch fast immer. Alleine um auf der sicheren Seite zu sein (kompatiblität mit zukünftigen Versionen der Konsole) und um sich viel Aufwand zu ersparen (das Rad neu erfinden kostet Geld)