Woran scheitert die 64-Bit-Revolution bisher?

[Senior Sanchez]

Um was? Von wem? Von den 1Ds-Besitzern? =)

@Ectoplasma
Subjektiv oder? :|

Wahrscheinlich von allen, die viel RAM adressieren wollen, damit Photoshop nicht so lahmt.

[Gast]

Apple zeigt aufgrund ihrer enormen Überlegenheit wie so oft, wo der Hammer hängt ;D

OSX kann schon ewig 4GB anstatt 3,2 GB wie unter Windows/Linux 32Bit Programmen zur Verfügung stellen. Somit gibt es selbst bei 32Bit Programmen mehr Luft. OSX kann auch schon länger viel mehr Speicher verwalten und 64Bit Backend-Prozesse ausführen. Es ist schon lange ein "32Bit-64Bit-Zwitter"
Seit 10.5 ist das System auch vollständig ein 64Bit Betriebsystem - bis auf den Kernel. Es kann also auch 64 Bit GUI-Programme ausführen, die als Universal Binary daher kommen, d.h. 32Bit und 64Bit Code steckt in einer Binary. Der User bekommt davon nichts mit. Es gibt nur ein Betriebsystem. Keine seperate 64Bit und 32Bit Version. Man kann die Platte aus einem "64Bit" Mac an einen "32Bit-Mac" hängen und problemlos booten, als wäre es schon immer dessen Platte gewesen.
In 10.6 wird dann auch der Kernel endgültig vollständig 64Bit-fähig werden. Apple hat den Vorteil, dass neue Technologien von Entwicklern i.d.R. viel schneller aufgegriffen werden, als das unter Windows häufig der Fall ist. Desweiteren ist die installierte Mac-32Bit-Basis, die noch in Zukunft unterstützt wird nicht so sehr groß, wie unter Windows. Es ist eigentlich nur der Yonah und da hätte Apple vielleicht mit dem Switch ein wenig warten sollen. Der G4 fällt bestimmt raus. G5 war eh 64Bit und die Masse der aktuellen Macs hat halt Core 2 Duo.
Daher denke ich, wird ab 10.6 64Bit unter OSX recht schnell zur Normalität.
Wäre Apple bei PowerPC geblieben, dann wäre es vielleicht sogar möglich, ein 32bit-Plugin in einem 64bit-Programm auszuführen. ;)

Zwar ist das derzeit in OSX nicht vorgesehen...
Q: So now I'm wondering, can 64-bit unix kernel calls be mixed freely within a 32-bit Carbon GUI environment?

No, the Mac OS programming model does not support mixing 32-bit and 64-bit calls in the same process (regardless of whether you're using Carbon, Cocoa, or just BSD Unix calls).
http://www.carbondev.com/site/?page=64-bit+Carbon

... aber der PowerPC-Prozessor kann eben 32bit-Code im 64bit-Modus ausführen und umgekehrt:
The user-level instructions specific to the 64-bit PowerPC processors can be executed in both 32-bit and in 64-bit
computation mode. The user-level instructions implemented by the 32-bit PowerPC processor can also be executed in
either computation mode.
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/AB70A3470F9CC0E287256ECC006D6A54/$file/970-software.pdf

Es wäre also evtl. möglich gewesen, die Schnittstellen so zu gestalten, dass 32bit-Plugins in 64bit-Programmen ausgeführt werden können. Problem ist nur, dass Apple Mac OS X jetzt für x86 anbietet und die Schnittstellen sich in der x86- und der PowerPC-Version nicht unterscheiden sollen, denn bei Intel sind 32bit-Plugins nicht mit 64bit-Applikationen kompatibel, da im 64bit-Modus kein 32bit-Code ausgeführt werden kann. Um 32bit-Code auszuführen muss in den Compatibility-Modus geschaltet werden, wo der Prozessor sich dann benimmt, als wäre er ein 32bit-Prozessor. Dabei werden aber auch Register deaktiviert etc, sodass kein 64bit-Code mehr ausgeführt werden kann.
Daher müssen evtl. die Möglichkeiten, die das OS bietet beschränkt werden.!?

[(del)]

Wahrscheinlich von allen, die viel RAM adressieren wollen, damit Photoshop nicht so lahmt.Vielleicht solltest du doch mit XP und der Winversion versuchen? Die lahmt erst bei 25 Protokollobjekten, 8 Cachestufen und 10 Ebenen...

[Gast]

Zumindest nicht in dem Sinne, wie es bei PPC (siehe Quote) mit den Plugins möglich ist -> darauf bezogen.

Nein. Problem tritt dann z.B. auf wenn eine 64-Bit-Anwenung 32-Bit-Libraries aufrufen muss und umgekehrt.
Ja so ist das eigentlich auch unter OSX mit den UBs.

[PHuV]

Apple zeigt aufgrund ihrer enormen Überlegenheit wie so oft, wo der Hammer hängt ;D

OSX kann schon ewig 4GB anstatt 3,2 GB wie unter Windows/Linux 32Bit Programmen zur Verfügung stellen. Somit gibt es selbst bei 32Bit Programmen mehr Luft. OSX kann auch schon länger viel mehr Speicher verwalten und 64Bit Backend-Prozesse ausführen. Es ist schon lange ein "32Bit-64Bit-Zwitter"


Na ja, Du vergißt, daß Apple bereits EFI einsetzt, und nicht auf die olle alte Bios-Krücke angewiesen ist, was beim PC noch zu vielen Problemen führt (ich nenne da nur mal daß üble Hardware-Mapping). Die Bios-Ablösung ist bereits lange überfällig, keine Ahnung, warum das immer wieder rausgezögert wird. :(

[Gast]

Na ja, Du vergißt, daß Apple bereits EFI einsetzt, und nicht auf die olle alte Bios-Krücke angewiesen ist, was beim PC noch zu vielen Problemen führt (ich nenne da nur mal daß üble Hardware-Mapping). Die Bios-Ablösung ist bereits lange überfällig, keine Ahnung, warum das immer wieder rausgezögert wird. :(

Hat MSI nicht "letztens" EFI-Boards angekündigt?

[(del)]

Was soll denn eine 64bit CPU, ein 64bit OS und 64bit Anwendungen für Probleme mit einem BIOS (statt EFI) haben?

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=380378

[Gast]

Mal eine frage zu dem Portieren von 32Bit Apps zu 64Bit Apps. Wie problematisch ist das? Was für eine Rolle spielt da LLP64 und LP64?
Ein Gentoo-64Bit-User scheint sich sich ja offenbar bei OpenSource-Software über den GCC ein reines 64Bit System zu kompilieren.

[Exxtreme]

Wozu braucht Gothic3 ein eigenes "Dateisystem"? Und warum brauchen Oblivion und TwoWorlds keins? Einige dieser Typen sollten mal stream loading lernen. Nachladeruckler haben mit dem ausgehenden Speicher des 32bit Adressraumes selten etwas zu tun. Es gibt genug Gegenbeispiele.

Streaming ist bereits eine Krücke und keine tolle Technik. =) Es wäre nicht da wenn man direkt addressieren könnte. Und auch beim Streaming brauchst du eine Addressierungsmöglichkeit, die die 32-Bit überschreitet und musst das virtuell irgendwie zusammenbasteln. Auch das kostet Performance.

Mag sein, daß es aus Endbenutzersicht kaum einen Unterschied macht. aber das alles kostet viele Mannstunden.

[Gast]

Streaming nutzte damals sehr viel und genauso wie jetzt.
Mannstunden? Nicht jedes Rad muß nue erfunden werden. Allerdings kommt es mir so vor, als wenn einigen Studios noch nie was über Räder gehört hätten.

nd auch beim Streaming brauchst du eine Addressierungsmöglichkeit, die die 32-Bit überschreitet und musst das virtuell irgendwie zusammenbasteln.Interessant. Leider fehlen irgendwie gute Beispiele dafür. Es gibt zwar paar Spieleversionen die von sich behaupten "64bit" zu sein, die Entwickler scheinen jedoch die Chance, damit den Mainstream wenigstens per Mundpropaganda und Test 64bit schmackhafter zu machen, ständig zu verpassen.
Ist nunmal so. Vieles glänzt zwar...

BH

[Ectoplasma]

@Ectoplasma
Subjektiv oder? :|


Die vielen Rechtschreibfehler sind es sicherlich nicht :rolleyes:
Das macht es schwierig zu lesen.

[Gast]

Die vielen Rechtschreibfehler sind es sicherlich nicht :rolleyes:
Das macht es schwierig zu lesen.Ah das. Ja, man bemüht sich. Wenn aber sonst nichts ist... :rolleyes: Bis dann mal.

BH

[Ganon]

Ein Gentoo-64Bit-User scheint sich sich ja offenbar bei OpenSource-Software über den GCC ein reines 64Bit System zu kompilieren.

Standardmäßig kompiliert Gentoo ein 32bit/64bit-System. Man kann optional ein reines 64bit-System installieren, aber viel Spaß hat man damit nicht und Probleme gibt es auch. Flash funktioniert nicht, Java-Plugin funktioniert nicht, OpenOffice macht afaik auch zicken (oder ist gar nicht erhältlich), etc. pp.

Also Problemlos ist 64bit auf OpenSource garantiert nicht.

Ich denke da an die SegFaults von diversen Anwendungen (auch Konsolenanwendungen wie "dd") in der Anfangszeit. FireFox machte zicken, etc. pp.

Also selbst dort ist der x86_64 Umstieg noch nicht 100%ig komplett. Auch darf man nicht vergessen das ein 64bit-System nach meinen Erfahrungen deutlich mehr RAM benötigt, ohne großen Mehrnutzen.

Klar, 64bit ist wichtig, aber ALLES als 64bit auszuliefern ist einfach unnötig. Aber aufhalten wird man das nicht können...

[Coda]

Auch darf man nicht vergessen das ein 64bit-System nach meinen Erfahrungen deutlich mehr RAM benötigt, ohne großen Mehrnutzen.
Hast du da wirklich den reellen physikalischen Verbrauch angeschaut? Viel Sinn ergibt das nicht.

Das einzige was mehr Speicher verbraucht sind Pointer und das ist kaum die große Datenmenge bei Anwendungen.

[(del)]

Hast du da wirklich den reellen physikalischen Verbrauch angeschaut? Viel Sinn ergibt das nicht.Nein? Werden zB. die Systemdateien nur partiell in den Speicher geladen? Wenn man den "Datenträgerverbrauch" einer frischen Installation von Vista32 vs. Vista64 vergleicht... Oder die Größen von Vista64-SP1 und Vista32-SP1...

Da frag ich mich, auch wenns stimmen sollte, durch welchen Wunder zB. Vista64 reel physikalisch nicht merkbar mehr RAM vereinnahmen soll als Vista32.

Mit Anwendungen verhält es sich meistens nicht anders.

edit:
Aktueller MPC-HC 32bit 6.21MB, 64bit 6.92MB. Und das ist noch eher ein schmeichelhaftes Ergebnis. Und nur eine einzige Exe.

Bei Anwendungen die aus etlichen Exes und Dlls oder gar bei ganzen Betriebssystemen die aus aberhunderten Dateien bestehen ist der "Verschnitt" im RAM mehr als nur merkbar.

[Gast]

[QUOTE=BessereHälfte;662220
edit:
Aktueller MPC-HC 32bit 6.21MB, 64bit 6.92MB. Und das ist noch eher ein schmeichelhaftes Ergebnis. Und nur eine einzige Exe.
[/QUOTE]

du sollst auch nicht die größe der .exe ansehen, sondern den realen speicherverbrauch.

der ist beim MPC gerade mal 5% höher in der 64bit-version, beim internet-explorer 1%, also komplett vernachlässigbar.

andere programme fallen mir nicht ein die man vernünftig vergleichen kann, dass eine 64bit-anwendung oft mehr speicher brauchen kann ist ja gerade der große vorteil.

[Ganon]

Hast du da wirklich den reellen physikalischen Verbrauch angeschaut? Viel Sinn ergibt das nicht.

Also ich habe jetzt nur von Anwendungen. Z.B. NetBeans in einer 32bit JavaVM braucht bei meinem Projekt 250 MB. Bei einer 64bit JavaVM sind es schon 350MB oder mehr. Anzeige aus NetBeans direkt.

Genauso bei anderen Anwendungen (wenn auch nicht so extrem).

Zum System komplett (jetzt alles unter Linux gemeint), müssen ja einige Libs auch 2 mal im Speicher vorhanden sein, wenn du eine 32bit Anwendung startest.

Also meine Erfahrungen beziehen sich jetzt auf Linux. Unter Windows weiß ich es nicht.

[Coda]

Also ich habe jetzt nur von Anwendungen. Z.B. NetBeans in einer 32bit JavaVM braucht bei meinem Projekt 250 MB. Bei einer 64bit JavaVM sind es schon 350MB oder mehr. Anzeige aus NetBeans direkt.
Da kannst du dich nicht drauf verlassen. Das zeigt auch oft einfach vom System reservierte Pages an die gar nicht im Speicher liegen. In der Realität werden das nicht mal 5% mehr sein.

[(del)]

du sollst auch nicht die größe der .exe ansehen, sondern den realen speicherverbrauch.Ah die Exes und Dlls selbst müßen nicht in den RAM? Starte mal Vista64 mal Vista32 auf einem 1GB Rechner. Wirst schon sehen wo Codas "5%" bleiben. Auf der Strecke...

dass eine 64bit-anwendung oft mehr speicher brauchen kann ist ja gerade der große vorteil.Nicht "brauchen kann", sondern gebrauchen/verwaltren kann. Darüber war hier aber nicht die Rede.

[SentinelBorg]

Da fällt mir grad ein, die neuen Grakas blenden doch immer nur einen Teil ihres Speichers in den Adressraum ein, betreiben als eine Art Bank Switching damit eine 1 GiB Graka nicht gleich 1 GiB von den 4 GiB beim 32 Bit System belegt? Tun sie das eigentlich auch bei einem 64 Bit OS oder sparen sie es sich dort?

[Gast]

Tun sie das eigentlich auch bei einem 64 Bit OS oder sparen sie es sich dort?

beine 8800GT mit Vista64 braucht insgesamt ~320MiB an adressraum direkt.

[BlackBirdSR]

Ich bin gespannt, wann Hersteller Spiele auch als 64-Bit Version beilegen.
Leider kostet soetwas ein wenig Zeit und Aufwand (und wenn es nur das Testen ist), den sich kaum jemand leisten kann.

Wahrscheinlich muss jemand genug Mum haben einen Blockbuster nur für x64 zu bringen (siehe Vista only). Allerdings kann das wirklich noch eine Weile dauern.

Solange so viele x86 Systeme vorherrschen gibt es auch keinerlei richtigen Anreiz für 64-Bit Spiele. Man sieht ja z.B an Crysis (Farcry, Riddick, Shadow Ops) das ohne konkrete Ausrichtung auf die neuen Möglichkeiten kaum ein Unterschied erkennbar wird.

[Gast]

Ich bin gespannt, wann Hersteller Spiele auch als 64-Bit Version beilegen.
Leider kostet soetwas ein wenig Zeit und Aufwand (und wenn es nur das Testen ist), den sich kaum jemand leisten kann.


gibt es doch schon (ua Crysis, Hellgate London, ich glaub auch Unreal Turnament)

[DerRob]

Da fällt mir grad ein, die neuen Grakas blenden doch immer nur einen Teil ihres Speichers in den Adressraum ein, betreiben als eine Art Bank Switching damit eine 1 GiB Graka nicht gleich 1 GiB von den 4 GiB beim 32 Bit System belegt? Tun sie das eigentlich auch bei einem 64 Bit OS oder sparen sie es sich dort?
Meine 8800GT mit 1GB belegt bei XP x64 die Speicherbereiche

000A0000 - 000BFFFF
D0000000 - DFFFFFFF
F4000000 - F5FFFFFF
F6000000 - F6FFFFFF

Also 128 kiB + 256 MiB + 32 MiB + 16 MiB

Überhaupt sind die Speicherbereiche aller Geräte noch innerhalb der 32 bit Grenze, wahrscheinlich, damit 32 bit Anwendungen die immernoch problemlos ansteuern können.

[BlackBirdSR]

gibt es doch schon (ua Crysis, Hellgate London, ich glaub auch Unreal Turnament)

Ja, aber alles nur halbherzige Beigaben. Keine davon zeigt wirkliche Vorteile, oder gar Unterscheide (abgesehen davon, dass der Performanceverlust unter Vista x64 ausgeglichen wird, warum auch immer)

[del_4901]

(abgesehen davon, dass der Performanceverlust unter Vista x64 ausgeglichen wird, warum auch immer)
Meinst du nicht auch, dass es sich hierbei um einen Widerspruch handelt?

[Gast]

Überhaupt sind die Speicherbereiche aller Geräte noch innerhalb der 32 bit Grenze, wahrscheinlich, damit 32 bit Anwendungen die immernoch problemlos ansteuern können.

auch, in erster linie aber da die erweiterungskarten alle nur 32bittig sind und garkeine 64bit-adressen verstehen können.

[Gast]

Ja, aber alles nur halbherzige Beigaben. Keine davon zeigt wirkliche Vorteile, oder gar Unterscheide (abgesehen davon, dass der Performanceverlust unter Vista x64 ausgeglichen wird, warum auch immer)


stimmt doch nicht, crysis zeigt in 64bit mehr details (in der standardeinstellugn) und ist dabei sogar geringfügig schneller.

Hellgate London spricht in der 64bit-version extrem viel speicher an, wesentlich mehr als mit 32bit möglich wäre. in wie weit das ein vorteil ist wird bei diesem spiel aber wohl nur schwer zu benchen sein.

[BlackBirdSR]

Meinst du nicht auch, dass es sich hierbei um einen Widerspruch handelt?

Warum? Ich kann sowohl in Riddick (bei extrem niedrigem CPU-Takt), als auch in Crysis und UT2004 Performanceverluste der x86-Version feststellen.
Interessanterweise gleichen sich diese in den 64-Bit Versionen wieder auf das Niveau aus, das z.B XP64 erreicht.

@Gast:
Crysis ist wohl das einzige Beispiel, aber selbst hier ist der Unterschied so gering, dass sich sonst keiner den Aufwand machen würde. Und Hellgate mag auch viel Speicher ansprechen können, aber auch hier wieder kein spürbarer Unterschied. Es muss ja auch auf 32-Bit Systemen funktionieren, und das spiegelt sich halt im Design wieder.

[Gast]

Warum? Ich kann sowohl in Riddick (bei extrem niedrigem CPU-Takt), als auch in Crysis und UT2004 Performanceverluste der x86-Version feststellen.
Interessanterweise gleichen sich diese in den 64-Bit Versionen wieder auf das Niveau aus, das z.B XP64 erreicht.

auf einzelfälle trifft das wohl zu (UT2004 hab ich auch schon öfter gehört), aber beim großteil gibt es keine unterschiede mehr.

[BlackBirdSR]

auf einzelfälle trifft das wohl zu (UT2004 hab ich auch schon öfter gehört), aber beim großteil gibt es keine unterschiede mehr.

Mittelmäßiges System und min-fps betrachtet, tritt das sehr wohl noch auf. Aber wann hat jemand das letzte mal mit einem X2-4200 und einer X1900 Vistax64 getestet? ;)

[SentinelBorg]

auch, in erster linie aber da die erweiterungskarten alle nur 32bittig sind und garkeine 64bit-adressen verstehen können.
Wird das irgendwann mal geändert und wo liegt da genau die Limitierung?

[HOT]

Was soll der Quatsch mit dem Mehrverbrauch? Das ist so gut wie nichts. Die Daten, die ja den Löwenanteil des Speichers einnehmen, bleiben ja gleich.
Wird das irgendwann mal geändert und wo liegt da genau die Limitierung?
Genaugenommen stimmt die Aussage auch garnicht, es gibt also keine Limitierung. Solange es einen 64Bittigen Treiber gibt, ist die Karte auch voll 64Bit-fähig. Bei Grafikkarten ist es ja sogar so, dass der volle VRAM >512MB insbesondere bei SLI/CF nur mit 64Bit überhaupt voll genutzt werden kann. Die ROMs der Karten sind total egal, die werden zum booten des Systems gebraucht, sonst nix. Sobald Windows/Linux die Treiber läd sind alle Geräte 64bittig.
Mittelmäßiges System und min-fps betrachtet, tritt das sehr wohl noch auf. Aber wann hat jemand das letzte mal mit einem X2-4200 und einer X1900 Vistax64 getestet? ;)
Es kommt ja nichtmal auf den Speicherverbrauch an. Es kommt ganz salop darauf an, ob das Speichermanagement regelnd eingreifen muss, weil etwas nicht mehr in den Adressraum passt. Bei 64Bit muss es das nicht und genau ab da gibt es Vorteile für 64Bit, auch ggü. LAA-32Bit-Apps. Wie sehr würde ich mir eine 64Bit Version von ArmA wünschen, das würd das Spiel derart besser machen, weil sehr viel grössere Action bei grösserer Sichtweite möglich wär. Bei ArmA merkt man mit dem Editor die Begrenzungen der Sichtweite deutlich, wenn man versucht, viel Kriegsmaterial und Soldaten auf die Insel zu verfrachten.

[Gast]

Na ja, Du vergißt, daß Apple bereits EFI einsetzt, und nicht auf die olle alte Bios-Krücke angewiesen ist, was beim PC noch zu vielen Problemen führt (ich nenne da nur mal daß üble Hardware-Mapping). Die Bios-Ablösung ist bereits lange überfällig, keine Ahnung, warum das immer wieder rausgezögert wird. :(

Auch EFI beseitigt die Probleme nicht vollständig. Beim Starten ist jede x86 CPU erstmal ein 8086, der im Real Mode läuft. EFI läuft aber im 32Bit Protected Mode, d.h. auch EFI ist auf die x86 Firmware (das eigentliche Bios) angewiesen, um überhaupt gestartet zu werden. Das betrifft auch das Aufwachen aus dem Ruhezustand.

[Gast]

Wird das irgendwann mal geändert und wo liegt da genau die Limitierung?

bei x86-64 sicher nie, kompatibilität ist wesentlich wichtiger.

im grunde ist es auch überhaupt kein problem, es wird eben einfach der arbeitsspeicher umgemappt um platz für die karten zu schaffen.

[HOT]

Auch EFI beseitigt die Probleme nicht vollständig. Beim Starten ist jede x86 CPU erstmal ein 8086, der im Real Mode läuft. EFI läuft aber im 32Bit Protected Mode, d.h. auch EFI ist auf die x86 Firmware (das eigentliche Bios) angewiesen, um überhaupt gestartet zu werden. Das betrifft auch das Aufwachen aus dem Ruhezustand.
Was für Probleme? Es gibt keine Probleme. Das kann man sich auch herandichten. Ob BIOS oder EFI ist für x64 derart irrelevant.

[Tigerchen]

Hallo

Ich stelle mich in dieser Hinsicht nicht doof, ich bin es...;) Aber die naivsten Fragen ernten immer die interessantesten und lebhaftesten Diskussionen; so hoffentlich auch hier.

Es begann damit, dass doch vor einigen Jahren der AMD A64 als erste 64-bit CPU auf den Markt kam. Damals wie heute, in Zeiten tiefster, verfestigter 32-bit Ära, hieß es: das ist schon ein Vorbau in die Zukunft, die sich einst im PC Leben in 64bit abspielen werde. Damit einhergehen werden, sobald die "Rahmenbedingungen" erst stimmen werden, exponentielle Leistungszuwächse. Mit anderen Worten, dieselbe vor einem Jahr ausgemusterte A64 single CPU wird eines Tages sehr, sehr viel schneller sein als mein aktueller Core Duo E6750, wenn man dem A64 denn nur eine 64-bit Umgebung zur Verfügung stellen würde.

Nun sind wir die Jahre weiter, die Zukunft, aus damaliger Sicht, doch eingetreten, so dachte ich?? Es gibt doch jetzt die "Rahmenbedinungen"! Es gibt 64-bit Betriebssysteme, 64-bit Treiber! Warum also nicht den alten A64 in den Slot und ungeahnte Performancedimensionen sehen?

Die Praxis aber ist finster: statt Jubelmeldungen über Leistungsregionen ungeahten Ausmaßes bei Verwendung von Vista 64-bit, überschlagen sich umgekehrt aber vielmehr die Meldungen im Sinne von: man könne froh sein, wenn man nicht derbste Einbussen und Einbrüche hat - trotz sogar der Möglichkeit, nun 8GB RAM zu haben?

Warum, so die Überschrift, können wir heute noch nicht 64 bit erleben, mit dem vollen Leistungspotential? Oder war das alles stets Marketinglüge, dass astreines 64 bit im idealen Umfeld gar nicht schneller ist?

Ash-Zayr

Der Stammvater von IA-32 erschien bereits 1985. Der Intel 80386 bot erstmals den Adressraum und die Mechanismen die Windows bis heute nutzt.
Erst ab 1995 wurden die neuen Möglichkeiten von einer breiten Masse genutzt. Da erschien nämlich Windows 95. Und selbst das war nur ein 16/32 Bit Mischsystem. Die heilige Kuh der Kompatibilität durfte nicht geschlachtet werden. Und so konnten uralte DOS Programme bis hin zu Windows ME nativ ausgeführt werden.
Ein echtes 32 Bit Betriebssystem erschien aber erst mit Windows 2000/XP. Solange braucht es eben beim Umstieg auf eine grundsätzlich andere Architektur.

[Gast]

Der Stammvater von IA-32 erschien bereits 1985. Der Intel 80386 bot erstmals den Adressraum und die Mechanismen die Windows bis heute nutzt.
Erst ab 1995 wurden die neuen Möglichkeiten von einer breiten Masse genutzt. Da erschien nämlich Windows 95. Und selbst das war nur ein 16/32 Bit Mischsystem. Die heilige Kuh der Kompatibilität durfte nicht geschlachtet werden. Und so konnten uralte DOS Programme bis hin zu Windows ME nativ ausgeführt werden.
Ein echtes 32 Bit Betriebssystem erschien aber erst mit Windows 2000/XP. Solange braucht es eben beim Umstieg auf eine grundsätzlich andere Architektur.


Es gab aber auch schon voher 32 bit Systeme. Von os/2 ab 1991 ! , zu Linux 1992, zu diversen anderen Unix Urvätern und derivaten wie MacOS.

Hier konnten man die alten 16bit Zöpfe abschneiden, weil sie
A) nicht existierten (Linux)
B) willentlich ohne Rücksicht abgeschnitten worden (OS/2 (warp)/MacOS)

Es gibt ein Leben neben Windows und das war schon Dekaden voher 32bit.

[Exxtreme]

Streaming nutzte damals sehr viel und genauso wie jetzt.
Mannstunden? Nicht jedes Rad muß nue erfunden werden. Allerdings kommt es mir so vor, als wenn einigen Studios noch nie was über Räder gehört hätten.

Streaming ist eine Krücke um scheinbar mehr Content in den RAM reinzuquetschen als eigentlich reinpasst. Deshalb wird dynamisch Content rausgeschmissen und neuer nachgeladen. Es gibt noch viel mehr solcher Krücken wie z.B. das alte EMS oder PAE etc. Kostet aber alles Leistung weil hoher Verwaltungs- und Kopieraufwand. Dann hast du auch das Problem, daß du keine 64-bittigen Variablen direkt bearbeiten kannst. Sprich, du musst rumtricksen indem du sie z.B. aufteilst irgendwie in 2x 32 Bit (kann auch der Compiler für dich machen) etc. Was das für ein Aufwand ist, das brauche ich hoffentlich nicht zu erläutern. Oder versuch mal 2000 + 3000 korrekt zusammenzuaddieren wenn du maximal 999 speichern kannst. Da wirst du mehrere 999'er brauchen und die wirst du irgendwie verketten müssen. :D

