JLI Spieleprogrammierung

[PeaceKiller]

[The Lord of Programming]

[PeaceKiller]

PC Games Hardware z.B. sagt das. Und auf Linux System denke ich kann man das bestätigen
_________________
»If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine

[The Lord of Programming]

Auf der 64-Bit-Version von Linux?
Da ist es natürlich klar, dass der schneller läuft. Aber vorausichtlich wird die 64-Bit-Version von Windows ja noch einige Zeit dauern. Deshalb kann man P4 und A64 bisher auch nur auf 32-Bit-Basis vergleichen
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console

Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet...

[Sören]

So wie ich es eine Seite vorher getan habe. Aber 20-30% sind schonmal nicht zu verachten, finde ich.

[Christian Rousselle]

Ich kann mir nicht vorstellen, dass der Gewinn bei normalen Anwendungen überhaupt spürbar sein wird. Was hat man davon, dass die Register größer sind? Erstmal bedeutet das mehr Aufwand - mehr Verwaltung und zwei 32 Bit Zahlen zu multiplizieren ist weniger Aufwand als das gleiche mit zwei 64 Bit Zahlen zu machen. Es wird erst dann schneller werden, wenn man z.B. gleichzeitig zwei 32 Bit zahlen in den 64 Bit registern verarbeitet oder natürlich von dem größeren Adressraum profitiert - aber einfach so wird es nicht schneller....

C.

[The Lord of Programming]

Gestern habe ich gelesen, dass es jetzt schon eine Testversion des 64-Bit-WinXp zum Downloaden gibt
--> chip.de

Mich wundert auch, dass es dann schneller laufen soll.
Es klingt zwar wie eine Verdoppelung, aber die 32 hat ja eigentlich überhaupt nix mit der Geschwindigkeit zu tun.

PS: *sfz* jeder sagt irgendwie etwas anderes, was Intel HT vs. AMD 64 angeht...
Einmal heißt es, HT-Rulez, dann wieder, dass nicht-auf-HT-optimierte Anwendungen dann sowieso keinen Vorteil bringen
Dann heißt es 64-Bit-Rulez, dann aber wieder, dass das auch keinen besonders großen Geschwindigkeitsvorteil bringt/bringen kann.
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console

Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet...

[PeaceKiller]

Nja wenn ich genug Geld zusammen hab kauf ich mir ein Dual 64bit AMD, dann hab ich beide Vorteile in einem.

edit: 46 in 64 korrigiert.
_________________
»If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine

[AFE-GmdG]

[Sören]

[The Lord of Programming]

[AFE-GmdG]

Vielleicht hab ich mich ungünstig ausgedrückt. Sicherlich ist ein höherer Takt für schnellere Frames und eine schnelle Festplatte für schnellere Ladezeiten verantwortlich. Aber wenn man genug (addressierbaren) Speicher hat, kann man üppiger damit umgehen. Bei Memory Mapped Files wird einfach so getahn, als ob eine Datei Teil des Ramspeichers ist, dadurch sind Operationen mit den Daten einfacher zu programmieren.
In einem 32-Bit-Betriebssystem (wo man 4 GB addressieren kann) wird pro Prozess ein Addressraum eingerichtet, der 4 GB groß ist.
Der Bereich von 0 bis 2 Gigabyte ist dabei für die Anwendung selbst, bis 3 GB für DLL's und bis 4 GB für System-DLL's reserviert. Hat man also eine Anwendung, die 100 MB Speicher verbraucht (z.B. durch ein Array) zeigen die Pointer allesamt auf den Bereich unter 2 GB, eine Bibliotheksfunktion (z.B. printf) hat eine Funktionsadresse im Bereich zwischen zwei und drei GB und eine Systemfunktion wie CreateWindow() hat einen Funktionspointer zwischen 3 und 4 GB. Soviel zur Theorie.
Jetzt hat man für seine eigene Anwendung also ca. 1,5 Gigabyte freien Speicher, der je nach Fragmetierung des Adressraumes in mehr oder weniger große Teile zersplittert ist. Wenn man nun einen Addressraum von 700 MB benötigt, kann die Sache schnell mal knapp werden. Dabei ist es völlig unrelevant, ob wirklich 700 MB freier physikalischer Ram zur Verfügung stehen - die würden bei Memory Mapped Files eh nicht verwendet werden - wichtig ist nur, dass ein Addressraum dieser Größe vorhanden ist. Die Datei wird dann einfach in diesen Addressraum eingeblendet.
Der größere zur Verfügung stehende Adressraum ist in einem 64-Bit-System ist die größte Stärke. Ansonsten gibt es natürlich auch Nachteile:
Wie bereits von Christian erwähnt, müssen für eine einfache Operation jetzt zwei mal 64 Bits statt bisher zwei mal 32 Bits miteinander verknüpft werden. Diese Müssen ebenfalls aus dem Speicher gelesen und das Ergebnis muss wieder in denselben geschrieben werden - alles Dinge, die sich in einem 64-Bit-System Geschwindigkeitsmäßig halbieren gegenüber einem 32-Bit-System (bei gleichschneller Hardware)
So, ich hoffe nun hab ich alle Klarheiten beseitigt
AFE-GmdG
_________________

[The Lord of Programming]

[AFE-GmdG]