Das ist z.B. eine Problematik unter vielen.

[Gast]

Deshalb wird dynamisch Content rausgeschmissen und neuer nachgeladen. Es gibt noch viel mehr solcher Krücken wie z.B. das alte EMS oder PAE etc.Und dein Ava gefällt mir wirklich besser als das neue Auto vom Nachbar. Oh man...

BH

[Tigerchen]

Es gab aber auch schon voher 32 bit Systeme. Von os/2 ab 1991 ! , zu Linux 1992, zu diversen anderen Unix Urvätern und derivaten wie MacOS.

Hier konnten man die alten 16bit Zöpfe abschneiden, weil sie
A) nicht existierten (Linux)
B) willentlich ohne Rücksicht abgeschnitten worden (OS/2 (warp)/MacOS)

Es gibt ein Leben neben Windows und das war schon Dekaden voher 32bit.

OS/2 war ein Nischenprodukt welches niemals den Massenmarkt erreichte. Genau wie all die anderen Nischenprodukte auf Unix Basis. Und auch Linux kam mehr als ein halbes Jahrzehnt nach dem i386. Den Massenmarkt bediente DOS. Das ließ sich genauso schlecht verdrängen wie das heutige 32 Bit Windows. Auch ich war sehr enttäuscht darüber daß Vista nicht nur als 64 Bit System erschien. Nun hoffe ich auf das nächste Windows und werde wohl so lange bei XP bleiben.

[HOT]

Windows7 erscheint zwar auch als 32Bit Version, aber es sollte klar sein, dass 64Bit bis dahin Standard ist. Dieser Trend zeichnet sich ja glücklicherweise ab, immer mehr Tipps in den Foren lauten "das liegt an deinem OS". Age of Conan ist daran z.B. nicht unschuldig :D.
Wer einen aktuellen Upper-Mainstream-Rechner will, kauft auch das Vista64 dabei und das sind die Markt-Zugpferde, die durch die ganzen Foren geistern. Immer mehr Leute begreifen, dass sie sich mit einem 32Bit OS einschränken. Wer will schon 4 GB RAM haben, von denen nur 3 maximal nutzbar sind und auch das nur in Ausnahmefällen (mehrere speicherintensive Apps gleichzeitig)?

[SgtTynis]

Erst ab 1995 wurden die neuen Möglichkeiten von einer breiten Masse genutzt. Da erschien nämlich Windows 95. Und selbst das war nur ein 16/32 Bit Mischsystem.


Für die Gamerfracktion wurde aber schon vorzeitig 32bit in Form der DosExtender (DOS/4GW) verwendet. Kann jetzt allerdings nicht sagen, ob es sich dabei technisch gesehen wirklich um eine 32bit Umgebung gehandelt hat.

[Exxtreme]

Für die Gamerfracktion wurde aber schon vorzeitig 32bit in Form der DosExtender (DOS/4GW) verwendet. Kann jetzt allerdings nicht sagen, ob es sich dabei technisch gesehen wirklich um eine 32bit Umgebung gehandelt hat.
Jein. DOS4GW war ein Protected Mode-Switcher für DOS. Man konnte damit auf bis zu 32 MB RAM zugreifen. Also viel mehr als im real Mode. OK, man kann das durchaus als einen 32-Bit-Extender ansehen. Zumindest partiell. ;)

[Tigerchen]

Für die Gamerfracktion wurde aber schon vorzeitig 32bit in Form der DosExtender (DOS/4GW) verwendet. Kann jetzt allerdings nicht sagen, ob es sich dabei technisch gesehen wirklich um eine 32bit Umgebung gehandelt hat.

Ja das stimmt. War aber nur eine Krücke wie PAE. Ich hatte auch nur eine handvoll Spiele die das nutzten.
Aber ist das das Thema? Tricks mit denen man mehr Adressraum nutzen konnte als der Adressbus eigentlich hergab waren schon beim Z80 um 1980 üblich. Das nannte man dann Bank-switching.

Was ich zum Thema sagen wollte ist daß es eben seine Zeit braucht bis eine richtige Umstellung kommt. Und das es schon in der Vergangenheit verdammt lange gedauert hat bis diese vollzogen war.

[Shink]

[COLOR="#000099"]Ich hatte auch nur eine handvoll Spiele die das nutzten.
Vielleicht OT aber: Das waren gar nicht mal so wenige.

[mapel110]

Vielleicht OT aber: Das waren gar nicht mal so wenige.
Fast alle Ego-Shooter zur damaligen Zeit.

Und man merkte, dass dieser Protected Mode Leistung kostet. Schon auf der Kommando-Zeile spürte man das bei diversen Befehlen. O_o

[EU-NEVER-EVER]

Hey Leute!

Bin neu im Forum und begrüße jeden!

Aber mal ne nebensächliche Frage:

Wie kommt man hier drauf, dass das 64Bit System scheitert.

Es fängt jetzt an... eine Revolution zu funken:eek:

Viele XP oder Vista Nutzer kaufen sich das 64Bit System.
Die Leute Kaufen sich viel mehr Ram da es einfach viel billiger ist wie nie zuvor! Das ist aber nur ein Argument warum man sich das BS kauft.

Hier mal eine kleine Liste der Programme die 64 unterstützen:

Foto-, Audio- & Videobearbeitung:
- AVI2DVD Converter
- Virtual Dub 1.6 (Freeware)
- DGDecode
- AviSynth
- Cakewalk Sonar (Shareware)
- The Panorama Factory 4 (Shareware)
- Windows Media Encoder

Audio- & Video-Player:
- Koolplaya

Audio- Videocodecs/Filter:
- FFDShow (!Net Framework 2 erforderkich!)
- Frauenhofer mp3 Encoder/Decoder (Personal-Free)
- Lame 3.97a
- Xvid

Brenn-Software etc.
- ISO Recorder Power Toy (Freeware)
- Roxio Easy Media Creator 8 (Shareware)

Laufzeit-Komponenten:
- Java (Sun) 5.0
- NET Framework 2.0

Anti-Virus:
- Sophos Anti-Virus (Shareware)
- Avast 4 (Free/Shareware)
- McAfee Enterprise 8.0 (Shareware)
- Symantec AntiVirus Corporate 10 (Shareware)
- NOD32 AntiVirus 2.5 (Shareware)
- Kaspersky Anti-Virus 6 (Shareware)
- AVG Anti-Virus 7 (Shareware)

Anti-Spyware/Adware-Tools:
- Windows Defender Beta

Browser:
- Internet Explorer 7 Beta
- Mozilla Firefox 1.5 (Vector64)
- Mozilla Firefox 1.6/3.0 Alpha (Mozilla)

E-Mail - Verwaltung:
- Mozilla Thunderbird 1.5 (Vector64)
- Mozilla Thunderbird 1.6/3.0 Alpha (Mozilla)

Firewall (Desktop): (Bitte keine Diskussion darüber)
- Ghost Security Suite
- GhostWall 1
- PeerGuardian 2
- Tiny Firewall 6 (Shareware)
- XP Firewall Control (Shareware)

System-Diagnose/Benchmark und Verwaltung:
- Everest Ultimate 2006 (Shareware)
- Sisoft Sandra 2007 (Shareware)
- Prime 95
- Process Explorer 10.x (Taskmanager - Ersatz)
- Regmon
- Fraps 2 (Shareware)
- Iometer
- OpenGL Extensions Viewer
- Cinebench
- Filemon
- BurnInTest Pro (Shareware)
- Performance Test (Shareware)
- Speed Commander 11 (Shareware)

Packer:
- Squeez 5
- 7z (zip) 4

Animation:
- Cinema 4D
- POV-Ray (Freeware)

Tweaking Tools:
- Tweak now! (Shareware)

Deskmodding:
- Cursor Editor
- Uxtheme Multi-Patcher 5
- Rainmeter 0.14 (Freeware)
- Style XP 64

Defragmentierung:
- Diskeeper 10
- O&O Defrag 8.0 (Shareware)
- Raxco Perfect Disk 7 (Shareware)

Laufwerksverwaltung/Emulatoren:
- Filedisk (virtuelles Laufwerk erstellen) (Shareware)

Datei-Verwaltung/Filesharing:
- Win2PDF
- ViewFolderSize
- SmartFTP (Shareware)
- Arctic Torrent
- Virtual ISO 1.5
- WinImage

Datensicherheit:
- Putty
- OpenSSL
- BestCrypt (Shareware)

Tools:
- Nvidia nTune
- WinFlash
- cFos 6 (Shareware)
- Sysinternals Autoruns 8.x
- Free PDF (PDF erzeugen)
- nLite 1.0
- HDCleaner 3 Beta
- Raspppoe 0.99 Beta (Freeware)
- Power Strip (Shareware)
- CommView 5 und andere... (Shareware)
- Orca
- Redmond
- Ghostscript
- X-Mouse Button Control 1.16
- UltraMon 2.6 (Shareware)
- StartupMonitor64 (Beta)
- Crystal CPUID 4.5 (Freeware)


Die Liste könnte weiter geführt werden...



ein 64-Bit Windows bringt natürlich nur dann nennenswerte Performance-Vorteile, wenn man auch 64-Bit Anwendungen darauf verwendest. (Vergleichbar ist das ungefähr mit dem Umstieg von 16-Bit auf 32-Bit-Anwendungen damals, als Win95 auf den Markt kam.)

MFG
EU-NEVER-EVER:|

[Shink]

Ein 64Bit-Browser bringt nur was wenn man damit die meisten Seiten ansehen kann die das 32Bit-Pendant zustande bringt.
Dank der weiten Verbreitung von Flash geht das leider nicht.

Crystal CPUID, nLite, Putty, OpenSSL und CursorEditor gibt es als 64Bit Version?
Ich würde mal sagen der größte Unterschied den man dort mitbekommt ist die gestiegene Binary-Größe.

[PatkIllA]

Und man merkte, dass dieser Protected Mode Leistung kostet. Schon auf der Kommando-Zeile spürte man das bei diversen Befehlen. O_oHö? Wo hattest du da einen Vergleich. Da wird am Anfang halt ein paar Sachen geladen, während der die alte Anwendung schon fertig war.

[mapel110]

Wenn man diesen EMM386-Treiber geladen hat, ging das doch auch nur im protected mode und dann wurde alles langsamer als im real mode.
Hat man wunderbar bei Games gemerkt, die dann EMS-Speicher wollten anstatt XMS.

[EU-NEVER-EVER]

Ein 64Bit-Browser bringt nur was wenn man damit die meisten Seiten ansehen kann die das 32Bit-Pendant zustande bringt.
Dank der weiten Verbreitung von Flash geht das leider nicht.

Crystal CPUID, nLite, Putty, OpenSSL und CursorEditor gibt es als 64Bit Version?
Ich würde mal sagen der größte Unterschied den man dort mitbekommt ist die gestiegene Binary-Größe.

So ist es alle Programme die ich gepostet habe sind 64bit fähig.
Naja und jedes 64Bit-Programm braucht mehr Speicher als sein 32Bit-Pendant aber was hat das mit Flash zu tun:|

[DerRob]

So ist es alle Programme die ich gepostet habe sind 64bit fähig.
Naja und jedes 64Bit-Programm braucht mehr Speicher als sein 32Bit-Pendant aber was hat das mit Flash zu tun:|
von flash gibts wohl (noch) keine 64bit-version, also muss der 64bit-browser ohne flash auskommen -> viele internet-seiten sind damit also nicht benutzbar.

[Gast]

Flash gibts noch? nicht als 64bit Version.

[BlackBirdSR]

So ist es alle Programme die ich gepostet habe sind 64bit fähig.


Du sagst es: fähig
Der Großteil davon Systemtools und Komponenten die ins System eingreifen. Die müssen oft schon aus Funktionsgründen 64Bit unterstützen.

Andere sind 64Bittig, wären sie es nicht würds auch keine Sau interessieren (Browser, Mail, Brennprogramme etc)
Die Anwendungen, die einen User zum Umstieg überreden könnten sind extrem in der Minderheit.

Ich bin auch für 64Bit-Anwendungen wo möglich und nötig. Aber man muss leider eingestehen, dass der Umstieg nicht nach dem Motto: "Viva la Revolution", sondern "langsam vollzieht sich die Evolution" abläuft.

[Shink]

Flash gibts noch? nicht als 64bit Version.
Genau. Flash gibt es nun schon seit 2005 noch? nicht als 64Bit Version (war anfangs eher ein Thema für die Linux-Welt in der es bald 64Bit Distros gab).
Und ein 32Bit Flash-Plugin kann man leider nicht zusammen mit einem 64Bit-Browser verwenden.

Es gäbe noch Gnash aber naja, irgendwie funktioniert das noch? nicht soo toll:
http://de.wikipedia.org/wiki/Gnash

Die wirklich interessanten 64Bit-Anwendungen imo:
- SQL Server
- Java JRE (wegen Serveranwendungen die in Java geschrieben wurden)
- Studio-Anwendungen, IDEs u.ä.

[EU-NEVER-EVER]

Du sagst es: fähig
Der Großteil davon Systemtools und Komponenten die ins System eingreifen. Die müssen oft schon aus Funktionsgründen 64Bit unterstützen.

Andere sind 64Bittig, wären sie es nicht würds auch keine Sau interessieren (Browser, Mail, Brennprogramme etc)
Die Anwendungen, die einen User zum Umstieg überreden könnten sind extrem in der Minderheit.

Ich bin auch für 64Bit-Anwendungen wo möglich und nötig. Aber man muss leider eingestehen, dass der Umstieg nicht nach dem Motto: "Viva la Revolution", sondern "langsam vollzieht sich die Evolution" abläuft.


Die Menschliche Evolution war aúch nicht besonders schnell. Tausende Jahre hat es gedauert bis wir vor einem PC sitzten konnte. Warten wir ab. Ich denke spätestens in einem Jahr, wenn die Kinderkrankheiten von Vista entgültig erloschen sind oder eben minimiert wurden sind, werden sich mehrere Käufer finden. Vergessen wir nicht das XP auch am anfang nicht beliebt war, und dann sich doch rausstellte das XP stabiler als win 2000 ist. Auch Flash wird sich daran setzten und eine 64Bit version erstellen. Doch warm jetzt Geld ausgeben solange die KUnden zufrieden sind und 32bit nutzen. Einfach abwarten und Tee trinken. ;)

Edit: Das XP 64 bit eigentlich eine Betaversion ist.. die immer weiter entwickelt wird.. deswegen würde ich nur empfelen Vista 64 bit kaufen, so mache ich es auch.. dann hat man einen neues OS und gleich einen funktinierende Deutsch version... und nur mal so ich habe mir einen neuen rechner bauen lassen und dafür hab ich 1.296€ ausgegeben.. Oder freunde

[BlackBirdSR]

Die Menschliche Evolution war aúch nicht besonders schnell. Tausende Jahre hat es gedauert bis wir vor einem PC sitzten konnte. Warten wir ab. Ich denke spätestens in einem Jahr, wenn die Kinderkrankheiten von Vista entgültig erloschen sind oder eben minimiert wurden sind, werden sich mehrere Käufer finden. Vergessen wir nicht das XP auch am anfang nicht beliebt war, und dann sich doch rausstellte das XP stabiler als win 2000 ist. Auch Flash wird sich daran setzten und eine 64Bit version erstellen. Doch warm jetzt Geld ausgeben solange die KUnden zufrieden sind und 32bit nutzen. Einfach abwarten und Tee trinken. ;)

Edit: Das XP 64 bit eigentlich eine Betaversion ist.. die immer weiter entwickelt wird.. deswegen würde ich nur empfelen Vista 64 bit kaufen, so mache ich es auch.. dann hat man einen neues OS und gleich einen funktinierende Deutsch version... und nur mal so ich habe mir einen neuen rechner bauen lassen und dafür hab ich 1.296€ ausgegeben.. Oder freunde

Was hat das mit dem Mensch zu tun? Mir ist schon klar wie Entwicklung funktioniert, exponentielle Kurven und so. Aber:

1. Ist es noch für lange Zeit recht egal ob sich Vista x64 besser verkauft. Programme die 64Bit wirklich nötig haben nutzen es jetzt schon, und sind meist nur für professionelle Anwender interessant. Alles andere, insbesondere Spiele muss für sehr sehr lange Zeit noch auf "Rückständige" Rücksicht nehmen.

2. Ist XP x64 das momentan beste x64-OS für Windowsandwendungen. Schneller als Vista, genügsamer als Vista, billiger als Vista (gelobt seist du 180 Tage Trial) und weit weniger Kompatibilitätsprobleme mit Anwendungen. Wer nicht gerade zufällig einen Treiber nicht bekommt (vIDE z.B), der hat mit XP x64 die noch bessere Entwicklungsplatform.

3. Flash wird gar nichts tun! Mal sehen was Adobe tut. Seit Jahren anscheinend ziemlich wenig. Überhaupt haben gerade gewinnorientierte Unternehmen anscheinend gar keine Zeit und Leute um 64Bit Versionen auf den Markt zu bringen...

[Coda]

Und man merkte, dass dieser Protected Mode Leistung kostet. Schon auf der Kommando-Zeile spürte man das bei diversen Befehlen. O_o
Das ist so direkt sicher nicht spürbar. Das einzige was beim Protected-Mode Leistung kostet sind TLB-Misses.

Ich vermute das was du da bemerkt hast ist der Wechsel in den Protected-Mode und zurück. Das ist nämlich wirklich je nachdem wie man es macht wirklich lahm.

Wenn man diesen EMM386-Treiber geladen hat, ging das doch auch nur im protected mode und dann wurde alles langsamer als im real mode.
Hat man wunderbar bei Games gemerkt, die dann EMS-Speicher wollten anstatt XMS.
Moment mal. EMS bedeutet, dass man Paging benutzt und die Speicherteile >1MiB in <1MiB eingeblendet hat. XMS funktioniert soweit ich weiß so ähnlich. Das hat beides nicht direkt was mit dem Protected Mode zu tun. Bitte nicht verwechseln.

Die Leistungsverluste durch TLB-Misses sind wirklich sehr gering.

[L.ED]

Dem Stimme ich zu, auch bezüglich xp 64Bit ;)

Und weil es irgendwo hier mit auch noch knapp rein passt (?), wollte dann gleich mal eine Frage dann noch los werden, die aktuell brennt und wo spontan auf die schnelle nicht so fündig werde.

Weiß einer ob die Grafiktabletts von Aipek oder Wacom, einfach so erkannt werden oder Funktionieren diese Dinge unter z.b. xp 64Bit nicht?

Bei neueren steht zu mindestens mal was von Vista Unterstützung aber nicht ob das auch die 64Bit Version mit einschließt (da muss man ja leider ganz allgemein Vorsichtig sein, selbst bei Teuren Produkten von Randsparten)?

[Exxtreme]

Wenn man diesen EMM386-Treiber geladen hat, ging das doch auch nur im protected mode und dann wurde alles langsamer als im real mode.
Hat man wunderbar bei Games gemerkt, die dann EMS-Speicher wollten anstatt XMS.
Ne, ich glaube, du verwechselst da was. :D

Was lahm war war XMS-Speicher. Um auf den zugreifen zu können wurde die CPU in den Protected Mode versetzt und irgendwannmal wieder zurück. Dummerweise musste man jedesmal die CPU komplett resetten was eben diese Trägheit auslöste.

Emm386 nutzte wiederum den XMS-Speicher um EMS-Speicher zu simulieren. Deshalb musste man immer himem.sys vor emm.exe laden sonst ging das nicht. Himem.sys war der XMS-Treiber.

Aus dem Grund war emm386 scheinbar immer so lahm. Zum dauernden CPU-Resetten durch die XMS-Zugriffe kam noch simuliertes Paging von EMS hinzu.

[Gast]

ein 64-Bit Windows bringt natürlich nur dann nennenswerte Performance-Vorteile, wenn man auch 64-Bit Anwendungen darauf verwendest.Ich bezeichne das als falsch. Windows bringt in 64bit schonmal garkeine Leistungsvorteile. Das bekommen bis jetzt nur 64bit Anwendungen hin, wenn sie den entsprechenden Untetbau vorfinden. Das zur Klugscheißerei.

Falls du das aber soweiso so gemeint hast, dann müßen diese 64bit Anwendungen, die ja nicht besonders schwer in der Erstellung sind, auch einen NUTZEN aus 64bit ziehen können.

Das tut 7-zip und das tut POV-Ray. Für 3/4 der Anwendungen die du aufgezählt hast spielen 64bit überhaupt keine Rolle. Es gibt sie höhstens in einer 64bit Version, damit sie mit einem Windows64 überhaupt reibungslos funktionieren können. Die zusätzlichen 64bit bzw. auf 48bit erweiterter Adressraum sind für sie aber sonst weitgehend unbedeutend.

[Shink]

Die zusätzlichen 64bit bzw. auf 48bit erweiterter Adressraum sind für sie aber sonst weitgehend unbedeutend.
Stimmt natürlich. Aber gibt es nicht in x86-64 zusätzliche Register, die bei für diese Prozessoren kompillierten Programmen einen Geschwindigkeitsvorteil bringen können?

Daneben finde ich dass es für die Zukunft schon Vorteile für 64Bit-Browser gibt: Wer weiß wie speicherhungrig zukünftige Videocodecs sind und wie hoch die zukünftige Durchschnittsauflösung:wink:

[mekakic]

2. Ist XP x64 das momentan beste x64-OS für Windowsandwendungen. Schneller als Vista, genügsamer als Vista, billiger als Vista (gelobt seist du 180 Tage Trial) und weit weniger Kompatibilitätsprobleme mit Anwendungen. Wer nicht gerade zufällig einen Treiber nicht bekommt (vIDE z.B), der hat mit XP x64 die noch bessere Entwicklungsplatform.Ack, benutze es ebenfalls und bin wirklich sehr glücklich damit.

3. Flash wird gar nichts tun! Mal sehen was Adobe tut. Seit Jahren anscheinend ziemlich wenig. Überhaupt haben gerade gewinnorientierte Unternehmen anscheinend gar keine Zeit und Leute um 64Bit Versionen auf den Markt zu bringen...Wenn man vernünftig entwickelt hat, ist die Wahrscheinlichkeit relativ gut, daß dies vielleicht der Aufwand eines Tages ist; ich meine Flash ist immerhin nicht Photoshop.

[HOT]

So ist es alle Programme die ich gepostet habe sind 64bit fähig.
Naja und jedes 64Bit-Programm braucht mehr Speicher als sein 32Bit-Pendant aber was hat das mit Flash zu tun:|
Die meisten Programme in deiner Liste sind blöderweise 32Bit Programme (einige mit LAA-Unterstützung). Zudem stellt eigentlich keiner die Notwendigkeit von 64Bit in Frage. Das ist doof ausgrdrückt im Thread-Titel.
Adobe hat übrigens keine 64Bit Version von Flash, sonst wäre ein 64Bit Browser machbar. Adobe hat sich in Sachen 64Bit-Entwicklung sowieso nicht mit Ruhm bekleckert.


PS/OT: Welche Organisation sichert besser Frieden als die EU? Da fällt mir keine ein... Wirtschaftliche Abhängigkeit ist der Friedensgarant schlechthin. Hauptsache man protestiert gegen irgendwas, egal, wie sinnlos das auch sein mag...

[Baalzamon]

[...]
Weiß einer ob die Grafiktabletts von Aipek oder Wacom, einfach so erkannt werden oder Funktionieren diese Dinge unter z.b. xp 64Bit nicht?
[...]
Das Wacom Grafiktablet meiner Freundin läuft ohne Probleme auf XP x64. Ich bin mir jetzt nicht mher sicher, ob ich einen Treiber installiert habe, oder ob das über das Windows-update mitkam... Auf jeden Fall läuft es, genauso wie die beiligende Tool-Software. :up:

[Shink]

PS/OT: Welche Organisation sichert besser Frieden als die EU? Da fällt mir keine ein... Wirtschaftliche Abhängigkeit ist der Friedensgarant schlechthin. Hauptsache man protestiert gegen irgendwas, egal, wie sinnlos das auch sein mag...
War auch schon kurz davor mich dazu zu äußern aber naja...

Welches Problem es sein kann ein Produkt für 64 Bit zu kompilieren dass immerhin auf einige Plattformen portiert wurde ist mir nicht ganz klar.
Auch nicht wieso wir alle immer noch an Flash hängen und nicht auf was anderes umsteigen aber gut, ist anscheinend so.:rolleyes:

[BlackBirdSR]

Stimmt natürlich. Aber gibt es nicht in x86-64 zusätzliche Register, die bei für diese Prozessoren kompillierten Programmen einen Geschwindigkeitsvorteil bringen können?

Daneben finde ich dass es für die Zukunft schon Vorteile für 64Bit-Browser gibt: Wer weiß wie speicherhungrig zukünftige Videocodecs sind und wie hoch die zukünftige Durchschnittsauflösung:wink:

Natürlich gibt es die zusätzlichen Register. Nur wann spürst du die 5-10% Performancevorteil? Das ist glaube ich die wichtige Frage.

Die DVD oder BluRay wird dadurch in nero auch nicht schneller fertig. Die Zeiten wo Leute glauben, dass Internet durch SSE2 oder x64 170% schneller werden sind auch vorbei.
Defragmentieren wird auch nicht so limitieren ;)

Was wirklich profitiert sind Sachen wie 7zip oder paint.net. Allerdings auch hier wieder: spürt man den Unterschied so stark, dass man umsteigen muss? (und bei beiden ist er sehr wohl spürbar)
Die Gründe für 64Bit Software liegen noch lange nicht bei normalen Alltags-Programmen. Deshalb zieht sich die Sache so langsam hin.
Auf der anderen Seite brauchen gerade Hersteller von teuren und aufwändigen Programmen sehr lange für die Portierungen. Sitze hier gerade an GIS-Software, und x64 Versionen kommen erst 2010. Wie schön während ich 4GB an Luftbildern und Rasterdaten über den Bildschirm ruckeln sehe ;)

Das Problem ist, dass anders als der Umstieg von 286 auf 386, diesesmal keine sofort sichtbaren Änderungen vorhanden sind. Wir sind zwar hart an der Grenze, allerdings nicht so hart wie die 286 damals. Auch stellt sich die Frage, inwiefern wir für die breite Masse an Software jetzt unbedingt 64Bit-Integer-Operationen in einem Durchgang erleigen müssen, und die 32-Bit Version davon wirklich so limtiert hat?!.
64Bit x87 und SIMD gab es ja vorher schon, also kaum Unterschied hier.
Die wenigen x64 Beispiele zeigen leider auch, dass skalar-SSE2 nicht unbedingt viel ausrichtet. Wohl auch weil es vorher wo ganz anders limitiert.

Was bleibt denn dann noch? 4GB-Adressraum für LAA-Software, gigantischer Adressraum für 64Bit Software, und keine Chance das zu nutzen, wenn 32Bit User den gleichenFunktionsumfang bekommen sollen/müssen (vgl. Spiele, Photo-Tools, Systemtools).

Meine Meinung ist, dass wie so oft die Spiele den Katalysator darstellen. Sobald es hier nicht mehr anders geht (und wir sind kurz davor, siehe Supreme Commander, Gothic3, Age of Conan), kommt die Zeit von x64. Und dann plötzlich steigt auch der Rest der Industrie großflächig um (Programme für Firmen mal ausgenommen, die sind davon natürlich unabhängig.)

[Wuzel]

Natürlich gibt es die zusätzlichen Register. Nur wann spürst du die 5-10% Performancevorteil? Das ist glaube ich die wichtige Frage.

Die DVD oder BluRay wird dadurch in nero auch nicht schneller fertig. Die Zeiten wo Leute glauben, dass Internet durch SSE2 oder x64 170% schneller werden sind auch vorbei.
Defragmentieren wird auch nicht so limitieren ;)

Was wirklich profitiert sind Sachen wie 7zip oder paint.net. Allerdings auch hier wieder: spürt man den Unterschied so stark, dass man umsteigen muss? (und bei beiden ist er sehr wohl spürbar)
Die Gründe für 64Bit Software liegen noch lange nicht bei normalen Alltags-Programmen. Deshalb zieht sich die Sache so langsam hin.
Auf der anderen Seite brauchen gerade Hersteller von teuren und aufwändigen Programmen sehr lange für die Portierungen. Sitze hier gerade an GIS-Software, und x64 Versionen kommen erst 2010. Wie schön während ich 4GB an Luftbildern und Rasterdaten über den Bildschirm ruckeln sehe ;)

Das Problem ist, dass anders als der Umstieg von 286 auf 386, diesesmal keine sofort sichtbaren Änderungen vorhanden sind. Wir sind zwar hart an der Grenze, allerdings nicht so hart wie die 286 damals. Auch stellt sich die Frage, inwiefern wir für die breite Masse an Software jetzt unbedingt 64Bit-Integer-Operationen in einem Durchgang erleigen müssen, und die 32-Bit Version davon wirklich so limtiert hat?!.
64Bit x87 und SIMD gab es ja vorher schon, also kaum Unterschied hier.
Die wenigen x64 Beispiele zeigen leider auch, dass skalar-SSE2 nicht unbedingt viel ausrichtet. Wohl auch weil es vorher wo ganz anders limitiert.

Was bleibt denn dann noch? 4GB-Adressraum für LAA-Software, gigantischer Adressraum für 64Bit Software, und keine Chance das zu nutzen, wenn 32Bit User den gleichenFunktionsumfang bekommen sollen/müssen (vgl. Spiele, Photo-Tools, Systemtools).

Meine Meinung ist, dass wie so oft die Spiele den Katalysator darstellen. Sobald es hier nicht mehr anders geht (und wir sind kurz davor, siehe Supreme Commander, Gothic3, Age of Conan), kommt die Zeit von x64. Und dann plötzlich steigt auch der Rest der Industrie großflächig um (Programme für Firmen mal ausgenommen, die sind davon natürlich unabhängig.)

286'er am Ende wegen nicht vorhandener 32bit Fähigkeit?
Die meisten 386'er bekamen in ihrer Lebzeit kein Fetzen 32bit Code zum verarbeiten.
32bit setzte sich erst bei Windows95 breitflächig durch.
In bestimmten Feldern - wie z.B. Banken (OS2 :) ) oder Workstations, Server waren 32bit zwar verbreitet, aber das ist heute auch nicht viel anders.

64bit setzt sich dann erst durch, wenn unser 'geliebter' Monopolist ein 64bit only Consum System rausbringt.

[BlackBirdSR]

286'er am Ende wegen nicht vorhandener 32bit Fähigkeit?
Die meisten 386'er bekamen in ihrer Lebzeit kein Fetzen 32bit Code zum verarbeiten.
32bit setzte sich erst bei Windows95 breitflächig durch.


Stimmt schon. Man muss aber auch sehen, wie lange man 286 und 386 nebenher kaufen konnte. Und es ging auch nicht zwangsläufig um 32Bit-Code sondern die Speicherbarrieren. Wie heute auch mal wieder ;)

[(del)]

Wuzel was ist das für ein stinkfaules und unsinniges Fullquotting? :|

Die Situation ist nicht vergleichbar, weil sie nicht die gleiche ist. Das müßte erkennbar sein oder? MS hat keine extra 16bit und 32bit von Win95 rausgebracht. Mit Vista32 und Vista64 ist das aber so. Zum gleichen Preis. Deswegen fragen sich hier einige warum die "Revolution", also die Entscheidung der User und OEMs auf 64bit zu setzen, weitgehend ausbleibt.

Das ist das Thema des Threads. Und ich meine Blackbird hat das garnicht so abwegig analysiert.

Die Erklärung einiger bezüglich "Spiele" ist für mich aber noch nicht so 100% nachvollziehbar. Nur weil man für ein gesamtes Spiel zB. 6GB Content produziert hat, heißt das nicht, daß man es auch am Stück braucht. Ich hab bis jetzt noch keine Spiel gesehen die pro Level mehr als LAA nötig hätten. Sie müßten dann quasi "levelfrei" sein bzw. die KOMPLETTE Welt im Speicher halten. Die Tricks um das umzugehen sind alt und billig. Und sie stören wirklich kaum. Was soll ich mit den nur im Level8 auftauchenden Klamotten (im Speicher), während ich im Level2 bin?

Nichts was ich bis jetzt zu sehen bekam vermittelt das Gefüh, das momentane Geschehen und die Darstellung dessen hätte 6GB nötig.
Vielleicht ist mein Gedankengang aber zu einfach gedacht (?) Bis später mal.

p.s.:
Wie groß ist eigentlich HL2? Wo blieben da die durchgehenden Rufe nach 64bit? ;)

[PatkIllA]

Deswegen fragen sich hier einige warum die "Revolution", also die Entscheidung der User und OEMs auf 64bit zu setzen, weitgehend ausbleibt.Die allermeisten User wissen da überhaupt nichts von und OEMs scheuen sich vor dem Support, der durch die nicht 100%ige Kompatbilität entsteht.

[(del)]

@PatkIllA
Und schon haben wir die BEIDEN allerwichtigsten Punkte aufgezählt :)

[Exxtreme]

Die Erklärung einiger bezüglich "Spiele" ist für mich aber noch nicht so 100% nachvollziehbar. Nur weil man für ein gesamtes Spiel zB. 6GB Content produziert hat, heißt das nicht, daß man es auch am Stück braucht.
Doch, die brauchst du am Stück. Das ist es ja. Würde man das nicht am Stück brauchen dann könnte man sich den Aufwand auch sparen. Gothic 3 hat nicht nur 6 GB an gesamten Content sondern 6 GB, die es am Stück braucht. Und die kannst du eben nicht komplett ansprechen. Hast also die Wahl: Entweder murksen und tricksen oder du drehst die Grafik und den Detailgrad oder die Sichtweite soweit runter, daß du unter der 3 GB-Grenze bleibst.

[(del)]

Doch, die brauchst du am Stück. Das ist es ja. Würde man das nicht am Stück brauchen dann könnte man sich den Aufwand auch sparen.Kannst du dazu mal etwas schreiben was man hinterher auch ruhigen Gewissens als "Erklärung" bezeichnen kann?

Gothic 3 hat nicht nur 6 GB an gesamten Content sondern 6 GB, die es am Stück braucht.Was a) kein Beweis für die Notwendigkeit ist und b) keine Begründung darstellt, da wiedermal nicht erklärt wird woraus sich das bei Gothic3 so zwingend ergibt und warum andere noch prima ohne auskommen.
G3 braucht 6GB am stück, wieviel Platz nimmt es auf der Platte ein?

Ich muß jetzt aber.

[BlackBirdSR]

Die Erklärung einiger bezüglich "Spiele" ist für mich aber noch nicht so 100% nachvollziehbar. Nur weil man für ein gesamtes Spiel zB. 6GB Content produziert hat, heißt das nicht, daß man es auch am Stück braucht. Ich hab bis jetzt noch keine Spiel gesehen die pro Level mehr als LAA nötig hätten.

Du brauchst nichtmal 6GB Content. Es reicht wenn du 512MB Adressraum am Stück brauchst. Und nun bekomm den mal wenn du schon 1GB belegt hast.

[Exxtreme]

Kannst du dazu mal etwas schreiben was man hinterher auch ruhigen Gewissens als "Erklärung" bezeichnen kann?

Was a) kein Beweis für die Notwendigkeit ist und b) keine Begründung darstellt, da wiedermal nicht erklärt wird woraus sich das bei Gothic3 so zwingend ergibt und warum andere noch prima ohne auskommen.
G3 braucht 6GB am stück, wieviel Platz nimmt es auf der Platte ein?

Ich muß jetzt aber.
Nochmal, wenn Gothic 3 nicht soviele Daten am Stück rumschieben müsste dann würden sich die Programmierer einfach den Aufwand sparen so ein Gemurkse überhaupt zu implementieren. Wozu ein virtuelles Dateisystem einbauen wenn man es gar nicht braucht? Eben. Bleiben eigentlich zwei "logische" Erklärungen übrig warum das eingebaut wurde:

1. Man braucht es
2. Die Programmierer sind so blöde, daß sie freiwillig Geld und Mannstunden verbrennen und Bugs riskieren um sich selbst zu beschäftigen.

So, welche Erklärung hälst du jetzt für wahrscheinlicher? 1 oder 2?

Und ein weiteres Problem ist, manchmal brauchst du viel RAM am Stück. Und das geht mit einem kleinen Adressraum u.U. nicht da er blöde belegt ist und Windows das nicht hergibt. Dann gibt es so schöne "Insufficient Memory"-Fehlermeldungen inkl. CtD.

Beide Problemchen schaffst du mit 64-Bit elegant aus der Welt. Keine komischen eigenen Speicherverwaltungen mehr weil man technische Limits umgehen muss.

[(del)]

Wuzel was ist das für ein stinkfaules und unsinniges Fullquotting? :|

Die Situation ist nicht vergleichbar, weil sie nicht die gleiche ist. Das müßte erkennbar sein oder? MS hat keine extra 16bit und 32bit von Win95 rausgebracht. Mit Vista32 und Vista64 ist das aber so. Zum gleichen Preis. Deswegen fragen sich hier einige warum die "Revolution", also die Entscheidung der User und OEMs auf 64bit zu setzen, weitgehend ausbleibt.

Das ist das Thema des Threads. Und ich meine Blackbird hat das garnicht so abwegig analysiert.

Die Erklärung einiger bezüglich "Spiele" ist für mich aber noch nicht so 100% nachvollziehbar. Nur weil man für ein gesamtes Spiel zB. 6GB Content produziert hat, heißt das nicht, daß man es auch am Stück braucht. Ich hab bis jetzt noch keine Spiel gesehen die pro Level mehr als LAA nötig hätten. Sie müßten dann quasi "levelfrei" sein bzw. die KOMPLETTE Welt im Speicher halten. Die Tricks um das umzugehen sind alt und billig. Und sie stören wirklich kaum. Was soll ich mit den nur im Level8 auftauchenden Klamotten (im Speicher), während ich im Level2 bin?

Nichts was ich bis jetzt zu sehen bekam vermittelt das Gefüh, das momentane Geschehen und die Darstellung dessen hätte 6GB nötig.
Vielleicht ist mein Gedankengang aber zu einfach gedacht (?) Bis später mal.

p.s.:
Wie groß ist eigentlich HL2? Wo blieben da die durchgehenden Rufe nach 64bit? ;)
seit 2005 gibt es HL2 64bit.

[EU-NEVER-EVER]

Was hat das mit dem Mensch zu tun? Mir ist schon klar wie Entwicklung funktioniert, exponentielle Kurven und so. Aber:

War eigentlich Ironie:wink:

1. Ist es noch für lange Zeit recht egal ob sich Vista x64 besser verkauft. Programme die 64Bit wirklich nötig haben nutzen es jetzt schon, und sind meist nur für professionelle Anwender interessant. Alles andere, insbesondere Spiele muss für sehr sehr lange Zeit noch auf "Rückständige" Rücksicht nehmen. Viele Spiele Brauchen heute einiges an Ram. Um Chrysis flüssig zu spielen wäre ein Rechner mit einigen Ram Riegeln entscheident im Vorteil. die 2GB für Crysis nützen nichts. Einen mit 4 oder 5GB wäre hier viel mehr angebracht. Da man von Ram ehe nicht viel genung haben kann ist das 64bit system normaler weise im Vorteil. Und da die meisten Anwendungen das 64 nutzen kann man gleich darauf ziehen

2. Ist XP x64 das momentan beste x64-OS für Windowsandwendungen. Schneller als Vista, genügsamer als Vista, billiger als Vista (gelobt seist du 180 Tage Trial) und weit weniger Kompatibilitätsprobleme mit Anwendungen. Wer nicht gerade zufällig einen Treiber nicht bekommt (vIDE z.B), der hat mit XP x64 die noch bessere Entwicklungsplatform. Stimme dir zu. Doch wird sich sicher auch ändern. Die Performance wird sich in 64bit Vista ändern und verbessern so das es wie auch das 32bit Vista irgendwann das XP zurück lassen wird.

3. Flash wird gar nichts tun! Mal sehen was Adobe tut. Seit Jahren anscheinend ziemlich wenig. Überhaupt haben gerade gewinnorientierte Unternehmen anscheinend gar keine Zeit und Leute um 64Bit Versionen auf den Markt zu bringen... So weit ich weis gibt es seit heute das Adobe9. Ist evtl 64Bit fähig!

[Wuzel]

Wuzel was ist das für ein stinkfaules und unsinniges Fullquotting? :|

Die Situation ist nicht vergleichbar, weil sie nicht die gleiche ist. Das müßte erkennbar sein oder? MS hat keine extra 16bit und 32bit von Win95 rausgebracht. Mit Vista32 und Vista64 ist das aber so. Zum gleichen Preis. Deswegen fragen sich hier einige warum die "Revolution", also die Entscheidung der User und OEMs auf 64bit zu setzen, weitgehend ausbleibt.

Das ist das Thema des Threads. Und ich meine Blackbird hat das garnicht so abwegig analysiert.

Die Erklärung einiger bezüglich "Spiele" ist für mich aber noch nicht so 100% nachvollziehbar. Nur weil man für ein gesamtes Spiel zB. 6GB Content produziert hat, heißt das nicht, daß man es auch am Stück braucht. Ich hab bis jetzt noch keine Spiel gesehen die pro Level mehr als LAA nötig hätten. Sie müßten dann quasi "levelfrei" sein bzw. die KOMPLETTE Welt im Speicher halten. Die Tricks um das umzugehen sind alt und billig. Und sie stören wirklich kaum. Was soll ich mit den nur im Level8 auftauchenden Klamotten (im Speicher), während ich im Level2 bin?

Nichts was ich bis jetzt zu sehen bekam vermittelt das Gefüh, das momentane Geschehen und die Darstellung dessen hätte 6GB nötig.
Vielleicht ist mein Gedankengang aber zu einfach gedacht (?) Bis später mal.

p.s.:
Wie groß ist eigentlich HL2? Wo blieben da die durchgehenden Rufe nach 64bit? ;)

Stinkfaules Quote? :rolleyes:

Wieviel Jahre und wieviel Realeases waren zwischen dem erscheinen des 386'ers und Windows95 vergangen?

Einfach mal im Kopf überfliegen und man merkt das die Situation garnicht so unähnlich war.

Der einzige Unterschied ist, das wir relativ früh extra Versionen unseres 'geliebten' Monopolisten bekamen.

[BlackBirdSR]

So weit ich weis gibt es seit heute das Adobe9. Ist evtl 64Bit fähig!

gibt einen "kleinen" Unterschied zwischen Flash und dem Acrobat.

[Gast]

Was wirklich profitiert sind Sachen wie 7zip oder paint.net. Allerdings auch hier wieder: spürt man den Unterschied so stark, dass man umsteigen muss? (und bei beiden ist er sehr wohl spürbar)

den unterschied spürt natürlich nicht der user, aber der programmierer, der nun vieles wesentlich einfacher erledigen kann. bis man als user den unterschied spüren würde gibt es keine 32bit-version mehr, also wird man keinen vergleich haben.

[Gast]

Etwas off topic:Was kommt in den Arbeitsspeicher,was in den Videospeicher der Grafikkarte bei einem Spiel??

[Gast]

Was kommt in den Arbeitsspeicher,was in den Videospeicher der Grafikkarte bei einem Spiel??

Arbeitsspeicher: diverse datenstrukturen die die spielwelt repräsentieren

VRAM: texturen, (statische) vertices, framebuffer, z-buffer etc.

[mekakic]

Wobei viele Dinge, die im VRAM liegen können, gleichzeitig auch im RAM liegen.

[Coda]

Seit D3D10 oder D3D9 auf Vista braucht man das eigentlich nicht mehr tun weil man Daten im VRAM nicht mehr verlieren kann.

[Gast]

http://www.unix.org/version2/whatsnew/lp64_wp.html

[Lokadamus]

Bleiben eigentlich zwei "logische" Erklärungen übrig warum das eingebaut wurde:

1. Man braucht es
2. Die Programmierer sind so blöde, daß sie freiwillig Geld und Mannstunden verbrennen und Bugs riskieren um sich selbst zu beschäftigen.

So, welche Erklärung hälst du jetzt für wahrscheinlicher? 1 oder 2?mmm...

Variante 2 ist für mich realistischer.

[Christian433]

Variante 2 hört sich zwar etwas "komisch" an, macht aber wahrscheinlich am meisten Sinn... :biggrin:

[Coda]

Ich hoffe das ist jetzt ironisch gemeint.

[Gast]

Ich hoffe das ist jetzt ironisch gemeint.ich hab schon so viele programme gesehen daß ich vor allem bei komerziellen eigentlich auch eher zu 2 tendiere.

[Coda]

Dann versteht ihr es nicht.

Wenn Gothic 3 ein reines 64-Bit-Programm gewesen wäre, dann wäre dieses virtuelle Dateisystem überhaupt nicht nötig gewesen weil man einfach die ganzen Daten über memory mapped files einblenden hätte können. Das ist überhaupt nur nötig weil man nicht genügend Adressen hat.

[lightning striker]

Meiner Meinung ist das Hauptproblem das Microsoft nochmal eine 32 bit Variante rausgebracht hat.
Wenn die nur Vista64bit rausgebracht hätten, dann würde mittlerweile auch alles auf 64bit setzen.

[Exxtreme]

mmm...

Variante 2 ist für mich realistischer.
Naja, mit 64 Bit hättest du den totalen Easy Mode um die 6 GB zu adressieren. Einfach direkt ansprechen und fertig. Mit 32 Bit wird's nen Krampf hoch drei.

[Lokadamus]

Dann versteht ihr es nicht.

Wenn Gothic 3 ein reines 64-Bit-Programm gewesen wäre, dann wäre dieses virtuelle Dateisystem überhaupt nicht nötig gewesen weil man einfach die ganzen Daten über memory mapped files einblenden hätte können. Das ist überhaupt nur nötig weil man nicht genügend Adressen hat.mmm...

Wieviel Content haben Farcry und Oblivion? Die müssen ja auch über 4GB kommen, ansonsten stimmt was anderes nicht.

[Coda]

Oblivion hat auch das gleiche Problem wie Gothic.

Far Cry benutzt Levels die in 2GiB passen. Sogar Crysis tut das noch.

[BlackBirdSR]

Supreme Commander geht es doch nicht anders. Erst über LAA gab es Linderung.

NeverwinterNights2 hat die Levels gleich in sehr kleine Abschnitte eingeteilt, erlaubt aber über den Editor größere Bereiche, und ist daher gleich von Beginn an mit gesetztem LAA-Flag ausgeliefert worden.

[Lokadamus]

Oblivion hat auch das gleiche Problem wie Gothic.

Far Cry benutzt Levels die in 2GiB passen. Sogar Crysis tut das noch.mmm...

Das ist das, was ich meine.
Einige benutzen die Resourcen ordentlich und andere tun so, als gäbe es mehr als genug und wundern sich, warum sie später einige Probleme haben.

[IceKillFX57]

Kann mir eig. jemand erklären warum das Vista 64Bit langsamer ist als 32Bit?
Allso ich merke den Leistungsverlust in Benchmarks oder in Games.
Woran liegt das?
an der miesen Optimierung?

[mapel110]

Konkrete Beispiele wären am besten.

[Gast]

Dann versteht ihr es nicht.Du das tue ich diesmal wirklich nicht. Laß mich mal kurz aufführen bitte.

Das Ruckeln bei G3 ist beim Nachladen wirklich unschön. Bei Oblivion viel weniger. Sie sollen aber beide die gleichen Probleme haben.

Bei einigen Spielen scheint LAA wunder zu bewirken (warum ist das kein Standard mittlerweile?!) bei einigen nur eine kleine Linderung. Komischerweise sehen die zweiten auch auf den zweiten Blick nicht besser als die ersten.

Warum muß ein Spiel, das 8GB "entpackten content" auf die Platte wirft, das gesamte Material schon im ersten Level verwalten? Sind die Level noch so riesig, man sieht doch nur einen Stück davon und wenn man mal weiter blickt, dann hat man - und braucht auch keine solchen - noch lange keine Texturen am Horizont mit dem Detailgrad der Texturen vor der Nase.

Und noch gleich eine Frage die man beim Antowrten bedenken könnte.
Warum versuchen die Studios Spiele in ener Art und auf eine Art zu entwickeln, zu presentieren und letztendlich zu verkaufen, die auf 32bit Systemen eigentlich nur lausig realisiert werden kann?
Wo sie wirklich rund erst dann laufen werden, wenn sie kaum noch selbst von der "Pyramide" zu bekommen sind und nur noch in irgendwelchen Compilations mit 5 Spielen auf einer BR gekauft werden können?

Ich wette so ein G3 wird sich 2010 auf Win7 64, SSDs und GT300/5870 wirklich wunderbar spielen lassen. Was hab ich aber davon als ein Idiot der sich sowas 2007 kauft?

[Gast]

Warum muß ein Spiel, das 8GB "entpackten content" auf die Platte wirft, das gesamte Material schon im ersten Level verwalten?Wobei das Verwalten eher so aussieht, als wenn die Engine am liebsten alle Orte auf einen Schlag im Speicher halten würde. Wozu ist sowas sinnvoll?

Die Entwickler sind ja auch gut drauf. Einerseites das Gejammer, Intel schmeißt sie ins kalte Wasser mit "friss oder stirb" mit den Multicores, andererseits hauen sie Spiele raus bei welchen "friss oder stirb" dem Käufer gilt. Und das ohne, daß man einfach nachvollziehen kann warum.
Naja. Race conditions aus dem Weg zu gehen scheint es eben schwieriger zu sein als für den User neue Hardware und 64bit OS mit 8GB zu kaufen und erstmal Treibermassaker zu veranstalten.

Die "Effizienz" mit welcher wir neue Entwicklungen auf dem Hardwaremakrt verfolgen und anschaffen sollen entspricht nicht im geringsten der Effizienz mit welcher Studios Spiele schreiben. Deswegen gelten, vom Thema Speicher mal ab, Sachen wie Bioshock als Perlen und heimsen das ganze Jahr über Auszeichnungen.

Weil eine kluge effiziente und durchdachte Programmierung leider keine Normalität, sondern etwas besonderes ist. Und solche Typen wollen mir erzählen ich brauche wegen der Sichtweite :| 64bit, weils nicht anders geht. Ja klar. In den letzten 2 Jahren bin ich eher der Meinung ich brauche keine 64bit, sondern den Quellcode und einen Debugger! :mad:
Crysis-patch 1.2 mit 361MB und über Raubkopien heulen. Ja die habens echt drauf. Was die erzählen stimmt auf jeden Fall :uup:

[IceKillFX57]

Crysis-patch 1.2 mit 361MB und über Raubkopien heulen. Ja die habens echt drauf. Was die erzählen stimmt auf jeden Fall :uup:

Das finde ich eig. noch ok... gab ja ein Spiel das released wurde und sogar ein tag danach ein Patch erschien mit ca. 3GB.
Das fand ich dan ganz schön heftig... müsste das Spiel "B.O.S" sein.

[Gast]

Das finde ich eig. noch ok... gab ja ein Spiel das released wurde und sogar ein tag danach ein Patch erschien mit ca. 3GB.
Das fand ich dan ganz schön heftig... müsste das Spiel "B.O.S" sein.Tja, soweit haben sie dich schon. Und viele anderen. Das muß abver nicht heißen, daß sie alle schon so eingelullt haben und daß sowas weiterhin Normalität sein muß.

Wunderbar finde ich auch, daß sobald du die Packung aufmachst, du damit meistens einen Aufkleber zerreißt mit einer Aufschrift die dir zu verstehen gibt, daß du hiermit mit dem Produkt so einverstanden bist wie er ist. Und eben nicht so wie er sein sollte. Alles normal. Alles schön. Alles wird gut.
Mußt dir halt nur Vista64 zulegen und 8GB reinstecken. Dann wird das in paar Monaten mit dem zweiten Patch schon rennen.

[(del)]

Das finde ich eig. noch ok... gab ja ein Spiel das released wurde und sogar ein tag danach ein Patch erschien mit ca. 3GB.
Das fand ich dan ganz schön heftig... müsste das Spiel "B.O.S" sein.Das finde ich überhaupt nciht heftig, weil ich nicht die Menge für so entscheidend sehe, sondern die Zeit.
Tag später heißt, man konnte BOS schon am nächsten Tag unbekümmert vom Anfang an bis zum Ende durchzocken. Eher ein "Positivfall" =) Obwohl, unbekümmert in heutigen Maßstäben :D Fürs BloodOfSahara und BlackOutSaigon hats imho trotzdem nicht gereicht (?) Besser war das.

[IceKillFX57]

Das finde ich überhaupt nciht heftig, weil ich nicht die Menge für so entscheidend sehe, sondern die Zeit.
Tag später heißt, man konnte BOS schon am nächsten Tag unbekümmert vom Anfang an bis zum Ende durchzocken. Eher ein "Positivfall" =) Obwohl, unbekümmert in heutigen Maßstäben :D Fürs BloodOfSahara und BlackOutSaigon hats imho trotzdem nicht gereicht (?) Besser war das.

naja... es war nicht direkt ein tag sondern eher vll. 1-2.
Das Problem war aber auch das jeder Spieler wieder von neu anfangen "muss".
Das kann ich ganz und garnicht leiden.
Meistens lege ich das Spiel dan zur seite und fasse es nie mehr an.
Ich habe keine Lust ein Spiel wieder von neu anfangen zu müssen wenn ich fast durch bin.
Und nochmal zur Größe... ich finde es doch schon ziemlich krass... da sieht man wieviel man falsch gemacht hat als laie.
Es war ja kein Balance Patch von ca. 10-20MB und kleinere Bugfixes sondern fast gleich das ganze Game.

[(del)]

Hast du schonmal was von Updates gehört die Spielstände nur zum Teil, wenn überhaupt, richtig konvertieren können und man erstmal einige Tricks und Aufwand im Spiel betreiben mußte um alles hinterher wieder so zu bekommen wie man es vorher hatte? Noch nie? Ich schon. Recht oft sogar ;)
Das wird jetzt aber alles langsam OT. Mal sehen wer und wann auf die Beiträge des tobenden Gastes antworten wird.

[BlackBirdSR]

Bei einigen Spielen scheint LAA wunder zu bewirken (warum ist das kein Standard mittlerweile?!)


Weil so ein Spiel auch auf einem System laufen muss, das keine 3 oder 4GB Adressraum zur Verfügung stellen kann. Ein 64Bit System kann das. Ein 32Bit System eben nur mit Anpassung der Bootkonfiguration. Das kannst du erstens keinem Gamer abverlangen, zweitens laufen weit nicht alle 32Bit Systeme damit stabil.


Und noch gleich eine Frage die man beim Antowrten bedenken könnte.
Warum versuchen die Studios Spiele in ener Art und auf eine Art zu entwickeln, zu presentieren und letztendlich zu verkaufen, die auf 32bit Systemen eigentlich nur lausig realisiert werden kann?
Wo sie wirklich rund erst dann laufen werden, wenn sie kaum noch selbst von der "Pyramide" zu bekommen sind und nur noch in irgendwelchen Compilations mit 5 Spielen auf einer BR gekauft werden können?

Ich wette so ein G3 wird sich 2010 auf Win7 64, SSDs und GT300/5870 wirklich wunderbar spielen lassen. Was hab ich aber davon als ein Idiot der sich sowas 2007 kauft?

Ist das nicht die falsche Frage?
Sollte die Frage nicht lauten, warum Spiele die dem normalen Entwicklungszyklus durchlaufen (schöner, größer, komplexer), plötzlich Probleme bekommen? Und was die Lösung dafür wäre? (64Bit)

[(del)]

Weil so ein Spiel auch auf einem System laufen muss, das keine 3 oder 4GB Adressraum zur Verfügung stellen kann.Laufen? Was stand da sonst so alles geschrieben? Man kann in den Fällen höhstens vom Starten sprechen. Laufen ist was anderes.

Ein 32Bit System eben nur mit Anpassung der Bootkonfiguration. Das kannst du erstens keinem Gamer abverlangen, zweitens laufen weit nicht alle 32Bit Systeme damit stabil.Und dann? Das kann ich jedem selbst überlassen. Oder läuft ein LAA Programm instabil auf einem 2GB System? Oder ist sowas heiden Arbeit für die Entwickler?
Grestorn hat sich sein komplettes G3 selbst in 30min gepatcht und das lief angeblich um Längen besser danach. Leute die es nicht gebacken bekommen müßen erstmal weniger schöne Texturen fahren. Scheint mir, Crysis nach, kein Riesendrama zu sein.

Die Gamer haben wir hier im Forum. Das kann ich denen nicht abverlangen? Oder wer ist "Gamer"? 0815 Zocker ist ein Gamer? Der sieht den Unterschied zwischen High und Veryhigh sowieso nicht. Oder es ist ihm egal.

Ist das nicht die falsche Frage?
Sollte die Frage nicht lauten, warum Spiele die dem normalen Entwicklungszyklus durchlaufen (schöner, größer, komplexer), plötzlich Probleme bekommen? Und was die Lösung dafür wäre? (64Bit)Nein, das ist nicht die falsche Frage gewesen. Ich kann kein Spiel für eine Platform auf die Art programmieren für welche sie nicht ausgelegt ist. Auf so eine Art, als wenn sie es wäre. Das ist ideenloses brute force wo kein brute force geht. Sprich: Es ist idiotisch.

[Exxtreme]

Wobei das Verwalten eher so aussieht, als wenn die Engine am liebsten alle Orte auf einen Schlag im Speicher halten würde. Wozu ist sowas sinnvoll?

Es geht nicht darum alles im Speicher halten zu wollen. Es geht darum benötigten Content eindeutig und einwandfrei lokalisieren und laden zu können. Und das klappt mit 32-Bit nicht mehr sobald deine Menge an Content die 2 (3) GB überschreitet. Sobald du diese Grenze überschreitest, ist tricksen angesagt. Dabei ist es völlig wurst wieviel Content du gleichzeitig brauchst.

Ich glaube, dir ist die Problematik gar nicht bewusst.

[(del)]

Hi Exxtreme. Schön daß du da bist.

Da hab ich auch so meine Problemmchen. Mein AIMP2 verwaltet über etliche Playlisten 10GB MP3. Bunt gemischt. Ich verstehe die Problematik mit dem Content auch nicht. Eine genauere Erklärung dafür, außer Feststellungen, daß es nötig ist und man sich der Problematik wohl nicht bewußt ist, gab es in diesem Thread leider noch nicht. Kommt das irgendwann?

edit:
Der Kernel hier verwaltet samt dem Dateisystem sogar hunderte Gigs auf der Platte. Und kann zB. auch 5GB Dateien verschieben. Schnell verschieben. Die beiden kommen irgendwie auch zurecht. Samt TotalCommander.
Der "lokalisiert" übrigens alles was ich auf der Platte habe. Und wenn ich im Ordner A nach einer Datei suche - weil ich mir sicher bin, daß sie da irgendwo steckt - dann läßt er Ordner B und C von der Suche aus. Das hat was...

Klar, ich schätze mal, das sind Äpfel und Birnen. Warum sie das sind, weiß ich aber noch nicht so genau. Es erklärt mir ja keiner ;)

Ok. Bis später mal. Ich sehe die Antwort wird sich bisschen hinziehen.

[BlackBirdSR]

Laufen? Was stand da sonst so alles geschrieben? Man kann in den Fällen höhstens vom Starten sprechen. Laufen ist was anderes.

Und dann? Das kann ich jedem selbst überlassen. Oder läuft ein LAA Programm instabil auf einem 2GB System? Oder ist sowas heiden Arbeit für die Entwickler?


Mit deinem Tonfall macht es mir keinen Spass. Nur so am Rande.

Was LAA betrifft: Vielleicht solltest du dir klar machen, dass LAA mit dem Hauptspeicher nichts zu tun hat. Ob die Sache instabil läuft liegt also nicht daran. Es liegt am System, den Treibern, den Programmen und den Devices. Das kann niemand abschätzen, und deshalb kann niemand verlangen, dass 3 oder 4GB Adressraum vorhanden sind. Darum kein LAA.

[Gast]

Vom "Verlangen" hast bis jetzt nur du geredet. Daß man es nicht "verlangen" kann ist übrigens schon deine zweite Antwort zum Thema LAA. Obwohl niemand außer dir das Thema im Kontext "Verlangen" in die Runde wirft.

Wir hatten jetzt 18 Seiten "Spaß". Ich dachte es wäre vielleicht endlich Zeit der Sache vernünftig und Punktgenau auf den Grund zu gehen. Ohne sich durch Gaga beirren zu lassen. Das nervt zuweilen. Wie das "Verlangen".
Man hakt genauer nach und bekommt nochmal die gleiche Antwort anders geschmückt. Entweder du verstehst auch nichts vom Spaß oder ich hab nicht den Humor für sowas ;)

Du brauchst mich übrigens über USERVA und andere Klötzchen nicht aufklären. Ich weiß nicht jede Antwort, aber ich weiß schon was und mit welchen Wortlaut ich frage.
Über Probleme mancher Treiber mit /3GB weiß ich bescheid. Obwohl der Schalter ursprünglich eben für Treiberentwickler gedacht war :frown: Warum sollten die aber eine besser Arbeit liefern als die Spieleprogrammierer? Eben.

Gute Nacht. BH

[BlackBirdSR]

Vom "Verlangen" hast bis jetzt nur du geredet. Daß man es nicht "verlangen" kann ist übrigens schon deine zweite Antwort zum Thema LAA. Obwohl niemand außer dir das Thema im Kontext "Verlangen" in die Runde wirft.



Jemand hat gefragt, ich habe spezifisch und genau darauf geantwortet. Ein System läuft potentiell instabiler wenn man den Adressraum auf 3GB erweitert. Und das ist der Grund warum eben niemand verlangen kann, dass der Adressraum auch zur Verfügung steht. Ergo kein LAA-Flag als Standard. Das war die erste Frage, und deine war die nach der Stabilität.
Und ich antworte so oft darauf wie es nötig ist.

Muss jemand vor mir etwas in die Runde werfen, damit ich es in den Mund nehmen darf? Wenn dich etwas nervt, steht es dir frei woanders zu posten und lass mich derweil weiter normal auf die Fragen anderer oder deiner posts antworten.

[Gast]

hier werden jetzt fragen beantwortet. das finde ich super und ich bin gespannt. die letzten 10 beiträge sind gespickt mit fragen.

man kann laa nicht verlangen. das wäre schonmal geklärt. nur zu. bitte weiter machen.

[Ganon]

Der Kernel hier verwaltet samt dem Dateisystem sogar hunderte Gigs auf der Platte. Und kann zB. auch 5GB Dateien verschieben. Schnell verschieben. Die beiden kommen irgendwie auch zurecht. Samt TotalCommander.

Du kannst eine 5GB Datei (unter Windows) aber auch nur unter NTFS verschieben, weil das ein 64bit Dateisystem ist, im Gegensatz zu FAT :D

[Exxtreme]

Hi Exxtreme. Schön daß du da bist.

Da hab ich auch so meine Problemmchen. Mein AIMP2 verwaltet über etliche Playlisten 10GB MP3. Bunt gemischt. Ich verstehe die Problematik mit dem Content auch nicht. Eine genauere Erklärung dafür, außer Feststellungen, daß es nötig ist und man sich der Problematik wohl nicht bewußt ist, gab es in diesem Thread leider noch nicht. Kommt das irgendwann?

Man nehme das Beispiel VFAT32. Mehr als 4 GB als Datei ist nicht drinne. Weil du mit 32 Bit nicht mehr adressieren kannst. Dabei ist es unerheblich ob du die 4 GB ganz am Stück oder einzelne Datensätze daraus brauchst. Es geht um das Ansprechen der Daten. Hast du aber 6 GB an Daten dann bekommst du ein Problem. Jetzt kannst du dir Workarounds überlegen, wie du damit umgehst.

[mekakic]

Verstehe es auch nicht so ganz, was würde dem entgegenstehen, wenn ich ein 2 GB Streaming Fenster habe, alles weitere ist in der Welt einfach über die Datei beschrieben. Wenn ich jetzt in einen Bereich komme, wo nicht alles nötige im Streaming Fenster brücksichtig ist, wird in der Weltbeschreibung nachgeschaut und die fraglichen Dateien in den Speicher geladen. So hätte ich mir das stets vorgestellt.

D.h. aber andersherum, daß man mit 64bit jeden Content einfach in den Adressraum einklinken könnte, und erst wenn es gebraucht wird, wird es in den realen Speicher geladen? Muß man es denn manuell wieder entladen?

Wird das heute auch schon gemacht und ist dafür der Adressraum auch bei kleineren Spielen noch zu gering?

[Lokadamus]

1.) Ist das nicht die falsche Frage?

2.) Sollte die Frage nicht lauten, warum Spiele die dem normalen Entwicklungszyklus durchlaufen (schöner, größer, komplexer), plötzlich Probleme bekommen?

3.) Und was die Lösung dafür wäre? (64Bit)mmm...

1.) Nein, es ist die richtige Frage: Sind 64Bit zwingend notwendig oder reichen 32Bit? Ist der Markt für reine 64Bit- Anwendungen/ Spiele bereit?

2.) Ist da nicht die Frage, warum es bei einem deutschen Entwicklerstudio so viele Probleme gibt, während ein amerikanisches Entwicklerstudio damit ziemlich gut klar kommt?

3.) 64Bit wären in diesem Fall nicht die Lösung, sondern wiedermal die Erlaubnis für schlampige Programmierung. Es ist ja genug Rechenpower da ...

[BlackBirdSR]

mmm...

1.) Nein, es ist die richtige Frage: Sind 64Bit zwingend notwendig oder reichen 32Bit? Ist der Markt für reine 64Bit- Anwendungen/ Spiele bereit?

2.) Ist da nicht die Frage, warum es bei einem deutschen Entwicklerstudio so viele Probleme gibt, während ein amerikanisches Entwicklerstudio damit ziemlich gut klar kommt?

3.) 64Bit wären in diesem Fall nicht die Lösung, sondern wiedermal die Erlaubnis für schlampige Programmierung. Es ist ja genug Rechenpower da ...

Ich bitte zu entschuldigen, aber das klingt als würde man das Gegengift ablehnen, während man diskutiert warum der eine Mensch eher auf das Gift anschlägt, der andere nicht.

Mit verlaub, wir haben ein Problem. Der eine kommt besser damit zurecht als der andere. Das Gegenmittel dazu liegt bereit, und wird auch benötigt. Da gibt es gar nichts daran zu rütteln.
Das Problem ist nur, dass sie sich halt nicht so einfach verabreichen lässt. Bis dahin muss man mit Hausmitteln und guter Hoffnung überleben.

[Lokadamus]

Ich bitte zu entschuldigen, aber das klingt als würde man das Gegengift ablehnen, während man diskutiert warum der eine Mensch eher auf das Gift anschlägt, der andere nicht.

Mit verlaub, wir haben ein Problem. Der eine kommt besser damit zurecht als der andere. Das Gegenmittel dazu liegt bereit, und wird auch benötigt. Da gibt es gar nichts daran zu rütteln.mmm...

Dein Vergleich hört sich für mich so an, als ob ich die Wahl habe, das Gegenmittel von einem fähigen Arzt oder Doktor Frankenstein gespritzt zu bekommen.

Wenn das eine Studio mit 32/64Bit klar kommt, dann soll es das benutzen, ja.
Wenn es das nicht kann, dann sollen sie sich lieber damit beschäftigen, was sie können, anstatt Schmutz zu machen (entweder auf 32Bit beschränken oder nur 64Bit bedienen).

[Exxtreme]

Verstehe es auch nicht so ganz, was würde dem entgegenstehen, wenn ich ein 2 GB Streaming Fenster habe, alles weitere ist in der Welt einfach über die Datei beschrieben. Wenn ich jetzt in einen Bereich komme, wo nicht alles nötige im Streaming Fenster brücksichtig ist, wird in der Weltbeschreibung nachgeschaut und die fraglichen Dateien in den Speicher geladen. So hätte ich mir das stets vorgestellt.

Erläutere es mal bitte genauer. ;) Ich glaube zwar zu wissen wo dein Fehler liegt, weiss es aber nicht genau ob du das so meinst.

[BlackBirdSR]

mmm...

Dein Vergleich hört sich für mich so an, als ob ich die Wahl habe, das Gegenmittel von einem fähigen Arzt oder Doktor Frankenstein gespritzt zu bekommen.

Wenn das eine Studio mit 32/64Bit klar kommt, dann soll es das benutzen, ja.
Wenn es das nicht kann, dann sollen sie sich lieber damit beschäftigen, was sie können, anstatt Schmutz zu machen (entweder auf 32Bit beschränken oder nur 64Bit bedienen).

Ich denke das wollte keiner damit aussagen. Natürlich sollte wer damit auskommt auch beim bekannten bleiben.

Wenn wir uns aber einmal auf Spiele beschränken, kann keiner 64Bit Systeme wirklich bedienen. Das Spieldesign muss ja identisch bleiben. Und nur mit höherer Sichtweite ist es ja nicht getan. Da sich die Basis an 32Bit Systemen dankt Vista x32 noch über Jahre hinweg auf 32Bit-Level bewegen wird, bekommen wir wohl auch nur sehr wenige reine 64Bit Spiele.

[Lokadamus]

Ich denke das wollte keiner damit aussagen. Natürlich sollte wer damit auskommt auch beim bekannten bleiben.mmm...

Als ich die von der letzten oder vorletzten Seite gestellte Frage mit Variante 2 beantwortet habe, wollte ich eigentlich nichts anderes sagen ;).
Bei deinem 2. Satz sehe ich eher das Problem, dass einige Programmierer teilweise Tagträumer sind und Sachen in Spiele einbringen wollen, die realistischer sind, aber wieder mehr Rechenpower in der einen oder anderen Art und Weise benötigen und zu unerwarteten Problemen führen. Sie können halt nicht so gut damit umgehen, wie es nötig wäre.

Wenn ich es richtig mitbekommen habe, wird bei Gothic 3 die KI über ein größeres Gebiet benutzt anstatt wie früher relativ lokal. Einer der Bugs, die hierdurch entstanden sind, waren leere Orte, welche von Tieren überrannt wurden. Gute, realistische KI, aber storymässig doch ein ziemlicher Bug. Wäre die KI lokal geblieben, wäre dieses Problem nie aufgetreten ...

[(del)]

Man nehme das Beispiel VFAT32. Mehr als 4 GB als Datei ist nicht drinne. Weil du mit 32 Bit nicht mehr adressieren kannst. Dabei ist es unerheblich ob du die 4 GB ganz am Stück oder einzelne Datensätze daraus brauchst. Es geht um das Ansprechen der Daten. Hast du aber 6 GB an Daten dann bekommst du ein Problem. Jetzt kannst du dir Workarounds überlegen, wie du damit umgehst.Dann lassen wir AIMP2 mal ruhen und nehmen... VLC. Damit kann man Playlisten auf für Videos erstellen.

Jetzt nehmen wir mal an, ich habe in der Playlist auch Videodateien die über 4GB groß sind. Mit VLC kann ich sie verwalten und VLC spielt sie auch problemlos ab. Flüssig. Und nu?

Hmm... Ich bin mir nicht sicher, deiner Antwort nach, ob du verstehst was ich mit diesen Analogien meine.

Blackbirds Antworten zu LAA gehen garnicht :usweet: Das hört sich so an als wenn er Angst hätte, man könnte mit 32bit zulange noch etwas reissen und die von ihm ersehnte Erlösung durch irgendeine brauchbare Lösung oder keine einseitigen Erklärungen nur unnötig verlschleppt wird. Technogeeks auf heißen Sohlen. Voll daneben. Meinungsmache.

Das wir mit 32bit ein Problem haben bestreitet doch niemand. Genauso verteufelt hier die 64bit (oder 48bit) ebenfalls niemand. Warum man aber mit 32bit gerade bei Spielen dermassen ins Schleudern kommen sollte, wie einige Studios uns das presentieren, ist hier aber noch lange nicht geklärt.

Ein Content der in seiner Gesamtheit (!) über 2GB liegt kann nicht der Grund dafür sein. Die Fragen des Gastes/meine sind hier noch garnicht geklärt oder auch nur angeschnitten.

Ich hab noch kein Spiel gesehen das mir mehr zeigt als in den VRAM passt ;) Und wir sind noch nichtmal großartig bei 1GB angelangt und selbst dann wird noch ein merkbar großes Stück davon für AA/AF verballert.

Wenn ich ein Spiel habe, wiederholt sich der Content an jedem Ort zu sagen wir mal 40%. Das muß ich immer parat haben. Oder sieht die Prozente hier jemand anders?
60% sind dann vom Ort, Figuren usw. abhängig. Selbst wenn ich eine übergangslose Welt haben möchte, brauche ich doch am Anfang des Spiels nicht den Content von der Mitte des Spiels verwalten. WOZU? Ich kann es nachladen, ich kann es "nachstreamen". Manche Studios kriegen das sogar recht flüssig hin. Ich muß nur wissen wo ich was auf der Platte abgelegt habe.
Ein 32bit XP-Kernel verwaltet hier mal eben hunderte Gigabytes an Daten. Superflüssig sogar (?)

Dann dauert selbst das Teleporten eben 1s auf 64bit und 4s auf 32bit, wenn ich plötzlich den kompletten Ort wechseln muß. Dabei kann ich den Spieler kurz mit einem ingame Video beschäftigen und gut.
Ich muß doch nur wissen was ich behalten und was ich von wo auf der Platte nachladen muß. Und das wird mir von einem 64bit FS geliefert.
Warum man sich für die Verwaltung dessen was man auf die Platte kopiert hat eigene virtuelle Dateisysteme basteln muß, begreife ich immernoch nicht.

Genau das gleiche fragt mekakic. Die Antwort ist übrigens köstlich... :uclap:

Bis morgen.

edit:
Womit ich nicht behaupte, ich hätte Recht und jemand versucht mich hier nur zu verschaukeln. Warum sich die Wissenden aber mit klaren Antworten auf ganz klare Fragen so extrem schwer tun, verstehe ich eben nicht. Wie präzise muß man diese Fragen noch präzisieren, Exxtreme? :|

[Aquaschaf]

Warum man aber mit 32bit gerade bei Spielen dermassen ins Schleudern kommen sollte, wie einige Studios uns das presentieren, ist hier aber noch lange nicht geklärt.

Das hat überhaupt nichts mit 32bit zu tun, sondern mit Zeitmangel und falscher Projektplanung bei Spielestudios.

[Gast]

Du kannst eine 5GB Datei (unter Windows) aber auch nur unter NTFS verschieben, weil das ein 64bit Dateisystem ist, im Gegensatz zu FAT :DNTFS steht auch dem Spiel zur Verfügung. Die Spiele selbst hauen aber an sich nie so große Einzeldateien auf die Platte (die sie dann laden/verwalten müßten).

Trotzdem danke für diese Neuigkeit...

BH

[Coda]

Jetzt nehmen wir mal an, ich habe in der Playlist auch Videodateien die über 4GB groß sind. Mit VLC kann ich sie verwalten und VLC spielt sie auch problemlos ab. Flüssig. Und nu?
Das ist doch sequentieller Zugriff. Das hat überhaupt gar nichts mit dem Problem zu tun.

mmm...

Das ist das, was ich meine.
Einige benutzen die Resourcen ordentlich und andere tun so, als gäbe es mehr als genug und wundern sich, warum sie später einige Probleme haben.
Die Gothic-3-Welt würde niemals in einen Speicherbereich in 32-Bit passen. Das kannst du nicht vergleichen. Es gibt einen massiven Unterschied zwischen Spielen mit freier Welt und Ladezonen was das angeht.

Ich würde gerne präziser antworten, aber die Fragen lassen das derzeit einfach nicht zu. Da würden die Antworten einfach zu lang werden und das ist mir einfach zu viel Arbeit weil man sie potentiell eh mal wieder ignoriert.

[BlackBirdSR]

...


steht alles hier im Thread. Musst du nur lesen. verstehen und verinnerlichen. Ich weiss gar nicht, warum du noch so tust, als könnte dir keiner sagen warum.
Und danke übrigens für die sehr netten Worte an uns. Diskutier doch mit anderen weiter.

[mekakic]

Erläutere es mal bitte genauer. ;) Ich glaube zwar zu wissen wo dein Fehler liegt, weiss es aber nicht genau ob du das so meinst. Es gibt eine Beschreibung der Welt, in denen alle Ressources stehen - also hier ein Haus, hier ein Stall, hier ein Huhn und hier eine Burg. Wo ich mich aktuell in der Welt befinde wird das Streaming Fenster der Welt befüllt, als alles was man an diesem Punkt in der Welt braucht oder vielleicht gleich brauchen könnte. In diesem Fenster werden einfach stets 1, 1.5 oder 2GiB an Weltdaten vorgehalten. Wenn ich in einen Bereich komme, wo ich das Haus brauche (was aber bisher in meinem Weltfenster nicht vorhanden ist), dann lade ich es hinzu. Paßt es nicht hinein, entfernt ein Mechanismus etwas, was dessen Ansicht nach jetzt am unwichtigsten ist - zum Beispiel das Huhn und der Stall werden entladen. Jetzt schnappe ich mir die Datei und lade sie in den Speicher, bekomme dann eine Adresse im 32bit Adressraum wieder wo z.B. 5 MiB an Daten für das Haus liegen .. und weiter gehts; falls ich das Huhn mal wieder brauche, gehts genauso...

Sicher fragmentiert mir dadurch der Heap und nach dem 100.000ten unterschiedlichen Haus / Huhn Kombinationen habe ich unter 32bit Probleme meine Stelle im Adressraum zu finden, wo die 5MiB reinpassen. Aber prinzipiell könnte ich damit doch locker 10GiB oder mehr an Modelldaten einbauen? Man stelle sich einfach vor, jedes 3D Modell ist (übertriebene) 100MiB groß. Ich kann 20 Modelle gleichzeitig darstellen, habe aber hundert. Jetzt habe ich eine XML (oder sonstwas) Datei in der eben Positionen und Eigenschaften von 100 Modellen an z.B. zusammen 300 Positionen in der ganzen Welt stehen. Das Ding ist hier vielleicht 500KiB groß, das bleibt immer im Speicher - der Rest wird einfach bei Bedarf dazugeladen.

[del_4901]

Extern fragmentieren tut der Heap da überhaupt nicht, da Stall, Haus und Huhn in Blöcke zerkloppt werden, welche alle die gleiche Größe haben. Man hat dann zwar Verschnitt (auch interne Fragmentierung genannt) aber damit muss/kann man leben.

[mekakic]

Extern fragmentieren tut der Heap da überhaupt nicht, da Stall, Haus und Huhn in Blöcke zerkloppt werden, welche alle die gleiche Größe haben. Man hat dann zwar Verschnitt (auch interne Fragmentierung genannt) aber damit muss/kann man leben.Echt? :confused: Ich dachte immer, daß die Sachen am Stück im Speicher liegen müssen? Wieso werden die in Blöcke zerlegt?

[Grestorn]

Extern fragmentieren tut der Heap da überhaupt nicht, da Stall, Haus und Huhn in Blöcke zerkloppt werden, welche alle die gleiche Größe haben. Man hat dann zwar Verschnitt (auch interne Fragmentierung genannt) aber damit muss/kann man leben.

Hatten wir diese Diskussion nicht schon mal, und hattest Du da nicht Stein und Bein darauf geschworen, dass es so etwas wie eine Fragmentierung des Adressraumes nicht geben würde?! :)

Was meinst Du mit "in Blöcke zerkloppt werden"? Von welchen Blöcken sprichst Du da bitte?

[Exxtreme]

Dann lassen wir AIMP2 mal ruhen und nehmen... VLC. Damit kann man Playlisten auf für Videos erstellen.

Jetzt nehmen wir mal an, ich habe in der Playlist auch Videodateien die über 4GB groß sind. Mit VLC kann ich sie verwalten und VLC spielt sie auch problemlos ab. Flüssig. Und nu?

Hmm... Ich bin mir nicht sicher, deiner Antwort nach, ob du verstehst was ich mit diesen Analogien meine.

Nein, ich verstehe deine Analogien nicht. Was haben Playlists mit der Problematik zu tun?

[Gast]

Nein, ich verstehe deine Analogien nicht. Was haben Playlists mit der Problematik zu tun?Was ist denn die Problematik?

[Gast]

Was meinst Du mit "in Blöcke zerkloppt werden"? Von welchen Blöcken sprichst Du da bitte?Was sind eigentlich memory pages?

[Grestorn]

Was ist denn die Problematik?

Wahlfreier, schneller Zugriff auf eine Datenstruktur, die sehr groß ist.

[Exxtreme]

Was ist denn die Problematik?
Zugriff auf eine Menge an Daten, die die 32 Bit überschreitet wodurch eine direkte Adressierung unmöglich ird.

[Grestorn]

Was sind eigentlich memory pages?

Die kleinste Speichereinheit, die a) in ein Pagefile ausgelagert werden kann und b) im physischen Speicher einer virtuellen Adresse zugeordnet werden kann.

Aber wenn eine Software einen Speicherblock der Größe x anfordert, muss immer ein fortlaufender Adressbereich im virtuellen Adressraum dafür bereitgestellt werden. Und dieser kann zwar in kleinen Blöcken (eben den Pages) auf verschiedene physische Speicherbereiche aufgeteilt werden, aber im virtuellen Adressraum muss er am Stück fortlaufend bleiben.

Und die Begrenzung des virtuellen Adressraums und die damit verbundene Gefahr der Fragmentierung ist eben auch das eigentliche Problem bei 32 bit!

[Gast]

steht alles hier im Thread. Musst du nur lesen. verstehen und verinnerlichen.Da müßen aber noch einige hier im Thread was? Arroganter Blödsinn.

}Und danke übrigens für die sehr netten Worte an uns.Leute die in Namen des Volkes sprechen bedeuten für eine Diskussion eine Sackgasse. Netter Versuch.

@Exxtreme
Wir kommen der Sache näher ;) Warum muß man auf mehr als 32bit Daten zugreifen, wenn man weniger als 32bit an Daten braucht? Wie mekakic es eben beschrieben hat.

@Grestorn
Werden Adressbereiche im Virtuellen Adressraum nicht auch mal frei? Oder verpeil ich hier noch was? Letztendlich schnapp ich mir als Spiel erstmal alles was frei ist bzw. was ich zum Startzeitpunkt bekommen kann. Das ist zB. nach einem Neustart von XP32 wieviel? (+ nochmal das was mekacic erwähnt hat und was ich schon die ganze Zeit meine).

[(del)]

Sorry, habs verpeilt mich anzumelden.

Warum muß man auf mehr als 32bit Daten zugreifenWarum über eine direkte Adressierung. Warum sollte die ganze G3-Welt in den Adressraum passen?

[Exxtreme]

@Exxtreme
Wir kommen der Sache näher ;) Warum muß man auf mehr als 32bit Daten zugreifen, wenn man weniger als 32bit an Daten braucht? Wie mekakic es eben beschrieben hat.

Damit das Programm von den Daten überhaupt Kenntnis hat und weiss wo diese Daten liegen.

[Grestorn]

@Grestorn
Werden Adressbereiche im Virtuellen Adressraum nicht auch mal frei? Oder verpeil ich hier noch was? Letztendlich schnapp ich mir als Spiel erstmal alles was frei ist bzw. was ich zum Startzeitpunkt bekommen kann. Das ist zB. nach einem Neustart von XP32 wieviel? (+ nochmal das was mekacic erwähnt hat und was ich schon die ganze Zeit meine).

Adressen im virtuellen Adressraum werden nur dann frei, wenn die Applikation den reservierten Speicher explizit freigibt.

Jede Applikation hat per Standard 2 GB Adressraum (32 bit, kein /3GB Switch). Mit dem muss sie auskommen. Wenn sie wiederholt sehr viele kleine und große Speicherblöcke allokiert und auch immer wieder teilweise freigibt, dann entsteht im virtuellen Adressraum eine Art "schweizer Loch-Käse", also reservierter Bereich, der von mehr oder weniger großen, nicht reservierten Speicherbereichen unterbrochen wird.

Wenn man das auf die Spitze treibt, kommt die Applikation irgendwann an den Punkt, bei dem für die Anforderung eines neuen, größeren Speicherblocks einfach kein unreserviertes "Loch" mit ausreichender Größe im Speicher mehr verfügbar ist, und so die Speicheranforderung nicht erfüllt werden kann, obwohl in der Summe genügend Speicheradressen im virtuellen Speicherbereich verfügbar wären und das System auch noch jede Menge echten und virtuellen Speicher zur Verfügung hat.

[mekakic]

Wahlfreier, schneller Zugriff auf eine Datenstruktur, die sehr groß ist. Warum muß denn Adressraum für alles an Content im Speicher reserviert sein? Wieso sollte Xardas Turm seinen kompletten Platz im 32bit Adressraum brauchen, 100h Spielstunden bevor ich nach Nordmar komme? Wenn man Adressraum hat, ist das sicher nett, aber warum nötig?

[mekakic]

Damit das Programm von den Daten überhaupt Kenntnis hat und weiss wo diese Daten liegen. Aber um zu wissen, wo die Daten liegen brauch ich doch nicht den ganzen Platz im Adressraum. Ich brauche doch nur eine Struktur, die mir sagt ob das Ding geladen ist und wenn ja an welcher Adresse.

EDITH: Die Fragmentierung des Adressraums ist (mir zumindest) klar, warum mehr als 4GiB Content nicht ohne große Schwierigkeiten möglich seinen sollen aber noch nicht.

[Grestorn]

Warum muß denn Adressraum für alles an Content im Speicher reserviert sein? Wieso sollte Xardas Turm seinen kompletten Platz im 32bit Adressraum brauchen, 100h Spielstunden bevor ich nach Nordmar komme? Wenn man Adressraum hat, ist das sicher nett, aber warum nötig?
Man kann natürlich mit viel Aufwand selbst eine Verwaltung programmieren, die die Datenobjekte virtualisiert und bei Bedarf nachläd.

Aber das ist eben viel Aufwand und man kann es gut und schlecht machen. Meist spart man sich das, und teilt die Welt lieber in kleine Level auf, die in den Adressraum passen.

Aber viel einfacher wäre es, man müsste sich darum einfach gar keine Gedanken machen und einfach ein großes, mehrere GB umfassenses Memory-Mapped File, in dem alle Objekte und Daten liegen, dem System bekannt geben, und los gehts. Das Programm greift dann einfach auf die Objekte zu und das Betriebssystem kümmert sich darum, dass sie bei Bedarf auch im physischen Speicher liegen. Das OS kann dabei die Ressourcen des Systems auch am besten nutzen.

Das ist die einzige wahre Lösung des Problems!

[BlackBirdSR]

Man kann natürlich mit viel Aufwand selbst eine Verwaltung programmieren, die die Datenobjekte virtualisiert und bei Bedarf nachläd.

Aber das ist eben viel Aufwand und man kann es gut und schlecht machen. Meist spart man sich das, und teilt die Welt lieber in kleine Level auf, die in den Adressraum passen.

Aber viel einfacher wäre es, man müsste sich darum einfach gar keine Gedanken machen und einfach ein großes, mehrere GB umfassenses Memory-Mapped File, in dem alle Objekte und Daten liegen, dem System bekannt geben, und los gehts. Das Programm greift dann einfach auf die Objekte zu und das Betriebssystem kümmert sich darum, dass sie bei Bedarf auch im physischen Speicher liegen. Das OS kann dabei die Ressourcen des Systems auch am besten nutzen.

Das ist die einzige wahre Lösung des Problems!

Neverwinter Nights 2 machts wie in Absatz 1 beschrieben. Realtiv kleine Level und Abschnitte. Dazwischen Ladezeiten und strikte Trennung.
Oblivion ähnlich, was bei der Detailfülle beider Spiele wohl sein muss.

Der 2. Absatz scheitert nun leider an Vista32 und der generellen Angst/Trägheit. Mit DX10 hat man sich getraut, aber da ging es nur um Spiele. Beim Betriebsystem selbst hatte man wohl zu viele Bedenken was Absatz und Kompatibilität angeht.

Nur was jetzt? Ich sehe nicht, wie sich die nächsten Jahre etwas daran ändert. Wir werden auc 2010 noch eine gigantische 32-Bit Basis haben. Und so gut wie keiner davon wird über 3GB Adressraum verfügen.

[(del)]

Damit das Programm von den Daten überhaupt Kenntnis hat und weiss wo diese Daten liegen.Es muß doch aber zur Laufzeit nicht ständig ALLE Daten bereithalten, da es nicht ständig alle Daten braucht. Und wenn es mal neue Daten braucht, guckt es in der eigenen Datenbank aus welcher Datei es sie holen soll.
Wäre diese Datenbank das virtuelle Dateisystem von G3? Dann wäre schon die Hälfte des Problems verstanden ;) Warum aber kann diese Vorgehensweise den 32bit Adressraum bzw. die 2GB/3GB RAM sprengen? Ok ich check mal aus hier und warte bis jemand auf den letzten Beitrag von mekacic eingegangen ist.

@Grestorn
Ok. Klar. Das ist die Fragmentierung des virtuellen Adressraumes.
Damit aber, WENN man es auf die Spitze treibt, dürfte aber entweder die Anendung durch das nötige Rumhüpfen des Kernels in den Adressbereichen langsamer werden oder sie kriegt den gebrauchten Adressbereich halt nicht zusammengekratzt. Was mir bei G3 aber nicht einleuctehn will.
Schön daß es jetzt jeder weiß, aber was hat das mit G3 zu tun, wenn man vor dem Start des Spiels es eben nicht auf die Spitze trieb?

Wie gesagt das Bereithalten von Querweisen für 6 GB Daten benötigt wohl keine 100 MB :| Nachladen bzw. Vorladen muß ich unter 64bit und 6GB ja auch, wenn ich dann 10GB Content habe. Der Streaming wird also immer aktuelle bleiben, Exxtreme ;) Die Spiele werden immer besser aussehen und bringen dann eben 2 DVDs Content oder gar eine ganze BR. Die Leute werden garantiert nicht alle 6 Monate den RAM um 2GB erweitern.

Der größere Adressbereich macht es einfacher, warum macht es der kleinere aber gleich fast unmöglich?

edit:
Was Vista64 ist die Zukunft :| und Spiele angeht. Wieviel RAM kann maximal Vista64 HomePremium verwalten? :uup: Wenn schon G3 ~6GB hat, ist man da mit der nächsten Generation der Spiele nicht auch schon am Ende?

[Gast]

Adressen im virtuellen Adressraum werden nur dann frei, wenn die Applikation den reservierten Speicher explizit freigibt.

Jede Applikation hat per Standard 2 GB Adressraum (32 bit, kein /3GB Switch). Mit dem muss sie auskommen. Wenn sie wiederholt sehr viele kleine und große Speicherblöcke allokiert und auch immer wieder teilweise freigibt, dann entsteht im virtuellen Adressraum eine Art "schweizer Loch-Käse", also reservierter Bereich, der von mehr oder weniger großen, nicht reservierten Speicherbereichen unterbrochen wird.

Wenn man das auf die Spitze treibt, kommt die Applikation irgendwann an den Punkt, bei dem für die Anforderung eines neuen, größeren Speicherblocks einfach kein unreserviertes "Loch" mit ausreichender Größe im Speicher mehr verfügbar ist, und so die Speicheranforderung nicht erfüllt werden kann, obwohl in der Summe genügend Speicheradressen im virtuellen Speicherbereich verfügbar wären und das System auch noch jede Menge echten und virtuellen Speicher zur Verfügung hat.
Das war doch früher vor der Zeit von virtuellen Adressraum auch ein Problem, damals machte man halt AFAIK Compaction und verschob die einzelnen Blöcke um wieder einen großen zusammenhängenden freien Bereich zu bekommen. Ist zwar sicher sehr langsam und aufwendig, aber was hindert einen daran dasselbe auch mit dem virtuellen Adressraum zu machen. Zumal es dort ja eigentlich schneller gehen müsste weil keine physischne Daten herumkopiert werden müssen sondern nur virtuelle Adressen neu gemappt.

[(del)]

Das war doch früher vor der Zeit von virtuellen Adressraum auch ein Problem, damals machte man halt AFAIK CompactionHab ich gerade auch überlegt. Es ist ja alles nur virtuell.

[Gast]

Hab ich gerade auch überlegt. Es ist ja alles nur virtuell.
Wenn ich mich recht erinnere hat man aber den virtuellen Adressraum überhaupt erst eingeführt weil man Compaction um jeden Preis vermeiden wollte - zu teuer und langsam. Und auch mit virtuellen Adressen dürfte das ganze nicht viel einfacher werden, da muss man dann den TLB und alles was da dranhängt auch neu laden, außerdem braucht man wieder eine eigene Verwaltung für die Löcher, ganz abgesehen vom Algorithmus der dann wirklich die Ersetzung vornimmt....

[(del)]

Was mich diesbezüglich als Laie auch immer interessiert hat, Datenträger lassen sich real defragmentieren, ein virtuelles Adressraum nicht? :frown:

[Exxtreme]

Aber um zu wissen, wo die Daten liegen brauch ich doch nicht den ganzen Platz im Adressraum. Ich brauche doch nur eine Struktur, die mir sagt ob das Ding geladen ist und wenn ja an welcher Adresse.

Doch, brauchst du. Das ist ja das Problem. Das Programm ist in der Lage maximal 4 GB "zu sehen". Hast du 6 GB an Daten dann sind die restlichen 2 GB für das Programm vorerst nicht existent. Braucht man aber die restlichen 2 GB, geht schon die Trickserei los.


Nochmal, es behauptet niemand, daß es nicht möglich ist mit 32 Bit mehr als 4 GB anzusprechen. Es geht leider nur indirekt und ist mit zusätzlichen Aufwand, Rumtrickserei und zusätzlichen Code verbunden. Was das Programm langsamer und fehleranfälliger macht. Noch nicht aufgefallen, daß es 10 Jahre lang mit den Spielständen geklappt hat und plötzlich paar "Blockbuster" Spielstände zerschiessen? Durch solche Rumtrickserei kann sowas eben auftreten. Da kann es halt passieren, daß paar Daten nicht mehr eindeutig sind weil man vergessen hat sie vorher rauszuwerfen etc.

[Gast]

Doch, brauchst du. Das ist ja das Problem. Das Programm ist in der Lage maximal 4 GB "zu sehen".Ja muß es denn mehr sehen?

[Gast]

Ja muß es denn mehr sehen?p.s.: Oblivion soll laut Blackbird besser rennen, weil man die Level kleiner hält. Ok. An content hat es aber nicht weniger als G3 oder? Warum hat es nicht solche oder fast garkeine Probleme damit, mehr als 4GB "zu sehen"? Das eine ergibt sich ja nicht aus dem anderen, wenn ich euren Erklärungen folge.

[BlackBirdSR]

Nochmal, es behauptet niemand, daß es nicht möglich ist mit 32 Bit mehr als 4 GB anzusprechen. Es geht leider nur indirekt und ist mit zusätzlichen Aufwand, Rumtrickserei und zusätzlichen Code verbunden. Was das Programm langsamer und fehleranfälliger macht. Noch nicht aufgefallen, daß es 10 Jahre lang mit den Spielständen geklappt hat und plötzlich paar "Blockbuster" Spielstände zerschiessen? Durch solche Rumtrickserei kann sowas eben auftreten. Da kann es halt passieren, daß paar Daten nicht mehr eindeutig sind weil man vergessen hat sie vorher rauszuwerfen etc.

Dann lass uns da mal weitermachen:
Vista x64 bietet 16GB RAM und 8TB Addressraum. Also genug für die Zeit in der Vista auf dem Markt ist. Aber vom Design kann man die Spiele nicht darauf anpassen. Ein Age of Conan oder Neverwinter Nights 2 würden nicht mit mit der 32-Bit Version übereinstimmen. EIn gigantischer Arbeitsaufwand um Skripts und Features anzupassen, und neue Bugs zu tilgen. Für Multiplayerspiele ist das so wie so ein No-Go!
Was bleibt sind kleine Gimmicks wie mehr Sichtweite oder leichte Performancevorteile. Die Abstürze bei unzureichender Optimierung (auf 32Bit Systemen) oder die kaputten Spielstände lassen sich damit jedoch nicht lösen. Und das auf mehrere Jahre..
Was nun?

[Exxtreme]

Ja muß es denn mehr sehen?
Ja, muss es bzw. dem Programm muss irgendwie bekannt gemacht werden, daß da noch mehr ist. Und der Mechanismus für die "Bekanntmachung" ist leider selbst von der 32-Bit-Regel betroffen. Das ist ja die Schwierigkeit an der ganzen Sache. :D

Klar kann man die Welt in 3 Teile aufteilen und sobald der Spieler einen Trigger überschreitet dann Ladebalken -> Teil 1 raus aus dem RAM -> Teil 2 rein in den RAM und weiter geht's. Oder man teilt die Welt in Kacheln ein schmeisst die Kacheln nach Bedarf auch aus dem RAM und lädt andere Kacheln. Merkt der Spieler vielleicht gar nicht. Nur ist das eben Rumtrickserei um Hardwarebeschränkungen zu umgehen.

[PatkIllA]

Was mich diesbezüglich als Laie auch immer interessiert hat, Datenträger lassen sich real defragmentieren, ein virtuelles Adressraum nicht? :frown:
Ginge auch. Da müssen dann aber wieder Daten umkopiert werden und man muss alle Pointer kennen und entsprechend verändern. Das ist mindestens genauso problematisch.

[Gast]

Ginge auch. Da müssen dann aber wieder Daten umkopiert werden und man muss alle Pointer kennen und entsprechend verändern. Das ist mindestens genauso problematisch.
Beim virtuellen Adressraum sollte es nach meinem Verständnis nicht nötig sein Daten umzukopieren. Das Programm merkt das ja gar nicht, das ist Sache des OS. Insofern bleiben auch alle Pointer konsistent.
Ändert natürlich nichts daran dass es saumäßig aufwendig wäre.

[del_4901]

Echt? :confused: Ich dachte immer, daß die Sachen am Stück im Speicher liegen müssen? Wieso werden die in Blöcke zerlegt?
Wiso sollen die am Stueck im Speicher liegen? RAM ist keine Festplatte, wo ein Arm sich ueber den Daten platzieren muss. Es ist also egal wie die Daten verteilt sind, der Zugriff darauf wird sich nicht verlangsamen. Wann man Bloecke gleicher Groesse hat, kann man zudem eine sehr schnelle eigene Speicherverwaltung implementieren, das waehre noch ein Grund mehr das so zu machen. Und das zerkloppen duefte wohl kein Problem sein, dass muss man eh machen, wenn man effizient arbeiten will (z.B.: Quadtree)

Hatten wir diese Diskussion nicht schon mal,
Sieh an, du hast also immernoch nichts dazu gelernt.
und hattest Du da nicht Stein und Bein darauf geschworen, dass es so etwas wie eine Fragmentierung des Adressraumes nicht geben würde?! :)
Habe ich nicht, ich habe nur gesagt, das ich damit keine Probleme habe, und das habe ich immernoch nicht.
Was meinst Du mit "in Blöcke zerkloppt werden"? Von welchen Blöcken sprichst Du da bitte?
Stell dich doch nicht bitte so bloed an, das sind vom Programmierer vergebene Memorychunks. Das ist notwendiger Standart, wenn man mit C/C++ arbeitet, und viele dynamische Daten hat.
Die kleinste Speichereinheit, die a) in ein Pagefile ausgelagert werden kann und b) im physischen Speicher einer virtuellen Adresse zugeordnet werden kann. Das sind memoryframes, pages sind die Bloecke im virtuellen Adressraum. Und aus der kleinsten Speichereinheit koennte ich dir auch einen Strick drehen, aber ich lass es einfach.

Man kann natürlich mit viel Aufwand selbst eine Verwaltung programmieren, die die Datenobjekte virtualisiert und bei Bedarf nachläd.
ein Tag ist also viel Aufwand
Aber viel einfacher wäre es, man müsste sich darum einfach gar keine Gedanken machen und einfach ein großes, mehrere GB umfassenses Memory-Mapped File, in dem alle Objekte und Daten liegen, dem System bekannt geben, und los gehts. Das Programm greift dann einfach auf die Objekte zu und das Betriebssystem kümmert sich darum, dass sie bei Bedarf auch im physischen Speicher liegen. Das OS kann dabei die Ressourcen des Systems auch am besten nutzen.

Das ist die einzige wahre Lösung des Problems!
Das ist einzig wahrer Bullshit, wenn man das so machen wuerde, dann wurde ich morgen noch auf die Speicheranforderung von heute warten. Vom OS wird nur einmalig Speicher geholt, und dann kuemmert sich das Game um den Rest. Speicheranforderungen vom OS sind um das 500x langsamer als wenn man das selber macht. Und wie bereits gesagt, zerkloppen muss ich die Geometrie eh, auf die eine oder andere Art.

[Grestorn]

@Grestorn
Ok. Klar. Das ist die Fragmentierung des virtuellen Adressraumes.
Damit aber, WENN man es auf die Spitze treibt, dürfte aber entweder die Anendung durch das nötige Rumhüpfen in den Adressbereichen langsamer werden oder sie kriegt den gebrauchten Adressbereich zusammengekratzt.
Schön daß es jetzt jeder weiß, aber was hat das mit G3 zu tun, wenn man vor dem Start des Spiels es eben nicht auf die Spitze trieb?

Wie gesagt das Bereithalten von Querweisen für 6 GB Daten benötigt wohl keine 100 MB :| Nachladen bzw. [/i]Vorladen[/i] muß ich unter 64bit und 6GB ja auch, wenn ich dann 10GB Content habe. Der Streaming wird also immer aktuelle bleiben, Exxtreme ;) Die Spiele werden immer besser aussehen und bringen dann eben 2 DVDs Content oder gar eine ganze BR.
Der größere Adressbereich macht es einfacher, warum macht es der kleinere aber gleich fast unmöglich?

Das "Rumhüpfen" macht überhaupt nichts langsam. Das einzige, was bremst, ist wenn Speicher von der Platte nachgeladen werden muss, weil er nicht bereits im physischen Speicher liegt.

Wenn genug physischer Speicher da ist, um alle Anforderungen die das Programm stellt zu erfüllen, dann merkst Du davon nichts. Nur wenn Du in andere Gebiete kommst und ein bislang unbenötigtes Objekt gebraucht wird, dass in einem noch nicht zugeordneten Speicherbereich liegt, muss dieser eben nachgeladen werden.

G3 hatte das Problem, dass sie selbst Objekte nachladen wenn sie sie brauchen und wieder freigeben, wenn sie eine längere Zeit nicht gebraucht werden. Dadurch kommt es genau zu dem "Schweizer Käse" Problem.

Um das zu vermeiden, wurde eine extra Speicherverwaltung dazugekauft, die das mildern soll, aber auch die kommt an ihre Grenzen. Das Ruckeln in G3 kommt übrigens auch nicht so sehr durch das nachladen sondern durch das regelmäßig notwendig werdende Bereiningen des Speichers.

[Grestorn]

Das war doch früher vor der Zeit von virtuellen Adressraum auch ein Problem, damals machte man halt AFAIK Compaction und verschob die einzelnen Blöcke um wieder einen großen zusammenhängenden freien Bereich zu bekommen. Ist zwar sicher sehr langsam und aufwendig, aber was hindert einen daran dasselbe auch mit dem virtuellen Adressraum zu machen. Zumal es dort ja eigentlich schneller gehen müsste weil keine physischne Daten herumkopiert werden müssen sondern nur virtuelle Adressen neu gemappt.

Was Du meinst ist eine GarbageCollection, und die kriegst Du nur wenn Du entweder entsprechende Sprachen benutzt (Java, BASIC, C#) oder eine entsprechende Speicherbibliothek mit SmartPointern in C++ einsetzt.

Und natürlich ist das nicht kostenlos, sprich es kostet auch Rechenzeit, speziell wenn eine Collection notwendig wird, was im Spiel dann eben auch wieder ein Ruckler ist. Siehe Gothic 3.

[Grestorn]

Sieh an, du hast also immernoch nichts dazu gelernt.

Und sofort schießt er sich auf mich ein. Du bist so berechnbar. Mal sehen wie lange es dauert, bis Du Dir erneut ein Bein stellst.

Stell dich doch nicht bitte so bloed an, das sind vom Programmierer vergebene Memorychunks. Das ist notwendiger Standart, wenn man mit C/C++ arbeitet, und viele dynamische Daten hat.
Das sind memoryframes, pages sind die Bloecke im virtuellen Adressraum. Und aus der kleinsten Speichereinheit koennte ich dir auch einen Strick drehen, aber ich lass es einfach.

Was soll denn der Schmarrn? Memorychunks. So ein Blödsinn. Wenn Du ein Objekt in C++ allokierst, dass 5 MB groß ist, dann werden 5 MB zusammenhängender Adressraum benötigt. Ganz egal ob es letztlich eine kleinste Speichereinheit gibt, die man allokieren kann, die hilft einem dabei GAR nichts.

Nur ein Speichermanager mit GarbageCollection (mit den bekannten Nachteilen) oder eben ein praktisch unbegrenzt großer Adressraum lösen das Problem endgültig.

Versuch doch mal mir einen Strick zu drehen, Herr von und zu Projektmanager, der offenbar keine Ahnung von Technik hat. Sorry, aber das muss mal gesagt werden.

[Gast]

Was Du meinst ist eine GarbageCollection, und die kriegst Du nur wenn Du entweder entsprechende Sprachen benutzt (Java, BASIC, C#) oder eine entsprechende Speicherbibliothek in C++ einsetzt.

Nein meine ich nicht. Compaction (http://ozark.hendrix.edu/~burch/csbsju/cs/350/notes/18/) ist eine Speicherverwaltungsstrategie und damit Sache des OS, Programme kriegen davon genau gar nix mit. Wie du hier auf Garbage Collection kommst ist mir ein Rätsel.

[del_4901]

Was soll denn der Schmarrn? Memorychunks. So ein Blödsinn. Wenn Du ein Objekt in C++ allokierst, dass 5 MB groß ist, dann werden 5 MB zusammenhängender Adressraum benötigt. Ganz egal ob es letztlich eine kleinste Speichereinheit gibt, die man allokieren kann, die hilft einem dabei GAR nichts.

Nur ein Speichermanager mit GarbageCollection (mit den bekannten Nachteilen) oder eben ein praktisch unbegrenzt großer Adressraum lösen das Problem endgültig.
Wenn ich einmalig ein grosses Objekt brauchen sollte, dann hohl ich mir das vom OS. Wenn ich viele gleich grosse Objekte brauche, die ich haeufig auch wieder freigebe, dann biege ich den new Operator auf eine eigens fuer diesen Objektyp geschriebene Speicherverwaltung um. Die ist erstens schneller, und zweitens, kann mein Addressraum nicht fragmentieren, da ich benutzte Bloecke wiederverwende. Wenn du haeufiger C++ programmmieren wuerdest, dann wuesstest du das aber auch.

In einem klassischen Game tritt der 2te Fall haeufig genug auf, sodass ich mir da keine Sorgen muss, das ich mal einen Teil der Map nicht in den Speicher bekomme.


Versuch doch mal mir einen Strick zu drehen, Herr von und zu Projektmanager, der offenbar keine Ahnung von Technik hat. Sorry, aber das muss mal gesagt werden. Wer hier keine Ahnung hat, steht ja wohl ausser Frage.

[mekakic]

Wiso sollen die am Stueck im Speicher liegen? RAM ist keine Festplatte, wo ein Arm sich ueber den Daten platzieren muss. Ich meine schon den virtuellen Adressraum, nicht den Speicher. Wie das im Speicher zerschreddert ist, kann mir ja egal sein. Nur ein Pointer auf eine Position in meinem virtuellen Adressraum, sollte dort dann auch den Bereich zusammenhängend haben :)

[Grestorn]

Nein meine ich nicht. Compaction (http://ozark.hendrix.edu/~burch/csbsju/cs/350/notes/18/) ist eine Speicherverwaltungsstrategie und damit Sache des OS, Programme kriegen davon genau gar nix mit. Wie du hier auf Garbage Collection kommst ist mir ein Rätsel.

Da ein Programm mit absoluten (virtuellen) Adressen arbeitet, kann das OS die nicht verschieben und damit auch nicht komprimieren. Was Du schreibst kann nicht funktionieren, nicht im virtuellen Adressraum!

[del_4901]

Ich meine schon den virtuellen Adressraum, nicht den Speicher. Wie das im Speicher zerschreddert ist, kann mir ja egal sein. Nur ein Pointer auf eine Position in meinem virtuellen Adressraum, sollte dort dann auch den Bereich zusammenhängend haben :)
Wofuer? Ich zerhacke ja nicht planlos, alles was mir vor die Latichte kommt. Es wird schon nur dort zerkloppt wo es Sinn macht, bzw es sowieso gemacht werden muss.
Da ein Programm mit absoluten (virtuellen) Adressen arbeitet, kann das OS die nicht verschieben und damit auch nicht komprimieren. Was Du schreibst kann nicht funktionieren, nicht im virtuellen Adressraum!
Hallo, die Welt beteht nicht nur aus x86ern. Es gibt durchaus Architekturen, wo man das so machen kann... Stichwort relative Adressierung ... Auch wenn mir jetzt grade keine einfaellt

[Grestorn]

Wenn ich einmalig ein grosses Objekt brauchen sollte, dann hohl ich mir das vom OS. Wenn ich viele gleich grosse Objekte brauche, die ich haeufig auch wieder freigebe, dann biege ich den new Operator auf eine eigens fuer diesen Objektyp geschriebene Speicherverwaltung um. Die ist erstens schneller, und zweitens, kann mein Addressraum nicht fragmentieren, da ich benutzte Bloecke wiederverwende. Wenn du haeufiger C++ programmmieren wuerdest, dann wuesstest du das aber auch.

Also machst Du Dir mühselig Gedanken darum, wie Du den Speicher so verwaltest, dass es nicht zur Fragmentierung kommt. Warum solltest Du das tun müssen? Das ist überflüssig, kostet Zeit (Deine und die des Rechners) und lässt sich komplett umgehen, in dem man den Adressraum erweitert.

"Benutzte Blöcke wiederverwendet" geht aber übrigens schon mal gar nicht, wenn die Blöcke nicht alle die gleiche Größe haben (Texturen usw.) und auch nicht immer in der selben Menge benötigt werden. Wenn Du natürlich den ganzen Level en block lädst und hinterher den gesamten Block wieder freigibst wenn der Level nicht mehr benötigt wird, hast Du das Problem umgangen - wie die meisten Spiele. Für eine große Welt, die mehr Speicher braucht als Adressraum da ist, funktioniert diese Lösung nur nicht, ohne dass man sie doch wieder in kleinere Level aufteilt.

Wer hier keine Ahnung hat, steht ja wohl ausser Frage.
Ganz recht.

[del_4901]

Also machst Du Dir mühselig Gedanken darum, wie Du den Speicher so verwaltest, dass es nicht zur Fragmentierung kommt. Warum solltest Du das tun müssen? Das ist überflüssig, kostet Zeit (Deine und die des Rechners) und lässt sich komplett umgehen, in dem man den Adressraum erweitert.
Das ist ein Tag Arbeit
Die Allokation braucht O(1) .... uhhh
Die Deallokation braucht auch O(1) .... uhhh

"Benutzte Blöcke wiederverwendet" geht aber übrigens schon mal gar nicht, wenn die Blöcke nicht alle die gleiche Größe haben (Texturen usw.) und auch nicht immer in der selben Menge benötigt werden.
Was habe ich denn gesagt... Bloecke gleicher groesse ... und Texturen liegen eh im Graka Speicher da muss ich mich nicht drum kuemmmern. Da hab ich maximal nen kleinen Cache um die ein oder andere Textur mal schnell vorzuladen.

Wenn Du natürlich den ganzen Level en block lädst und hinterher den gesamten Block wieder freigibst wenn der Level nicht mehr benötigt wird, hast Du das Problem umgangen - wie die meisten Spiele. Für eine große Welt, die mehr Speicher braucht als Adressraum da ist, funktioniert diese Lösung nur nicht, ohne dass man sie doch wieder in kleinere Level aufteilt.

Wer die Welt(Level) als ein grosses Teil aufasst, hat ganz andere Probleme als die Speicherverwaltung. Befass dich mal mit dem Thema, anstatt immer mitreden zu wollen, obwohl du keinen Plan hast, das nervt!

[mekakic]

Das ist die einzige wahre Lösung des Problems!Danke, das ist sicher ungleich komfortabler -- wobei ich noch nicht so davon überzeugt bin, daß das dynamische Nachladen von Objekten jetzt so komplex ist. Etwas derartiges habe ich auch schon gemacht (in deutlich kleineren Welten) und das war wahrlich nicht das größte Problem. Bei Gothic3 sehen ich eher das Problem, daß zum einen der 32bit Adressraum fragmentiert, zum anderen das man nicht zuviel Content hat, sondern zuviel gleichzeitig im Speicher halten muß, weil man es mit dem was gleichzeitig angezeigt und verarbeitet werden soll, etwas übertrieben hat. Das ein Streaming System in solchen Grenzsituationen sicherlich aus dem letzten Loch pfeift ist klar. Damit das nicht falsch verstanden wird, bin sehr deutlich für 64bit Systeme (verwende auch selber eins) und das 32bit System bei viel Content Probleme bekommen sehe ich genauso, nur das die Gesamtmenge des Contents (und nicht der gleichzeitig benötigte) eines der zentralen Probleme ist, sehe ich momentan noch nicht so; unabhängig von anderen Vorteilen des vergrößten Adressraums.

Würde man Memory Mapped files denn unter 32bit überhaupt machen wollen, wenn man auch nur knapp 2GiB Content hat? Das nimmt ja auch bei 32Bit gleich schonmal eine ganze Menge Adressraum weg und der Rest mag durch jede Menge dynamischer Nutzdaten auch wieder schnell fragmentieren.

[Grestorn]

Was habe ich denn gesagt... Bloecke gleicher groesse ... und Texturen liegen eh im Graka Speicher da muss ich mich nicht drum kuemmmern. Da hab ich maximal nen kleinen Cache um die ein oder andere Textur mal schnell vorzuladen.Wenn Du größere Blöcke nimmst um auch kleinere Objekte darin abzulegen hast Du nur die Granularität vergrößert und am Problem selbst nichts geändert.

Z.B.: Nehmen wir an Dein Block ist 5kB groß (kannst jeden anderen Wert nehmen). Damit kostet erstens jedes Mini-Objekt schon mal 5 kB Platz. Aber damit ließe sich ja noch leben. Schlimmer ist aber, wenn ein Objekt mal mehr als 5kB braucht, dann musst Du nämlich eine Anzahl zusammenhängender Blöcke allokieren. Und hast letztlich wieder genau das selbe Problem, nur auf einer anderen, weil gröberen Ebene.

Blöcke bilden - bei dynamischen Daten unterschiedlicher Größe - macht gar keinen Sinn.

Wer die Welt(Level) als ein grosses Teil aufasst, hat ganz andere Probleme als die Speicherverwaltung. Befass dich mal mit dem Thema, anstatt immer mitreden zu wollen, obwohl du keinen Plan hast, das nervt!

Natürlich wird die Welt nicht als ein Teil aufgefasst, das habe ich auch nie behauptet. Was ich schrieb ist dass ich für die Daten des Levels einen ausreichend großen Speicherblock im virtuellen Adressraum allokieren kann, in dem ich die Daten selbst verwalte, also über eine eigene kleine Speicherverwaltung anspreche. Wird der Level dann entladen, dann kann ich den gesamten Block freigeben, und vermeide somit jede Fragmentierung. Das geht aber nur dann, wenn der gesamte Level auf einmal in den Adressraum passt, also kein Streaming benötigt wird.

Du hast einfach nur ein Problem mir zu folgen, das ist alles. Schade für Dich.

[Grestorn]

Danke, das ist sicher ungleich komfortabler -- wobei ich noch nicht so davon überzeugt bin, daß das dynamische Nachladen von Objekten jetzt so komplex ist. Etwas derartiges habe ich auch schon gemacht (in deutlich kleineren Welten) und das war wahrlich nicht das größte Problem.

Das glaube ich Dir gerne. So lange Du weit vom Adressraumlimit weg bist, ist das auch gar kein Problem.

Bei Gothic3 sehen ich eher das Problem, daß zum einen der 32bit Adressraum fragmentiert, zum anderen das man nicht zuviel Content hat, sondern zuviel gleichzeitig im Speicher halten muß, weil man es mit dem was gleichzeitig angezeigt und verarbeitet werden soll, etwas übertrieben hat. Das ein Streaming System in solchen Grenzsituationen sicherlich aus dem letzten Loch pfeift ist klar.

Das stimmt sicherlich auch, aber warum sollen wir uns die Weitsichtigkeit und die AI einer virtuellen Welt von so etwas wie einem Adressraumlimit einschränken lassen?

Würde man Memory Mapped files denn unter 32bit überhaupt machen wollen, wenn man auch nur knapp 2GiB Content hat? Das nimmt ja auch bei 32Bit gleich schonmal eine ganze Menge Adressraum weg und der Rest mag durch jede Menge dynamischer Nutzdaten auch wieder schnell fragmentieren.

Ich denke, Memory Mapped Files werden in der einen oder anderen Form durchaus heute schon in Spielen genutzt, ich könnte mir das zumindest gut vorstellen. Natürlich geht Adressraum verloren, aber wenn in einem Spiel der Adressraum kein Problem ist, kann man so sehr elegant einen Level von der Platte in den Speicher befördern. Aber, damit AlphaTier was zu lästern hat, ich habe noch nie an der Entwicklung eines Spieles mitgewirkt, also geht mir in dieser Frage die First-Hand Experience ab.

Nichts desto trotz erkenne ich, wenn jemand Blödsinn schreibt...

[mekakic]

Das stimmt sicherlich auch, aber warum sollen wir uns die Weitsichtigkeit und die AI einer virtuellen Welt von so etwas wie einem Adressraumlimit einschränken lassen? Sollte man nicht müssen, da habe ich ja die gleiche Meinung; es ging mir nur um den Gesamtcontent der ganzen Welt als losgelöstes Problem ansich.

[del_4901]

Wenn Du größere Blöcke nimmst um auch kleinere Objekte darin abzulegen hast Du nur die Granularität vergrößert und am Problem selbst nichts geändert. Dann habe ich nur Verschnitt, den nehme ich bis zu einem gewissen Grad in kauf. Fuer noch keinere Bloecke gibt es eine extra Verwaltung, welche kleinere Bloecke verwaltet.
Z.B.: Nehmen wir an Dein Block ist 5kB groß (kannst jeden anderen Wert nehmen). Damit kostet erstens jedes Mini-Objekt schon mal 5 kB Platz. Aber damit ließe sich ja noch leben. Schlimmer ist aber, wenn ein Objekt mal mehr als 5kB braucht, dann musst Du nämlich eine Anzahl zusammenhängender Blöcke allokieren. Und hast letztlich wieder genau das selbe Problem, nur auf einer anderen, weil gröberen Ebene.

Tja, so wurdest Du das machen. Mehrere Bloecke fur ein Objekt zu nehmen ist natuerlich doof. Wenn man viele groessere Objekte hat nimmt man entweder groessere Bloecke, oder laesst es das OS machen.

Blöcke bilden - bei dynamischen Daten unterschiedlicher Größe - macht gar keinen Sinn.
Ey, bist wohl heute besonders begriffstutzig oder was? Natuerlich nur fuer Objekte gleicher Groesse.

Natürlich wird die Welt nicht als ein Teil aufgefasst, das habe ich auch nie behauptet. Was ich schrieb ist dass ich für die Daten des Levels einen ausreichend großen Speicherblock im virtuellen Adressraum allokieren kann, in dem ich die Daten selbst verwalte, also über eine eigene kleine Speicherverwaltung anspreche. Wird der Level dann entladen, dann kann ich den gesamten Block freigeben, und vermeide somit jede Fragmentierung. Ey Grestorn, langsam gehst du mir auf die Ketten, du wiederholst hier genau das, was ich seid 2 Seiten dir versuche zu verklickern. *gaehn* Du bist jetzt also mit diesem Verfahren einverstanden, dann hast du ja doch noch was gelernt, glueckwunsch fuer Dich, verdient hast du es eigentlich nicht.
Das fett gedruckte habe ich geschrieben, nicht du.

Du schriebst:

Wenn Du natürlich den ganzen Level en block lädst und hinterher den gesamten Block wieder freigibst wenn der Level nicht mehr benötigt wird, hast Du das Problem umgangen - wie die meisten Spiele. Für eine große Welt, die mehr Speicher braucht als Adressraum da ist, funktioniert diese Lösung nur nicht, ohne dass man sie doch wieder in kleinere Level aufteilt.

Level muessen nach dem allgemeinen Verstaendniss, der Spieler und Programmierer neu geladen werden. Das entspricht z.B nicht den Blaettern einer raeumlich unterteilten Datenstruktur.


Du hast einfach nur ein Problem mir zu folgen, das ist alles. Schade für Dich.
Sieh an, dass wollte ich grade dir vorschlagen.

[Exxtreme]

Greston & AlphaTier. Lasst den Kleinkrieg bitte sein oder führt den privat weiter. Möchte nur ungern Karten verteilen.



Danke.

[Grestorn]

Anmerkung: Dank des moderativen Ermahnung kürze ich mein Posting massiv, so dass alleine die Fakten stehen bleiben, die ich nicht unwidersprochen stehen lassen will:

Ey, bist wohl heute besonders begriffstutzig oder was? Natuerlich nur fuer Objekte gleicher Groesse.

Wovon reden wir eigentlich? Von irgendwelchen kleinen Objekten wie sie beim Programmieren ständig vorkommen und wie sie auch mal zu 1000en in irgendwelchen Listen stehen können oder von Daten für einen Level in einem Spiel, also umfangreiche, unterschiedlich große Daten wie eben Meshes, Texturen (die auch erst im Speicher stehen müssen bevor sie in die GraKa kommen, insbesondere wenn die Welt sehr groß ist) und andere hochkomplexe Datenstrukturen wie z.B. NPCs samt aller ihnen zugeordneter Items usw?

Ey Grestorn, langsam gehst du mir auf die Ketten, du wiederholst hier genau das, was ich seid 2 Seiten dir versuche zu verklickern. *gaehn* Du bist jetzt also mit diesem Verfahren einverstanden, dann hast du ja doch noch was gelernt, glueckwunsch fuer Dich, verdient hast du es eigentlich nicht.
Du hast einfach nur nicht verstanden, was ich ursprünglich geschrieben hatte. Ich hatte auch schon im ursprünglichen Posting, in dem ich diese (sehr offensichtliche und mir absolut nicht neue) Lösung skizierte, klar geschrieben warum dieses Prinzip eben nur bei verhältnismäßig kleinen Levels funktioniert.

[del_4901]

Wovon reden wir eigentlich? Von irgendwelchen kleinen Objekten wie sie beim Programmieren ständig vorkommen und wie sie auch mal zu 1000en in irgendwelchen Listen stehen können oder von Daten für einen Level in einem Spiel, also umfangreiche, unterschiedlich große Daten wie eben Meshes, Texturen (die auch erst im Speicher stehen müssen bevor sie in die GraKa kommen, insbesondere wenn die Welt sehr groß ist) und andere hochkomplexe Datenstrukturen wie z.B. NPCs samt aller ihnen zugeordneter Items usw?
Wir reden von allen Dingen die haeufig alloziiert und dealloziiert werden. Aber insbesondere bei den Blaettern von mehreren raeumlichen Datenstrukturen. (z.B. Quadtree) Mit denen alle Objekte in Spielen representiert werden muessen.


Du hast einfach nur nicht verstanden, was ich ursprünglich geschrieben hatte. Ich hatte auch schon im ursprünglichen Posting, in dem ich diese (sehr offensichtliche und mir absolut nicht neue) Lösung skizierte, klar geschrieben warum dieses Prinzip eben nur bei verhältnismäßig kleinen Levels funktioniert. Dann sage mir doch mal, wiso das bei einem grossen Level nicht gehen sollte? Die Groesse ist doch egal, weil jedes Level sowieso in gleich grosse Stueckchen zerhackt werden muss. Die sind natuerlich nicht immer genau gleich Gross, haben aber eine Maximalgroesse, die nicht ueberschritten werden kann, und genau dort setzt die blockbasierte Speicherverwaltung an. Das nennt man uebrigens auch Freispeicherlisten.

[Grestorn]

Wir reden von allen Dingen die haeufig alloziiert und dealloziiert werden. Aber insbesondere bei den Blaettern von mehreren raeumlichen Datenstrukturen. (z.B. Quadtree) Mit denen alle Objekte in Spielen representiert werden muessen.

Solche Datenstrukturen müssen auch nicht am Stück im Speicher liegen (bestenfalls deren Blätter, also Endnodes, die aber normalerweise auch einzeln nicht so besonders groß sind), deswegen sehe ich auch nicht, wo sie irgendein Problem sein sollten und warum man sich Gedanken machen müsste, hier eine Fragmentierung zu vermeiden.

Fragmentierung stört doch erst dann, wenn Datenblöcke mit einer gewissen nicht unerheblichen aber eben auch nicht gleichen Größe in größerer Zahl auftreten.

Dann sage mir doch mal, wiso das bei einem grossen Level nicht gehen sollte? Die Groesse ist doch egal, weil jedes Level sowieso in gleich grosse Stueckchen zerhackt werden muss. Die sind natuerlich nicht immer genau gleich Gross, haben aber eine Maximalgroesse, die nicht ueberschritten werden kann, und genau dort setzt die blockbasierte Speicherverwaltung an. Das nennt man uebrigens auch Freispeicherlisten.
Wieso muss ein Level in Stücke gehackt werden? Wie soll das mit einer Welt wie Gothic 3 überhaupt gehen, wenn man nicht mittendrin auf einmal eine harte Levelgrenze sehen will?

[del_4901]

Solche Datenstrukturen müssen auch nicht am Stück im Speicher liegen (bestenfalls deren Blätter, also Endnodes, die aber normalerweise auch einzeln nicht so besonders groß sind),
Ja, genau so war das auch geplant

deswegen sehe ich auch nicht, wo sie irgendein Problem sein sollten und warum man sich Gedanken machen müsste, hier eine Fragmentierung zu vermeiden.
Nein, denn das OS kann nicht wissen, dass ich in naher Zukunft nochmal so einen Quadtree-Block brauche, wie ich ihn gerade freigegeben habe. Wenn ich nun zwischenzeitlich einen kleineren Block alloziiere, kann es mir passiern, dass das OS genau in die Luecke einpasst, die ich ja eigentlich nochmal spaeter fuer einen Quadtree-Block verwenden wollte. Und genau dass ist externe Fragmentierung, genau das was ich eigentlich vermeiden wollte. Hier setzen die Freispeicherlisten an, und geben den Block eben nicht an das OS zurueck, sondern warten, bis wieder ein passgerechter Block benoetigt wird.


Fragmentierung stört doch erst dann, wenn Datenblöcke mit einer gewissen nicht unerheblichen aber eben auch nicht gleichen Größe in größerer Zahl auftreten. Das passiert sehr haufig, wenn man eben nicht Objekte gleicher Groesse in Freispeicherlisten verwaltet.

So hat man z.B ne Freispeicherliste fuer Events, eine fuer die Blaetter im Quadtree, eine fuer Nodes im Szenengraphen und und und.... Dank template Metaprogrammierung ist das auch nich wirklich aufwaendig.



Wieso muss ein Level in Stücke gehackt werden? Wie soll das mit einer Welt wie Gothic 3 überhaupt gehen, wenn man nicht mittendrin auf einmal eine harte Levelgrenze sehen will? Es wird buendig geschnitten, da sieht man keine Spalten oder Grenzen, wie gesagt, schau dir mal KD-Trees, Quadtrees, Octrees, BSP-Trees etc. an, dann weisst du wiso man zerkloppt. Die Anwendungen sind vielfaeltig und aus der heutigen Spielewelt nichtmehr wegzudenken.

[Gast]

Da ein Programm mit absoluten (virtuellen) Adressen arbeitet, kann das OS die nicht verschieben und damit auch nicht komprimieren. Was Du schreibst kann nicht funktionieren, nicht im virtuellen Adressraum!
Ja, hast recht.

Aber wäre nicht irgendein Mechanismus denkbar der die Adressen, die das Programm benutzt, kennt und entsprechend umbiegt? Ich meine, wenn ich 2000 Blöcke zu je 1MB allokiere und dann jeden zweiten freigebe, stehe ich vor der Situation dass ich 1 GB freien Speicher habe und trotzdem nicht 2 MB allokieren kann. Das ist doch dämlich. Das OS hätte doch die Möglichkeit die Adressen zu überwachen und entsprechend neu zu verteilen... oder nicht?

Man könnte doch in so einem Fall z.b. alle noch allokierten Blöcke in der Pagetable auf invalid setzen und ein "compaction bit" setzen. Beim nächsten Zugriff fliegt ein Pagefault, das OS erkennt das compaction bit und biegt die pointer entsprechend um. Es kann das weil es die Pointer kennt, die sind ja vorher zur Laufzeit alloziert worden. Geht natürlich nicht mit Adressen die zur Compilezeit generiert worden sind.

[Grestorn]

@Gast: Auch dann bräuchte das Programm ja immer noch eine Möglichkeit diese Daten eindeutig zu referenzieren. Also wiederum einen virtuellen Adressraum... womit sich der Kreis schließt.

Nämlich genau das gibt es ja schon: Einen virtuellen Adressraum der nach belieben auf den physischen Adressraum gemappt wird.

Das Mappen und der physische Adressraum sind beides nicht das Problem, sondern dass der virtuelle bei 32 bit eben auf gut 4 Milliarden eindeutige Adressen limitiert ist. Und um das zu ändern, hat man eine 64 bit Architektur eingeführt.

[Grestorn]

Es wird buendig geschnitten, da sieht man keine Spalten oder Grenzen, wie gesagt, schau dir mal KD-Trees, Quadtrees, Octrees, BSP-Trees etc. an, dann weisst du wiso man zerkloppt. Die Anwendungen sind vielfaeltig und aus der heutigen Spielewelt nichtmehr wegzudenken.

Ganz kurz nur: Ich brauche ja auch Daten aus weit entfernten Teilen, zumindest in einer Form die es mir ermöglicht auch entfernte Gegenden anzuzeigen.

Man kann das so machen, dass entfernte Gegenden in stark reduzierten Details vorhanden sind und nur eine Textur aufgepappt wird. Es gibt dann Zellen, die sich überlappen und das System hält immer eine begrenzte Zahl dieser Zellen im Speicher und lädt nach Bedarf weitere nach, wenn der Spieler sich bewegt. So ähnlich funktioniert wohl Oblivion.

Ich habe nie bestritten, dass man sich mit dem einen oder anderen Mittel auch mit auf 32 bit begrenztem Adressraum behelfen kann (lies einfach den Anfang meiner Diskussion in diesem Thread), aber egal wie man es anstellt: Bei zunehmend größeren Welten mit zunehmender Weitsicht kostet dass dem Entwickler immer mehr an extra Arbeit und auch extra Performance. Dein O(1) stimmt nämlich nur auf das einzelne Objekt bezogen - bei n Objekten sind wir ja schon bei O(n) - wie bei den meisten Dingen der täglichen Softwareentwicklung. Wenn auch nur linear, so doch ein Problem wenn nur n groß genug ist.

Und deswegen ist es sinnvoll und gut das ganze Problem ein und für alle mal mit einer Nutzung eines 64 bit Adressraums zu beheben.

[Gast]

@Gast: Auch dann bräuchte das Programm ja immer noch eine Möglichkeit diese Daten eindeutig zu referenzieren. Also wiederum einen virtuellen Adressraum... womit sich der Kreis schließt.

Nämlich genau das gibt es ja schon: Einen virtuellen Adressraum der nach belieben auf den physischen Adressraum gemappt wird.

Das Mappen und der physische Adressraum sind beides nicht das Problem, sondern dass der virtuelle bei 32 bit eben auf gut 4 Milliarden eindeutige Adressen limitiert ist. Und um das zu ändern, hat man eine 64 bit Architektur eingeführt.
Das ist mir schon klar.

Aber mit meinem Vorschlag könnte man in dem vorher konstruierten Fall (2000 mal 1 MB allozieren, dann jeden zweiten Block freigeben) noch immer 2 MB Speicher bekommen...auch 512MB...oder 800MB. Weil das OS die virtuellen Adressen entsprechend umgebogen hat sodass wieder ein großer zusammenhängender Bereich frei ist. Das war mein Vorschlag, und der funktioniert (auch!) mit 32bit. Dein Vorschlag ist einfach mit der 64bit Keuel zu kommen, das geht natürlich auch...

Vorausgesetzt natürlich der Vorschlag ist überhaupt umsetzbar. :D Äußerungen dazu?

[Grestorn]

Ein Programm greift nicht nur über die Startadresse eines Datenblocks auf diesen zu sondern erwartet, dass die Daten in dem Block in aufeinanderfolgenden Speicheradressen dahinter angeordnet sind und direkt durch Addition auf den Startpointer darauf zugegriffen werden kann.

Anders gesagt: Alle 4 Milliarden Adressen werden benötigt, da hilft kein Trick. Man kann nur die Zahl der Adressen erhöhen, und nichts anderes macht die Erweiterung auf 64 bit.

[del_4901]

Ganz kurz nur: Ich brauche ja auch Daten aus weit entfernten Teilen, zumindest in einer Form die es mir ermöglicht auch entfernte Gegenden anzuzeigen.
Und wo ist da das Problem?

Man kann das so machen, dass entfernte Gegenden in stark reduzierten Details vorhanden sind und nur eine Textur aufgepappt wird. Es gibt dann Zellen, die sich überlappen und das System hält immer eine begrenzte Zahl dieser Zellen im Speicher und lädt nach Bedarf weitere nach, wenn der Spieler sich bewegt. So ähnlich funktioniert wohl Oblivion.
So oder so ähnlich, auch wenn ich persöhnlich vom dem Zellensystem nicht viel halte.

Ich habe nie bestritten, dass man sich mit dem einen oder anderen Mittel auch mit auf 32 bit begrenztem Adressraum behelfen kann (lies einfach den Anfang meiner Diskussion in diesem Thread),
Memory Mapped IO ist einfach keine Alternative.

aber egal wie man es anstellt: Bei zunehmend größeren Welten mit zunehmender Weitsicht kostet dass dem Entwickler immer mehr an extra Arbeit und auch extra Performance. Dein O(1) stimmt nämlich nur auf das einzelne Objekt bezogen - bei n Objekten sind wir ja schon bei O(n) - wie bei den meisten Dingen der täglichen Softwareentwicklung. Wenn auch nur linear, so doch ein Problem wenn nur n groß genug ist.
Das ist bei Freispeicherlisten eben nicht so. O(1) Punkt aus, ohne aber. Zumal wo kommen wir denn da hin, ne Speicherverwaltung mit O(n) den Programmierer, der sowas verzapft, würde ich eigenhändig erwürgen.

Und deswegen ist es sinnvoll und gut das ganze Problem ein und für alle mal mit einer Nutzung eines 64 bit Adressraums zu beheben.
Wenn ich keine 64bit habe, kann ich Hoch und Tief springen, es wird sich nichts ändern. Und noch sind in den Konsolen keine 64bitter verbaut.

[del_4901]

Das ist mir schon klar.

Aber mit meinem Vorschlag könnte man in dem vorher konstruierten Fall (2000 mal 1 MB allozieren, dann jeden zweiten Block freigeben) noch immer 2 MB Speicher bekommen...auch 512MB...oder 800MB. Weil das OS die virtuellen Adressen entsprechend umgebogen hat sodass wieder ein großer zusammenhängender Bereich frei ist. Das war mein Vorschlag, und der funktioniert (auch!) mit 32bit. Dein Vorschlag ist einfach mit der 64bit Keuel zu kommen, das geht natürlich auch...

Vorausgesetzt natürlich der Vorschlag ist überhaupt umsetzbar. :D Äußerungen dazu?

Also wenn ich das richtig verstanden habe wird das sogar so gemacht. Das OS verwaltet die sogenannten Abbildungstabellen, dort kann jede Page im virtuellem Adressraum, einem Frame im physischen Speicher zugeordnet werden. Die Ordnung dabei darf sich natürlich ändern, solange komplette Pages frei werden. Halbe Dinge können natürlich nicht gemacht werden, es dürfen nur Pages auf andere Frames umgebogen werden, welche leer sind.

[Grestorn]

Memory Mapped IO ist einfach keine Alternative.

Warum nicht?

Das ist bei Freispeicherlisten eben nicht so. O(1) Punkt aus, ohne aber. Zumal wo kommen wir denn da hin, ne Speicherverwaltung mit O(n) den Programmierer, der sowas verzapft, würde ich eigenhändig erwürgen.
O(n) ist der Standard, wenn man keine Maßnahmen dagegen ergreift. Wenn Du n Objekte anlegst, hast Du n Allokationen und - ohne extra Maßnahmen - auch wieder n Freigaben.

Dass es Tricks gibt das zu vermeiden, wissen wir beide. Dass diese Tricks im Allgemeinen weder nötig sind noch angewand werden, auch. In so fern ist Deine Aussage, einen solchen Programmierer zu erwürgen, schon sehr bezeichnend. Fang schon mal mit fast allen C++ Programmierern an, die nur new und delete nutzen.

Aber wahrscheinlich hattest Du nur mich im Kopf, den Du ja so gerne würgen oder noch schlimmeres würdest, wie Du mir ja eben erst privat versichert hast... :)

Wenn ich keine 64bit habe, kann ich Hoch und Tief springen, es wird sich nichts ändern. Und noch sind in den Konsolen keine 64bitter verbaut.

Dass man mit dem auskommen muss, was man hat, ist doch klar. Darum dreht es sich aber in diesem Thread nicht! Es dreht sich darum, was 64bit für Vorteile bringen kann, und warum diese nicht genutzt werden.

[Grestorn]

Also wenn ich das richtig verstanden habe wird das sogar so gemacht. Das OS verwaltet die sogenannten Abbildungstabellen, dort kann jede Page im virtuellem Adressraum, einem Frame im physischen Speicher zugeordnet werden. Die Ordnung dabei darf sich natürlich ändern, solange komplette Pages frei werden. Halbe Dinge können natürlich nicht gemacht werden, es dürfen nur Pages auf andere Frames umgebogen werden, welche leer sind.

Ich glaubs nicht. Du hast mal wieder nichts verstanden... Da kann man echt nur mit dem Kopf schütteln.

Immer noch nicht begriffen, was ein virtueller Adressraum ist, und warum man so viel auf physischen oder sonstigen Speicher zuordnen kann wie man will, und deswegen dennoch nicht mehr eindeutig adressierbare Bytes bekommt und trotzdem in die Fragmentierungsfalle läuft, es sei denn, man setzt eine GarbageCollection ein?

[del_4901]

Warum nicht?

Weil man damit nicht die Fragmentierung bekämpft, das ist nichts anderes als ein erweitertes malloc. Genauso lahm, wenn nicht sogar noch lahmer, aber das müsste man mal testen.

Ich glaubs nicht. Du hast mal wieder nichts verstanden... Da kann man echt nur mit dem Kopf schütteln.

Immer noch nicht begriffen, was ein virtueller Adressraum ist, und warum man so viel auf physischen oder sonstigen Speicher zuordnen kann wie man will, und deswegen dennoch nicht mehr eindeutig adressierbare Bytes bekommt und trotzdem in die Fragmentierungsfalle läuft, es sei denn, man setzt eine GarbageCollection ein?

Was war denn da nun schonwieder dran falsch?

O(n) ist der Standard, wenn man keine Maßnahmen dagegen ergreift. Wenn Du n Objekte anlegst, hast Du n Allokationen und - ohne extra Maßnahmen - auch wieder n Freigaben.

Dass es Tricks gibt das zu vermeiden, wissen wir beide. Dass diese Tricks im Allgemeinen weder nötig sind noch angewand werden, auch. In so fern ist Deine Aussage, einen solchen Programmierer zu erwürgen, schon sehr bezeichnend. Fang schon mal mit fast allen C++ Programmierern an, die nur new und delete nutzen.

Du weißt aber schon das das Standart OS Platzierungstrategien wie z.B First-Fit einen average Case von O(m) m<<n bei der allokation haben. Nur die deallokation ist mit O(1) genauso günstig, da muss aber nochmal verschmolzen werden, ok das ist auch blos O(1) also nicht der rede wert.

[Grestorn]

Weil man damit nicht die Fragmentierung bekämpft, das ist nichts anderes als ein erweitertes malloc. Genauso lahm, wenn nicht sogar noch lahmer, aber das müsste man mal testen.

Das musst Du mir erklären. Zunächst geht es ja um statische, unverändlerliche Daten (veränderbare Daten würde ich nicht in einem Memory Mapped File ablegen, wozu auch), sprich den statischen Weltdaten. Und fragmentieren kann das überhaupt nicht, weil Du kein einziges malloc oder free brauchst. Du hast einfach schlagartig alle Objekte Deines Levels im virtuellen Speicher und kannst nach Belieben darauf zugreifen. Den Rest erledigt das OS.

Was war denn da nun schonwieder dran falsch?

Du betonst, dass das OS es so macht, wie der Gast vorschlägt. Damit hast Du vollkommen Recht. Du unterschlägst aber, dass das das Problem kein bisschen behebt. Die Problematik des begrenzten Adressraums und dessen Fragmentierung bleibt.

[del_4901]

Das musst Du mir erklären. Zunächst geht es ja um statische, unverändlerliche Daten (veränderbare Daten würde ich nicht in einem Memory Mapped File ablegen, wozu auch), sprich den statischen Weltdaten. Und fragmentieren kann das überhaupt nicht, weil Du kein einziges malloc oder free brauchst. Du hast einfach schlagartig alle Objekte Deines Levels im virtuellen Speicher und kannst nach Belieben darauf zugreifen. Den Rest erledigt das OS.
Das Problem ist doch, das wir nicht alle Objekte schlagartig in den Speicher bekommen, darum dreht es sich doch die ganze Zeit.


Du betonst, dass das OS es so macht, wie der Gast vorschlägt. Damit hast Du vollkommen Recht. Du unterschlägst aber, dass das das Problem kein bisschen behebt. Die Problematik des begrenzten Adressraums und dessen Fragmentierung bleibt.
Wenn wir das nicht hätten, würde unser alles OS jeden Tag einmal wegen Fragmentierung abstürzen. Warscheinlich sogar eher.

[Coda]

Was mich diesbezüglich als Laie auch immer interessiert hat, Datenträger lassen sich real defragmentieren, ein virtuelles Adressraum nicht? :frown:
Ein "Moving Garbage Collector" kann das oder auch eine eigene Speicherverwaltung, aber nicht die normal verwendete Methode der Speicherallozierung.

Die eigene Speicherverwaltung ist aber einfach schon wieder unnötiger Aufwand.

Weil man damit nicht die Fragmentierung bekämpft, das ist nichts anderes als ein erweitertes malloc. Genauso lahm, wenn nicht sogar noch lahmer, aber das müsste man mal testen.
Ich ging bisher davon aus dass MMIO einen physikalischen Speicherbereich als Cache verwendet und dort eben die Daten auf die man gerade zugreift reinkopiert und entsprechend auf die virtuellen Adressen einblendet. Das ist definitiv schneller als ein malloc.

[del_4901]

Die eigene Speicherverwaltung ist aber einfach schon wieder unnötiger Aufwand. Ich habe Tests gefahren mit um bis 500x besserer Performance gegenüber der Speicherverwaltung des Betriebssystems. Schon allein das rechtfertigt eine eigene kleine Speicherverwaltung. Zumal es nur einem Tag Arbeit entspricht. Von der externen Fragmentierfreiheit mal ganz abgesehen.


Ich ging bisher davon aus dass MMIO einen physikalischen Speicherbereich als Cache verwendet und dort eben die Daten auf die man gerade zugreift reinkopiert und entsprechend auf die virtuellen Adressen einblendet. Das ist definitiv schneller als ein malloc.
Also ich gebe bisher davon aus das MMIO allerhand möglichen Gerätespeicher in den virtuellen Adressraum einblendet. z.B ein Stück HDD Speicherplatz. Dabei wird immer der komplette Speicherplatz eingeblendet, halbe Sachen gibt es auch bei MMIO nicht. MMIO ist eine Systemfunktion, und benötigt daher einen Softwareinterrupt zur Ausführung ... und genau das ist es was malloc und mmap so langsam macht. Ob das nun im RAM gecached wird, weiß ich nicht, ich glaube aber schon das die das machen.

[Gast]

Ein "Moving Garbage Collector" kann das oder auch eine eigene Speicherverwaltung, aber nicht die normal verwendete Methode der Speicherallozierung.

Die eigene Speicherverwaltung ist aber einfach schon wieder unnötiger Aufwand.
[...]

Also ist es prinzipiell machbar Compaction auf den virtuellen Adreesraum anzuwenden. Warum macht man das nicht standardmäßig? Dann hätte man keine Probleme dass der virtuelle Adressraum so fragmentiert dass man keine 5MB zusammenhängenden (virtuellen) Speicher mehr bekommt obwohl insgesamt genug frei wären.

[del_4901]

Also ist es prinzipiell machbar Compaction auf den virtuellen Adreesraum anzuwenden. Warum macht man das nicht standardmäßig? Dann hätte man keine Probleme dass der virtuelle Adressraum so fragmentiert dass man keine 5MB zusammenhängenden (virtuellen) Speicher mehr bekommt obwohl insgesamt genug frei wären.
Macht man doch, das nennt sich dann Java und/oder C#. C/C++ ist halt zu doof dazu, es sei denn man implementiert sich seinen eignenen GC ... das ist dann aber wirklich eine hässliche Angelegenheit und nicht an einem Tag zu schaffen.

[Coda]

Also ist es prinzipiell machbar Compaction auf den virtuellen Adreesraum anzuwenden. Warum macht man das nicht standardmäßig? Dann hätte man keine Probleme dass der virtuelle Adressraum so fragmentiert dass man keine 5MB zusammenhängenden (virtuellen) Speicher mehr bekommt obwohl insgesamt genug frei wären.
Wenn man new und delete verwendet ist es eben nicht machbar durch das OS.

Selbst wenn es die App selber macht ist es nur praktisch anwendbar wenn die Objektgrößen bekannt sind und nur ein paar verschiedene davon.

Ich habe Tests gefahren mit um bis 500x besserer Performance gegenüber der Speicherverwaltung des Betriebssystems. Schon allein das rechtfertigt eine eigene kleine Speicherverwaltung. Zumal es nur einem Tag Arbeit entspricht. Von der externen Fragmentierfreiheit mal ganz abgesehen.
Also für die, die ich in einem kritischen Loop allozieren muss würde ich natürlich auch kein new/delete verwenden, aber ansonsten ist es einfach viel Aufwand alles von Hand im Speicher zu verteilen.

Also ich gebe bisher davon aus das MMIO allerhand möglichen Gerätespeicher in den virtuellen Adressraum einblendet. z.B ein Stück HDD Speicherplatz. Dabei wird immer der komplette Speicherplatz eingeblendet, halbe Sachen gibt es auch bei MMIO nicht. MMIO ist eine Systemfunktion, und benötigt daher einen Softwareinterrupt zur Ausführung ... und genau das ist es was malloc und mmap so langsam macht. Ob das nun im RAM gecached wird, weiß ich nicht, ich glaube aber schon das die das machen.
Das müsste man mal klären bevor wir hier weiterdiskutieren. Imho würde das den Sinn nehmen bei der Sache.

Wenn ich das hier so lese http://en.wikipedia.org/wiki/Memory-mapped_file dann meine ich das ich recht habe.

[Gast]

Macht man doch, das nennt sich dann Java und/oder C#. C/C++ ist halt zu doof dazu, es sei denn man implementiert sich seinen eignenen GC ... das ist dann aber wirklich eine hässliche Angelegenheit und nicht an einem Tag zu schaffen.
Ich meine auf OS-Ebene, nicht auf Applikationsebene. Mir schwebt vor dass das alles transparent für die Anwendung ist, so wie halt z.b. virtuelle Adressen. Das Betriebssystem übernimmt für dich die Compaction und du kriegst gar nichts mit. Aber laut Coda ist es wohl auf OS-Ebene nicht so einfach möglich.

[Coda]

Das Problem dabei ist ganz einfach, dass man in C++ so alloziert:

int *pointer = new int;

Dann hat die App einfach eine feste Variable mit der Speicheradresse, d.h. das OS kann den allozierten int nicht einfach verschieben. Und wo der Pointer überall hinkopiert wurde und verwendet wird weiß es auch nicht. Das ist eben nur mit einer Sprache möglich die keine Pointer kennt und wird das dann auch von der Runtime gemacht und nicht vom OS.

Macht man doch, das nennt sich dann Java und/oder C#. C/C++ ist halt zu doof dazu, es sei denn man implementiert sich seinen eignenen GC ... das ist dann aber wirklich eine hässliche Angelegenheit und nicht an einem Tag zu schaffen.
Haben .NET und die Java VM wirklich einen Moving-GC?

Das macht nämlich Probleme sobald man andere Sprachen anbinden möchte usw.

[Grestorn]

Das Problem ist doch, das wir nicht alle Objekte schlagartig in den Speicher bekommen, darum dreht es sich doch die ganze Zeit.Warum sollte man das wollen? Man will nur die Objekte im Speicher haben, die man braucht. Bei einem MemoryMapped File werden nur die Pages in den physischen Speicher geladen, auf die zugegriffen wird.

Wenn wir das nicht hätten, würde unser alles OS jeden Tag einmal wegen Fragmentierung abstürzen. Warscheinlich sogar eher.
Wieso denn das? In einem OS laufen unzählige Prozesse und jeder Prozess hat seinen eigenen Adressraum von 2GB, die er üblicherweise nicht mal annähernd nutzt.

[del_4901]

Selbst wenn es die App selber macht ist es nur praktisch anwendbar wenn die Objektgrößen bekannt sind und nur ein paar verschiedene davon. Beim alloziieren bekomm ich ne Größe immer mitgeliefert, nur beim löschen wirds kniffelig, da muss man sich dann was ausdenken.


Also für die, die ich in einem kritischen Loop allozieren muss würde ich natürlich auch kein new/delete verwenden, aber ansonsten ist es einfach viel Aufwand alles von Hand im Speicher zu verteilen.
So ein Template ist Ruck Zuck geschrieben, das wundert mich jetzt aber das du als Profi da von viel Aufwand sprichst. Das ist nur ein bissel new und delete überladen und gut is. Es währe natürlich noch interessant alle gleich großen Objekte in einer Freiliste zu verwalten, dann wird das löschen ein wenig teurer, dann muss man einmal eine Adresse Hashen. O(log(n)) damit kan ich auch noch leben.


Das müsste man mal klären bevor wir hier weiterdiskutieren. Imho würde das den Sinn nehmen bei der Sache. Im Falle von Memmory Mapped File ist es schon schneller als fseek und konsorten, da fseek ja auch wieder Systemaufrufe sind, wenn ich also in der Datei umherspule spring ich also ständig in den Kernel. Außerdem muss kopiert werden. Bei mmap springe ich einmal in den Kernel und mappe mir das File in den v. Adressraum. Dabei belege ich die komplette Anzahl virtueller Adresssen, welche die Datei benötigt. Die Datei wird nur teilweise in die Frames gelegt. Greife ich auf eien Page zu, die nicht gemappt wird, werden die Daten in ein on demand Frame geladen. Das kann sehr hässlich werden, ist aber immernoch um Dimensionen besser als jedesmal den Kernel zu besuchen.

Haben .NET und die Java VM wirklich einen Moving-GC?
Also soviel wie ich weiß sind das eh Mischformen, und damals als ich bei meinem OS Prof (Beste Grüße an Prof. Nolte) noch mallochen durfte, hat er sowas erwähnt, das zumindestens Java damit arbeitet.

[Grestorn]

Also ist es prinzipiell machbar Compaction auf den virtuellen Adreesraum anzuwenden. Warum macht man das nicht standardmäßig? Dann hätte man keine Probleme dass der virtuelle Adressraum so fragmentiert dass man keine 5MB zusammenhängenden (virtuellen) Speicher mehr bekommt obwohl insgesamt genug frei wären.

Wie gesagt, das ist GarbageCollection und die SW muss damit umgehen können. Sprich, statt direkt auf die Objekte im Speicher zuzugreifen, muss vor jedem Zugriff eine Tabelle befragt werden, in der nur die Anfangsadressen der Blöcke verzeichnet sind. Bei einer GarbageCollection wird diese Tabelle aktualisiert.

Das kann aber das OS alleine nicht machen, weil übliche Programme direkt auf den Speicher und das auch wahlfrei zugreifen. Nur in "höheren" Programmiersprachen, wie Java oder C#, wo man als Programmierer keinen direkten Zugriff auf den Speicher hat, kann man das "hinter dem Rücken" des Programmierers machen.

In C++ geht das auch, aber nur wenn der Programmierer das selbst so wünscht und sich auch entsprechend diszipliniert.

[Coda]

Beim alloziieren bekomm ich ne Größe immer mitgeliefert, nur beim löschen wirds kniffelig, da muss man sich dann was ausdenken.
Wenn du unterschiedliche Größen hast kannst du aber nicht effizient suchen wenn du mal was zwischendrin freigegeben hast. Dann reimplementierst du auch nur malloc wenn du nicht irgendwelche Einschränkungen voraussetzt.

Im Falle von Memmory Mapped File ist es schon schneller als fseek und konsorten, da fseek ja auch wieder Systemaufrufe sind, wenn ich also in der Datei umherspule spring ich also ständig in den Kernel. Außerdem muss kopiert werden. Bei mmap springe ich einmal in den Kernel und mappe mir das File in den v. Adressraum. Dabei belege ich die komplette Anzahl virtueller Adresssen, welche die Datei benötigt. Die Datei wird nur teilweise in die Frames gelegt. Greife ich auf eien Page zu, die nicht gemappt wird, werden die Daten in ein on demand Frame geladen. Das kann sehr hässlich werden, ist aber immernoch um Dimensionen besser als jedesmal den Kernel zu besuchen.
Dann ist genau wo das Problem an memory mapped files?

[del_4901]

Wenn du unterschiedliche Größen hast kannst du aber nicht effizient suchen wenn du mal was zwischendrin freigegeben hast. Dann reimplementierst du auch nur malloc wenn du nicht irgendwelche Einschränkungen voraussetzt. Jetzt ist der nächste der hier auf unterschiedlichen Größen rumreitet. Alle Objekte haben gleiche größe, ich muss nichts verschmelzen, kein gar nichts. Wenn ich mehrere Größen haben möchte, dann brauche ich für jede Größe einen extra Speichermanager der Größe X, oder ich nehme Teilweisen Verschnitt in kauf, oder beides. Ich glaube ich weiß wo es hapert. es gibt einen globalen new Operator, und einen für jede Klasse, die kann ich extra überladen. Man sollte es tunlichst vermeiden den globalen new Operator zu überladen, wenn man nicht grade sein eigenes OS implementiert.


Dann ist genau wo das Problem an memory mapped files?
Warum sollte man das wollen? Man will nur die Objekte im Speicher haben, die man braucht. Bei einem MemoryMapped File werden nur die Pages in den physischen Speicher geladen, auf die zugegriffen wird.
Da schlage ich mal 2 Fliegen mit einer Klappe. MMF belegen immer den kompletten Adressraum der Datei ... ist meine Datei 2GB groß, sind 2GB vom Virtuellem Arbeitspeicher futsch und ich könnte theoretisch nur noch 2GB für den Rest der Anwendung nutzen.(32bitter) Also bringt es mir gar nichts wenn ich das komplette File mit MMF in den Speicher packe. Bei einem 64bitter kann man sich das leisten, aber da muss man eh nicht auf Fragmentierung achten.

[Coda]

Alle Objekte haben gleiche größe...
Das habe ich doch oben auch gesagt? Aber das ist nunmal nicht immer gegeben. Und ich weiß, dass man new überladen kann und was placement new ist. Danke ;)

Da schlage ich mal 2 Fliegen mit einer Klappe. MMF belegen immer den kompletten Adressraum der Datei ... ist meine Datei 2GB groß, sind 2GB vom Virtuellem Arbeitspeicher futsch und ich könnte theretisch nur noch 2GB für den Rest der Anwendung nutzen. Also bringt es mir gar nichts wenn ich das komplette File mit MMF in den Speicher packe. Bei einem 64bitter kann man sich das leisten, aber da muss man eh nicht auf Fragmentierung achten.
Darum geht's doch die ganze Zeit, dass man sich das mit 64 bit leisten kann aber mit 32 bit eben nicht und deshalb andere Klimmzüge veranstalten muss, die eigentlich nicht nötig wären.

Mit 64 bit könnte man die ganze Welt einfach in ein Memory Mapped File und hätte umsonst caching etc. ohne das man da groß viel rumschreiben muss dafür.

[del_4901]

Darum geht's doch die ganze Zeit, dass man sich das mit 64 bit leisten kann aber mit 32 bit eben nicht und deshalb andere Klimmzüge veranstalten muss, die eigentlich nicht nötig wären.

Mit 64 bit könnte man die ganze Welt einfach in ein Memory Mapped File und hätte umsonst caching etc. ohne das man da groß viel rumschreiben muss dafür.
Wenn das dann mal irgendwann soweit ist, das jeder nen 64er neben den Fernseher stehen hat, mach ich das auch. Solange muss ich mit Klimmzügen leben, die ich jetzt aber auch nicht so schlimm finde. Wobei eines doch noch für den eigenen Speichermanager spicht. Das OS kann nicht wissen welche Pages gerade augelagert werden können, da ist die eigene Anwendung im Vorteil, die kann viel feingranularer bestimmen was weggeschmissen werden darf, und was nicht. Das kann unter Umständen teuer werden diese Aufgabe an das OS abzuschieben.
Also zur Ergänzung ist es sicherlich nicht schlecht.

Aber das ist nunmal nicht immer gegeben.
Ich habe auch nur davon geredet, wo es Sinn macht bzw. nötig ist. Und das sind verdammt viele Fälle. Stell dir mal vor du hast durch deine komplette SW eine Rohrpost verlegt. Wenn du jedesmal vom System neu Speicher holst, nur weil du grade ne Rohrpost verschicken möchstest, dann kannst du auch den Azubi das erledigen lassen, der kocht dann nebenbei sogar noch für dich Kaffee.

[(del)]

Schon erstaunlich, aber es klappt immer wieder ;) Durch an sich dümmliches Gequatsche sehr interessante Gesprächsrunden anzuleiern :up:

So lernt man dazu. Danke an die Geeks für die sehr interessanten Infos. Was bleibt ist noch die Frage, ob der Projektmanager lügt oder einfach das sagt was er erlebt, betreut und selbst programmiert. Ich würde sagen, der Typ wird wohl hier keine Märchen erzählen. Von daher...

Exxtreme, die Idee mit Kacheln ist prima ;) So stell ich mir das vor. Den Schwächeren im Thread schuldest du aber noch eine Erklärung ;)Ja, muss es bzw. dem Programm muss irgendwie bekannt gemacht werden, daß da noch mehr ist.Das weiß der VLC mit seiner Playlist noch. Hier greift die Analogie noch. Aber...
Und der Mechanismus für die "Bekanntmachung" ist leider selbst von der 32-Bit-Regel betroffen.aus welcher Notwendigkeit sich DAS ergibt, das verstehe ich noch nicht. Das was AlphaTier&Co nun besprechen ist nur ein weiterer Aspekt des Problems. Mich interessiert aber zuerst das obenerwähnte. Und dafür finde ich hier noch keine Erklärung.

Ich hoffe auch, da ich wohl die nächsten 2 Tage nicht "hier" bin, daß im weiteren Verlauf auch die letzten begreifen, daß die Frage danach warum manche Studios mit "Kacheln" überhaupt nicht klar kommen und das es doch wohl bitte wirklich nicht dermassen saugen kann wie es G3 tut, nichts mit einer Abneigung gegenüber 64bit zu tun hat.
"Ja aber mit 64bit hat die Probleme dann gar nicht blah blah" hat zB. mit meinen Fragen nichts zu tun. ich selbst habe nie nach den Vorteilen der 64bit gefragt. Einige andere auf den letzten Seiten auch nicht.

G3 ist diesbezüglich Crap, Oblivion rennt. Crysis auch. Es braucht zwar Power, hat aber nicht mit für den Spieler lästigen Speicherproblemen zu kämpfen. Auch im Freien nicht.
Das ist die Realität. Unter 32bit. Mit Unterschieden in der Grafik und Sichtweiten die nur ein 3DCenter-Member bemerkt. Wenn überhaupt.

Warum das bei Spielen mit gleichem Umfang und ähnlicher "Aufmachung" mal geht und mal nicht kann also nicht mit den Beschränkungen von 32bit Systemen zusammenhängen. Es sei den man sieht das im dem Kontext wie er hier im Beitrag 376 steht...

Viel Spaß noch ;)

[Aquaschaf]

G3 ist diesbezüglich Crap, Oblivion rennt. Crysis auch. Es braucht zwar Power, hat aber nicht mit für den Spieler lästigen Speicherproblemen zu kämpfen. Auch im Freien nicht.

Oblivion hat mit seinem Zellensystem stark sichtbare LoD-Grenzen. Und bei Crysis musste die Spielwelt in mehr und in kleinere Level aufgeteilt werden als geplant. Das heißt in einem Fall haben die Einschränkungen durch 32bit eine sichtbare Auswirkung auf die Grafik, im anderen Fall sogar auf Spiel- und Leveldesign.

[Xmas]

Wie gesagt, das ist GarbageCollection und die SW muss damit umgehen können. Sprich, statt direkt auf die Objekte im Speicher zuzugreifen, muss vor jedem Zugriff eine Tabelle befragt werden, in der nur die Anfangsadressen der Blöcke verzeichnet sind. Bei einer GarbageCollection wird diese Tabelle aktualisiert.
Das ist eine Möglichkeit, hier wird auch von Handles gesprochen. Die sind wegen der doppelten Dereferenzierung für die Performance allerdings eher nachteilig, weswegen es auch die Speicherverwaltung ohne Handles gibt, bei der die Referenzen direkt Speicheradressen darstellen. Auch hier ist ein Compacting GC möglich, nur müssen dann tatsächlich alle Referenzen die auf das Objekt zeigen geändert werden. Suns Hotspot VM macht dies so.

[Gast]

Oblivion hat mit seinem Zellensystem stark sichtbare LoD-Grenzen. Und bei Crysis musste die Spielwelt in mehr und in kleinere Level aufgeteilt werden als geplant. Das heißt in einem Fall haben die Einschränkungen durch 32bit eine sichtbare Auswirkung auf die Grafik, im anderen Fall sogar auf Spiel- und Leveldesign.Aber nur, weil du diese Infos mitbekommen hast. Sonst könntest du oder wir nur wage Mußmaßungen anstellen. So glasklar ist das in den meisten Fällen nicht, wenn man keine zusätzliche Hintergrundinfos hat.
Die Einschränkungen dessen was man pro Level oder pro Zelle ungestreamt zu sehen bekommt sind klar. Das ist nicht das Thema.

[Grestorn]

So lernt man dazu. Danke an die Geeks für die sehr interessanten Infos. Was bleibt ist noch die Frage, ob der Projektmanager lügt oder einfach das sagt was er erlebt, betreut und selbst programmiert. Ich würde sagen, der Typ wird wohl hier keine Märchen erzählen. Von daher...

Wenn Dir der nötige technische Background fehlt, solltest Du Dich mit solchen Festlegungen lieber zurückhalten, finde ich.

[Grestorn]

Das ist eine Möglichkeit, hier wird auch von Handles gesprochen. Die sind wegen der doppelten Dereferenzierung für die Performance allerdings eher nachteilig, weswegen es auch die Speicherverwaltung ohne Handles gibt, bei der die Referenzen direkt Speicheradressen darstellen. Auch hier ist ein Compacting GC möglich, nur müssen dann tatsächlich alle Referenzen die auf das Objekt zeigen geändert werden. Suns Hotspot VM macht dies so.

Das geht natürlich auch, dann dauert die GarbageCollection einen Tick länger, dafür ist der Programmablauf nen Tick effizienter. Wahrscheinlich ein guter Trade-Off. Am Grundprinzip ändert das - wie Du selbst ja schreibst - gar nichts.

[Gast]

Wenn Dir der nötige technische Background fehlt, solltest Du Dich mit solchen Festlegungen lieber zurückhalten, finde ich.
Das behauptet ja genau der richtige Quatschkopf. Getreu dem Motto: Alles was ich selber tu, das trau ich jedem anderen zu.

[Grestorn]

Das behauptet ja genau der richtige Quatschkopf. Getreu dem Motto: Alles was ich selber tu, das trau ich jedem anderen zu.

Ich habe den technischen Background. Wenn Du anderer Meinung bist, dann weise mir erst mal einen Fehler in einem meiner Beiträge hier im Thread nach.

[mekakic]

G3 ist diesbezüglich Crap, Oblivion rennt. Crysis auch. Es braucht zwar Power, hat aber nicht mit für den Spieler lästigen Speicherproblemen zu kämpfen. Auch im Freien nicht. Also die Weltdarstellung und Grafik finde ich doch deutlich weiter in G3 als in Oblivion, allein das wirklich nirgends harte Levelgrenzen vorkommen macht den Job um sovieles schwieriger. Außerdem sollte man bei der Bewertung von bsp. G3 (aber auch anderen Titel) etwas vorsichtig sein, da das Spiel ja nun positiv ausgedrückt leicht unfertig auf den Markt kam. Vielleicht ist die Technik dahinter ja auch sehr gut, es fehlte nur an etwas Tuning am System (die berühmten 2 Monate) damit es sich auch im richtigen Licht präsentieren kann, jetzt trägt es nur das Kleid der unfertigen Software und das sieht nie gut aus.

Btw: man sollte mal einen Aufruf an Spellbound richten für den CP1.7 das ganze gleichzeitig als 64bit Version zu veröffentlichen - dann könnte man so schön vergleichen (so groß sollte der Aufwand ja nicht sein). :)

[Exxtreme]

Das weiß der VLC mit seiner Playlist noch. Hier greift die Analogie noch. Aber...
Ich verstehe deine Analogie mit der Playlist nicht, sorry.

[HOT]

[...]

Btw: man sollte mal einen Aufruf an Spellbound richten für den CP1.7 das ganze gleichzeitig als 64bit Version zu veröffentlichen - dann könnte man so schön vergleichen (so groß sollte der Aufwand ja nicht sein). :)
Ein 64Bit Kompilat von G3 als Testversion wäre eine klasse Sache, das stimmt.

[HeyArnoldo]

nur mal ne kurze Frage...
Die n64 hatte doch schon 64bit...Wahrscheinlich sind die aktuellen Konsolen (kenn mich da nich so aus..) mittlerweile schon bei 128bit....?
Es scheint also auch für Spiele durchaus interessant zu sein.
Liegt´s wirklich nur am os, daß wir immer noch mit 32bit (wie lang is das mit der n64her?? 12Jahre?) rumeiern, oder ist das programieren der Anwendungen und spiele in 64bit wirklich soviel komplizierter??

[Exxtreme]

nur mal ne kurze Frage...
Die n64 hatte doch schon 64bit...Wahrscheinlich sind die aktuellen Konsolen (kenn mich da nich so aus..) mittlerweile schon bei 128bit....?
Es scheint also auch für Spiele durchaus interessant zu sein.
Liegt´s wirklich nur am os, daß wir immer noch mit 32bit (wie lang is das mit der n64her?? 12Jahre?) rumeiern, oder ist das programieren der Anwendungen und spiele in 64bit wirklich soviel komplizierter??
Du solltest nicht die Registerbreite mit der Breite der Datenbusse verwechseln. Sind zwei Paar Stiefel.

[Ganon]

Du solltest nicht die Registerbreite mit der Breite der Datenbusse verwechseln. Sind zwei Paar Stiefel.

Wobei es beim N64 (obwohl es eine 64bit CPU war, mit 32bit System-Bus) sowieso nicht auf die Speichergrenzen ankam, bei 8MB RAM :D

[Ganon]

Wahrscheinlich sind die aktuellen Konsolen (kenn mich da nich so aus..) mittlerweile schon bei 128bit....?

Aktuelle Konsolen sind weiterhin bei 32/64bit, wie damals auch schon ;) Die Bit-Zahlen sind sowieso nichtssagen, bei Konsolen.

[HeyArnoldo]

Und wieder ein bischen schlauer..=)

[Exxtreme]

Btw: man sollte mal einen Aufruf an Spellbound richten für den CP1.7 das ganze gleichzeitig als 64bit Version zu veröffentlichen - dann könnte man so schön vergleichen (so groß sollte der Aufwand ja nicht sein). :)
Wird wohl nicht so einfach sein, fürchte ich bzw. man wird durch einfaches Neukompilieren die Probleme nicht wegbekommen. Ist der gesamte Content und die Engine auf "Wir umschiffen die 32-Bit-Hürden" ausgelegt dann wird die Neukompilierung keine Wirkung zeigen denn das Programm wird sich weiterhin wie ein 32-Bit-Programm verhalten.

[Grestorn]

Wird wohl nicht so einfach sein, fürchte ich bzw. man wird durch einfaches Neukompilieren die Probleme nicht wegbekommen. Ist der gesamte Content und die Engine auf "Wir umschiffen die 32-Bit-Hürden" ausgelegt dann wird die Neukompilierung keine Wirkung zeigen denn das Programm wird sich weiterhin wie ein 32-Bit-Programm verhalten.

jein. Sie haben ja schon einen Speichermanager, der einen Cache verwaltet und automatisch bereinigt. Wenn der mit 64 bit arbeitet und die Cache-Größen entsprechend erweitert werden, müsste das durchaus gehen. Insbesondere wenn deswegen keine Bereinigung mehr notwendig wird (weil der Adressraum dann kein Problem ist) - denn die ist für die meisten heftigen Ruckler verantwortlich - laut Aussage in deren Forum.

[mekakic]

Ein Problem könnte evtl. sein, das bestimmte Middleware vielleicht außer als 32Bit lib nicht zur Verfügung steht bzw. was ein einfaches Neukompilieren (und dadurch kostenlose Mitnahme des größeren Adressraums) verhindert.

Wie würde man denn am besten eine derartige Anfrage absetzen, damit das nicht in irgendeinem Help-Desk-Loch verschwindet, sondern an der Quelle ankommt?

[del_4901]

jein. Sie haben ja schon einen Speichermanager, der einen Cache verwaltet und automatisch bereinigt. Wenn der mit 64 bit arbeitet und die Cache-Größen entsprechend erweitert werden, müsste das durchaus gehen. Insbesondere wenn deswegen keine Bereinigung mehr notwendig wird (weil der Adressraum dann kein Problem ist) - denn die ist für die meisten heftigen Ruckler verantwortlich - laut Aussage in deren Forum.
Das schwarz markiere sorgt nicht fuer die Ruckeler, nichtmal indirekt.
Die hefitigen Rucker kommen einzig und allein, vom Nachladen der Daten(von Platte) in den RAM. Wenn du das vom OS ueber MMF in 64bit erledigen laesst, kann es nur noch schlimmer werden, da das OS sowas nur "on demand" macht. Aehnlich schlimm sieht es bei der auslagerungs Strategie beim auslagern aus. Also je mehr ich ueber diese Geschichte nachdenke, umso bekloppter finde ich das Ganze. Die eigene Speicherverwaltung kann da viel bessere Vorhersage- und Ersetzungstrategien fahren als das OS.

[Grestorn]

Das schwarz markiere sorgt nicht fuer die Ruckeler, nichtmal indirekt.
Die hefitigen Rucker kommen einzig und allein, vom Nachladen der Daten(von Platte) in den RAM. Wenn du das vom OS ueber MMF in 64bit erledigen laesst, kann es nur noch schlimmer werden, da das OS sowas nur "on demand" macht. Aehnlich schlimm sieht es bei der auslagerungs Strategie beim auslagern aus. Also je mehr ich ueber diese Geschichte nachdenke, umso bekloppter finde ich das Ganze. Die eigene Speicherverwaltung kann da viel bessere Vorhersage- und Ersetzungstrategien fahren als das OS.

Gut dass Du das so genau weiß, sogar so genau dass Du damit explizit dem Readme der 1.6 widersprechen kannst ... :)

Wieso sollte eine Bereinigung (was nichts anderes als eine Art GarbageCollection im Objektcache von G3 sein dürfte) nicht für Ruckler verantwortlich sein? Während einer solchen GC kann kein Thread auf die Daten in dem vom Speichermanager verwalteten Cache zugreifen. Das führt natürlich zu einem Ruckler.

Was Du bekloppt findest haben wir in diesem Thread ja schon reichlich erlebt. Ich mache mir mal eine Regel daraus, alles was Du für bekloppt hältst nochmal extra in Augenschein zu nehmen, es gibt eine gute Chance, das da was wertvolles dabei ist ...

[del_4901]

Gut dass Du das so genau weiß, sogar so genau dass Du damit explizit dem Readme der 1.6 widersprechen kannst ... :)

Wieso sollte eine Bereinigung (was nichts anderes als eine Art GarbageCollection im Objektcache von G3 sein dürfte) nicht für Ruckler verantwortlich sein? Während einer solchen GC kann kein Thread auf die Daten in dem vom Speichermanager verwalteten Cache zugreifen. Das führt natürlich zu einem Ruckler.
Dann tuts mir leid, aber die sind dann einfach zu doof sowas richtig zu implementieren. Ich nehm doch keine allgemeine Ersetzungstrategie, wenn ich eine Spezielle, z.B in Abhaenigkeit von der Spielerkamera, fahren kann. Wenn ich mich dabei nicht ganz dumm anstelle, kann ich Synergieeffekte durch Interprozesskollisionen vermeiden.

[mekakic]

Selbst wenn man von der RamDisk spielt, gibt es aber "Nachlade"-Ruckler, sie sind deutlich reduziert, aber immernoch ruckelt es in unregelmäßigen Abständen kurz bzw. beim Betreten komplexer Bereiche.

[del_4901]

Selbst wenn man von der RamDisk spielt, gibt es aber "Nachlade"-Ruckler, sie sind deutlich reduziert, aber immernoch ruckelt es in unregelmäßigen Abständen kurz bzw. beim Betreten komplexer Bereiche.
Quelle?

[mekakic]

Ich spiele es auf einer 3.7GB RamDisk und im World-of-Gothic Forum noch ein paar andere (dort habe ich das auch schon gelesen).

[del_4901]

Ich spiele es auf einer 3.7GB RamDisk und im World-of-Gothic Forum noch ein paar andere (dort habe ich das auch schon gelesen).
Ohne ausgetuefftelte Testreihen, wuerde ich mich nicht dazu hinreissen lassen, dass es allein daran liegt.

[Coda]

Kann doch sein dass Gothic beim nachladen auch noch ne Weile rumrechnet auf den Daten. Würde mich jetzt nicht wundern.

[del_4901]

Kann doch sein dass Gothic beim nachladen auch noch ne Weile rumrechnet auf den Daten. Würde mich jetzt nicht wundern.
Mich auch nicht, ist aber nur Spekulation. Fuer den Fall, dass dem so waere, wieso berechnet man nicht die Sachen, bevor man Sie braucht in einem extra Thread, so dass sie vorhanden sind wenn Sie gebraucht werden.

[PHuV]

Selbst wenn man von der RamDisk spielt, gibt es aber "Nachlade"-Ruckler, sie sind deutlich reduziert, aber immernoch ruckelt es in unregelmäßigen Abständen kurz bzw. beim Betreten komplexer Bereiche.

Das kann ich nur bestätigen, ich habe damals auch einen Test mit Ramdisk und I-Ram (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=329090&highlight=I-Ram+Ramdisk) gemacht, und dort das gesamte Gothic 3 kopiert, der einzige Unterschied waren die Ladezeiten am Anfang des Spieles, die Ruckler traten trotzdem genau so auf.

Das schwarz markiere sorgt nicht fuer die Ruckeler, nichtmal indirekt.
Die hefitigen Rucker kommen einzig und allein, vom Nachladen der Daten(von Platte) in den RAM. Wenn du das vom OS ueber MMF in 64bit erledigen laesst, kann es nur noch schlimmer werden, da das OS sowas nur "on demand" macht. Aehnlich schlimm sieht es bei der auslagerungs Strategie beim auslagern aus. Also je mehr ich ueber diese Geschichte nachdenke, umso bekloppter finde ich das Ganze. Die eigene Speicherverwaltung kann da viel bessere Vorhersage- und Ersetzungstrategien fahren als das OS.

Definitiv falsch, weil die praktische Erfahrung etwas anders liefert. Eine Ramdisk oder das I-Ram hatten Zugriffszeiten 1ms< und Übertragungsraten bei I-Ram von ca 120 MB/s, bei der Ramdisk sogar ca 2000-3450 MB/s, und trotzdem waren die Ruckler deutlich zu beobachten und wahrzunehmen. Deine Erklärung greift hier also nicht.

[del_4901]

Definitiv falsch, weil die praktische Erfahrung etwas anders liefert. Eine Ramdisk oder das I-Ram hatten Zugriffszeiten 1ms< und Übertragungsraten bei I-Ram von ca 120 MB/s, bei der Ramdisk sogar ca 2000-3450 MB/s, und trotzdem waren die Ruckler deutlich zu beobachten und wahrzunehmen. Deine Erklärung greift hier also nicht.
Wie Coda schon gesagt sagt, das kann duraus sein, das die mit den Meshes noch was machen ... in die gamespezifische Datenstrutur umrechen... was auch immer. Sowas passiert halt, wenn ich immer alles auf den letzten Drücker mache. Worauf ich eigentlich hinaus wollte, das OS macht sowas immer auf den letzten Drücker, und das kann nicht gut sein. Außerdem kann man aus deiner praktischen Erfahrung noch lange nicht den Umkehrschluss ziehen, wer weiß wie verfriemelt die Testrechner sind, oder die Bandbreite an anderer Stelle wird knapp (Übertragung zur GPU) auf dem Weg von Platte (IRAM/Ramdisk) zu, Monitor gibt es soviele Zwischenstationen, wo überall was schieflaufen kann.

[(del)]

Also die Weltdarstellung und Grafik finde ich doch deutlich weiter in G3 als in Oblivion, allein das wirklich nirgends harte Levelgrenzen vorkommen macht den Job um sovieles schwieriger.Die "Levelgrenzen" sind durch die loadfreezes genauso hart wie in Doom3... Nein sorry, sie sind viel schlimmer.

Außerdem sollte man bei der Bewertung von bsp. G3 (aber auch anderen Titel) etwas vorsichtig sein, da das Spiel ja nun positiv ausgedrückt leicht unfertig auf den Markt kam.Wenn das eine Begründung sein soll, dann dürfte man auch kein Haushaltsgerät bewerten, der nach 2 Tagen auseinander fällt, weil irgendwelche Schrauben im Inneren nicht nachgezogen wurden :|

@Exxtreme
Ich verstehe deine Analogie mit der Playlist nicht, sorry.
Ja klar. Verstehe. Nicht schlimm :D :uup:

Ich verstehe halt das andere nicht. Sorry.

[mekakic]

Die Levelgrenzen sind durch die loadfreezes härter als in Doom3...Doom3 habe ich nie gespielt, aber erstens spiele ich von Ramdisk, da sind die deutlich reduziert; zweitens empfand ich die auch auf Festplatte als nicht so störend wie die festen Ladebildschirme in Oblivion, The Witcher oder ähnliches. Dazu sind sie eben dynamisch und erlauben auch eine ganz andere Welt, in der man eben in alle Bereiche reingucken kann, die sonst durch harte Levelgrenzen einfach abgeschnitten werden, oder echtes Licht was nachts aus Fenstern herauskommt u.ä.. Das ist schon ein Unterschied.

Wenn das eine Begründung sein soll, dann dürfte man auch kein Haushaltsgerät bewerten, der nach 2 Tagen auseinander fällt, weil irgendwelche Schrauben im Inneren nicht nachgezogen wurden :|Das Produkt mag da vielleicht nicht gut sein, die Technik (um die es geht hier gerade) aber vielleicht schon. Genau diese Unterscheidung meinte ich. Nur wegen eines in der Hinsicht mangelhaften Produkts, nicht einen 1:1 Rückschluß auf die Technik zu ziehen.

[(del)]

Nur wegen eines in der Hinsicht mangelhaften Produkts, nicht einen 1:1 Rückschluß auf die Technik zu ziehen.Nun. Daß man das auch unter 32bit vernünftig hinbekommen könnte ist auch meine Meinung...
Die Probleme die hier gemalt werden sehe ich einfach nicht.

[Exxtreme]

@Exxtreme

Ja klar. Verstehe. Nicht schlimm :D :uup:

Ich verstehe halt das andere nicht. Sorry.
Die Analogie greift deshalb nicht weil die Playlist nicht "weiss" welcher Content sich hinter der besagten MP3 befindet. Du kannst nicht mittels Playlist die 20'ste Sekunde des Songs x anspringen. Du kannst nur Song x anspringen, musst dann aber manuell auf auf die 20'ste Sekunde spulen.

Von daher ist die Playlist kein guter Vergleich. Die Playlist "weiss" halt nicht was sie kennt. Ein Programm muss aber die Dinge kennen von denen es weiss.

[Grestorn]

Nun. Daß man das auch unter 32bit vernünftig hinbekommen könnte ist auch meine Meinung...
Die Probleme die hier gemalt werden sehe ich einfach nicht.

Was wohl daran liegt, dass Du nicht viel von der Programmierung verstehst, und von den Problemen große Datenmengen dynamisch zu verwalten. Das ist ja auch nicht schlimm, nur solltest Du Dich dann aus der Diskussion besser etwas raushalten.

[Gast]

Was wohl daran liegt, dass Du nicht viel von der Programmierung verstehst, und von den Problemen große Datenmengen dynamisch zu verwalten. Das ist ja auch nicht schlimm, nur solltest Du Dich dann aus der Diskussion besser etwas raushalten.Deine Tipps werden mit der Zeit nicht besser. Sie werden nur arroganter. Habe ich hier schon jemanden erzählt, es ist nicht so wie er sagt, sondern eben so und so? Und solange ich B nicht 100% nachvolliehen kann bleibt A erstmal gültig.
Aber über "Einschiessen" rumjaulen. Ich kann deine hinterlästige arrogante Art nicht leiden. Das hatten wir schon. Es ist wirklich traurig, daß ich dich dauernd dran erinnern muß.

@Exxtreme
Geht klar. Du verstehst es also doch ;) Und auch die "Schwächen" dieser Ideen. Ok. Was ist aber, wenn jede Datei einen kleinen Inhaltsverzeichnis mit sich führen würde? Quasi als Header. Ich was (Playlist) in welcher Datei sich das benötigte befindet. Wenn ich sie hab, kann ich aus dem Header schnell auslesen wo denn nun das liegt wa sich brauche. Nicht? Plus managment dessen. Ich kann manche dazugekommenen Infos behalten, manche verwerfe ich usw. Grob beschrieben.

Ich muß doch nicht ALLES gleichzeitig wissen (?) Ich muß nur wissen. Davon ab ist mir noch nicht ganz klar was die Größe des Contents mit der Menge des Contents zu tun hat. Ich kann auch küntliche aus 20 Dateien und 10 Objekten 5GB content erzeugen.

[Grestorn]

Deine Tipps werden mit der Zeit nicht besser. Sie werden nur arroganter. Habe ich hier schon jemanden erzählt, es ist nicht so wie er sagt, sondern eben so und so? Und solange ich B nicht 100% nachvolliehen kann bleibt A erstmal gültig.
Aber über "Einschiessen" rumjaulen. Ich kann deine hinterlästige arrogante Art nicht leiden. Das hatten wir schon. Es ist wirklich traurig, daß ich dich dauernd dran erinnern muß.

Ich kann's ja nicht ändern, es ist nun mal wie es ist. Wenn Du schreibst dass Du die Probleme mit 32bit Adressraum nicht nachvollziehen kannst, dann solltest Du Dich auch einfach aus der Diskussion raushalten. Das hat gar nichts mit Arroganz zu tun.

Ich meine, Du erzählst auch keinem Arzt wie er seinen Job machen sollst und maulst ihn an, dass er arrogant wäre, wenn er Dich dann darauf hinweist, dass Du ihm gerade auf seinem Spezialgebiet erklären willst, wie es richtig gemacht wird.

Ich muß doch nicht ALLES gleichzeitig wissen (?) Ich muß nur wissen. Davon ab ist mir noch nicht ganz klar was die Größe des Contents mit der Menge des Contents zu tun hat. Ich kann auch küntliche aus 20 Dateien und 10 Objekten 5GB content erzeugen.

Du musst nicht alles gleichzeitig wissen, aber Du musst alles schnell im Zugriff haben KÖNNEN wenn Du es brauchen solltest. Natürlich kann man so etwas wie eine "Playlist" machen (man nennt das dann Objekttabelle) in der verzeichnet ist, ob ein Objekt geladen ist und wo es im Adressraum tatsächlich gerade liegt - und, falls es noch nicht im Speicher liegt, gegebenenfalls nachladen, sobald darauf zugegriffen wird. Genau das wird ja wohl auch gemacht in Gothic3.

Aber da das Zeug ja auch wieder aus dem Speicher entfernt werden muss (um für andere Objekte Platz zu schaffen, man nimmt da meist eine Strategie wie "lösche die am längsten nicht benötigten Objekte zuerst") entstehen eben die bereits beschriebenen Löcher im Adressraum, die eine effiziente Nutzung des Adressraums immer schwerer machen. Wenn diese Fragmentierung zu schlimm wird, was nur passiert, wenn der Datenbedarf in der selben Größenordnung wie der Adressraum ist (also 0,5-2 GB), dann bleibt nichts anderes übrig, als die Objekte im Adressraum ab und zu "aufzuräumen", sprich neu anzuordnen so dass keine Löcher im Adressraum mehr da sind. Durch Anpassung der "Playlist" (also der Objekttabelle) kann das Programm auch danach die Objekte noch finden.

Das kannst Du Dir ganz ähnlich vorstellen wie bei einem RPG mit einem Raster in Inventory für die Items die Du mit Dir rumträgst (z.B. Diablo 2). Die Items nehmen unterschiedlichen Platz ein, und wenn sie ungünstig angeordnet sind, dann kriegst Du ein größeres Objekt nicht mehr unter, obwohl es eigentlich in der Summe noch ausreichend Platz gäbe. Räumst Du das Inventory auf, passt es wieder wunderbar rein.

Genau das ist aber die schon so oft beschriebene GarbageCollection und die hat den Nachteil, dass während der Collection das Programm stehen muss - und das führt wiederum zu Rucklern in 3D Echtzeitspielen wie Gothic 3.

[Exxtreme]

@Exxtreme
Geht klar. Du verstehst es also doch ;) Und auch die "Schwächen" dieser Ideen. Ok. Was ist aber, wenn jede Datei einen kleinen Inhaltsverzeichnis mit sich führen würde? Quasi als Header. Ich was (Playlist) in welcher Datei sich das benötigte befindet. Wenn ich sie hab, kann ich aus dem Header schnell auslesen wo denn nun das liegt wa sich brauche. Nicht? Plus managment dessen. Ich kann manche dazugekommenen Infos behalten, manche verwerfe ich usw. Grob beschrieben.

Ich muß doch nicht ALLES gleichzeitig wissen (?) Ich muß nur wissen. Davon ab ist mir noch nicht ganz klar was die Größe des Contents mit der Menge des Contents zu tun hat. Ich kann auch küntliche aus 20 Dateien und 10 Objekten 5GB content erzeugen.
So wird das wohl heute schon gemacht. Nur musst du bedenken, daß deine geladenen Daten eben nie eindeutig sind. Denn nicht die eindeutige Adresse bestimmt die Gültigkeit der Daten sondern die Position des Chars in der Spielewelt etc. Die entscheidet was rausgeschmissen und was geladen wird. Und hier können schon paar Fehler passieren. Kann mir vorstellen, daß das ein netter Spielstandkiller ist.

[(del)]

Ich kann's ja nicht ändern, es ist nun mal wie es ist.Keine Panik. Meine Erwartungen an dich sind entsprechend.

Natürlich kann man so etwas wie eine "Playlist" machen (man nennt das dann Objekttabelle) in der verzeichnet ist, ob ein Objekt geladen ist und wo es im Adressraum tatsächlich gerade liegt - und, falls es noch nicht im Speicher liegt, gegebenenfalls nachladenWarum muß ein Objekt im Adressraum liegen, wenn es noch nicht einmal geladen wurde? Ich glaub das präzisiert jetzt meine vorhergehenden Fragen recht gut.

@Exxtreme
Wann soll der Spielstand denn gekillt werden? Meinst du solche Probleme schon während der Entstehung oder nach Updates?

Das ist jetzt aber ein drittes Thema. Das eine ist die Größe des Contents, da andere die Menge des Contents und das dritte wären jetzt die Spielstände. Wir müßen irgendwo aufhören, wenn wir irgendwo anfangen wollen ;)

Ich bleib erstmal beim letzten Beitrag von Alphatier hängen. Bis dann mal.

[Coda]

BH du stellst eindeutig die falschen Fragen.

Da müsste man jetzt die komplette Geschichte der virtuellen Speicherverwaltung in einen Post reinbringen was einfach nicht möglich ist. Entweder du willst es nicht verstehen oder aber du bekommst es so niemals erklärt.

[del_4901]

BH du stellst eindeutig die falschen Fragen.

Da müsste man jetzt die komplette Geschichte der virtuellen Speicherverwaltung in einen Post reinbringen was einfach nicht möglich ist. Entweder du willst es nicht verstehen oder aber du bekommst es so niemals erklärt.

Vllt. kannst du ihm ja auch einfach 2-3 Internetquellen für die Anwesenden raussuchen? In der Zeit wo du deinen schönen Text hier verfasst hast, hab ich mal im Netz geschaut was es so gibt.

Ich muss zugeben, es sind nicht alle Links für Jedermann geeignet, einiges ist ganz schönes Holz, aber das hilft vllt. dabei die richtigen Fragen zu stellen.

http://www.ceesar.ch/cms/upload/pdf/infotronic/06_Speichermanagement_Printed.pdf
http://www.0x90.org/releases/memory.pdf
http://www.eng.umd.edu/~blj/papers/asplos98.pdf
http://oreilly.com/catalog/linuxdrive3/book/ch15.pdf
http://www.linuxhq.com/guides/TLK/mm/memory.html
http://www.intellectualheaven.com/Articles/WinMM.pdf

[(del)]

Danke Alphatier. Gibts nachmittags was zu lesen.

Ich stell mir gerade vor, ich bekomme mal wieder einen frischen Azubi für ne Woche aufs Auge gedrückt, der fragt mich etwas und ich erkläre ihm, die Frage ist falsch und ich kann sie nicht beantworten. Wenn er im zweiten Lehrjahr ist, dann weiß er wie er mich das fragen soll. Dann reden wir nochmal.
Der wäre nicht angepinkelt oder verschämmt, der hätte sich über mich in der Pause kaputtgelacht und ich würde den Aufkleber "Freak" bis zum Ende des Berufslebens nicht loswerden :D Man ihr seid mir echt Experten des höhsten Grades ;)

Als wenn ich jemanden der nicht weiß aus was sich ein TCP/IP-Paket zusammensetzt, den Sinn und "die Grundsätze der Funktionsweise" einer Domäne nicht erklären könnte. Dann würd ich mir aber Gedanken machen...

Ja ich check mal aus hier. Ich fange gleich mit der Architektur einer MMU an und kämpfe mich bis zum Kernel und AMD64 durch. Vielleicht kann ich bis zum Herbst was vernünftiges Fragen :biggrin:

Übrigens scheint bei dem Rest der sich dann traute mit mir mitzuschwimmen das Licht auch nicht so besonders aufgegangen zu sein. Irgendwie schwach der Thread hier ;)

War trotzdem nett mit euch. Mit den meisten jedenfalls :tongue:

EOD

[Coda]

Wir sind hier auch nicht deine Lehrer sondern stehen freiwillig zur Verfügung. Das ist der große Unterschied.

[Coda]

Ihr könnt davon halten was ihr wollt aber ich steh genau dazu. Wer in einem Technikforum etwas wissen will der muss auch etwas Willen dazu zeigen. Bei BH sehe ich davon nicht viel.

Und wer nichtmal die Courage hat sich hier einzuloggen bevor er solche Stammtischparolen ablässt ist auch ein ganz armes Würstchen. Ich habe es hier noch nie nötig gehabt auch nur einen Post als Gast zu verfassen und das wird sich auch nicht ändern.