Ich hatte mir ein gutes MMX erhofft, doch es war vergeblich dank Ubi Soft

[AchtBit]

Ist ja nicht zu fassen was die sich leisten. Der 32Bit User ist voll angeschmiert. Die Audioausgabe ist aufs Minimum und die Texturqualität auf Mittel limitiert, wenn ein 32bit OS verwendet wird. Ich würde nicht mal meckeren, wenns wenigstens teilweise 64bit unterstützen tät, aber es ist nativ 32bit only. Das ist einfach eine Frechheit. Vom User gleich noch eine Betriebssystemwechsel zu erwarten, der überhaubt nicht notwendig ist, sondern einfach nur das Resultat von, entweder zu wenig Zeit für ein Speichermanagement oder pure Marktstrategie, um den User zum Systemwechsel zu drängen.

Ich glaub eher ersteres trifft zu. Ich hab das Programm mal überwacht und das Resultat ist klar ersichtlich, das Game alloziert solange Ram, bis der Hauptprozess komplett physisch ins Ram passt. Die etwa 1,5gb privater Ram führen zwangsläufig dazu, das jede Spitze im gemeinsam genutzte Speicher, Windows dazu bewegt den den gesamten virtuellen Speicher für das Game zu vergrössern. Und zwar knallhart bis zum 2gb limit bevor eine Auslagerung erfolgt. Die Arschkarte hat derjenige, in dem Fall ich, wer 4gb Ram und 2gb VRam auf einem 32Bit OS betreibt. Der Grund, sobald der virtuelle Speicher ca. 2000MB erreicht hat dann passt nicht mehr viel zw. Game Speicher und Graka Adressraum. Das Game kackt einfach ab. Das passiert leider immer dann wenn man die Gegend wechselt, da entstehen kurzfristig Spitzen die den virtuellen Speicher auf über 2000MB schiessen, was letztendlich dann zum crash führt.

Leider bei meiner HW config unumgänglich aber zum glück konnte ich mir, 2x1gb Speicher, für 14,50 bei Ebay angeln. Immer noch besser wie ein Systemwechsel. Trotzdem finde ich das unter aller Saubär von Ubi was die mit den Kunden treiben.

 

[Stueppi]

Ich schätze mal das die Entwickler davon ausgehen das PC Spieler zu zeiten der PS4 und XBone, die technisch gesehen nur Mittelgut sind, einen PC besitzen der 64 Bit hat und 8Gig Ram. Wenn sich jemand weigert jahrelang nicht aufzurüsten hat meiner ansicht nicht das Recht zu jammern das 2014er Spiele nicht mehr für 2006er PCs entwickelt werden, sondern an den neuen Maßstäben angelehnt werden.

 

[NatokWa]

Mal davon abgesehen das es NICHT an Ubisoft liegt ... das Game wird nur uber Ubisoft (UPlay) GESTARTET weil Ubi die Rechte an der Might and Magic Reihe hat und diese nicht rausrückt . MM-X ist ein INDI !!!! Game .

Außerdem ..... wer Gurkt denn noch mit 32Bit rum heutzutage ??? Dein Rechner packt locker 64 Bit ... und Win7 ist nun wirklich net mehr teuer , also komm mal runter und installiers dir .....

 

[Lelwani]

Ist ja nicht zu fassen was die sich leisten. Der 32Bit User ist voll angeschmiert. Die Audioausgabe ist aufs Minimum und die Texturqualität auf Mittel limitiert, wenn ein 32bit OS verwendet wird. Ich würde nicht mal meckeren, wenns wenigstens teilweise 64bit unterstützen tät, aber es ist nativ 32bit only. Das ist einfach eine Frechheit. Vom User gleich noch eine Betriebssystemwechsel zu erwarten, der überhaubt nicht notwendig ist, sondern einfach nur das Resultat von, entweder zu wenig Zeit für ein Speichermanagement oder pure Marktstrategie, um den User zum Systemwechsel zu drängen.

Ich glaub eher ersteres trifft zu. Ich hab das Programm mal überwacht und das Resultat ist klar ersichtlich, das Game alloziert solange Ram, bis der Hauptprozess komplett physisch ins Ram passt. Die etwa 1,5gb privater Ram führen zwangsläufig dazu, das jede Spitze im gemeinsam genutzte Speicher, Windows dazu bewegt den den gesamten virtuellen Speicher für das Game zu vergrössern. Und zwar knallhart bis zum 2gb limit bevor eine Auslagerung erfolgt. Die Arschkarte hat derjenige, in dem Fall ich, wer 4gb Ram und 2gb VRam auf einem 32Bit OS betreibt. Der Grund, sobald der virtuelle Speicher ca. 2000MB erreicht hat dann passt nicht mehr viel zw. Game Speicher und Graka Adressraum. Das Game kackt einfach ab. Das passiert leider immer dann wenn man die Gegend wechselt, da entstehen kurzfristig Spitzen die den virtuellen Speicher auf über 2000MB schiessen, was letztendlich dann zum crash führt.

Leider bei meiner HW config unumgänglich aber zum glück konnte ich mir, 2x1gb Speicher, für 14,50 bei Ebay angeln. Immer noch besser wie ein Systemwechsel. Trotzdem finde ich das unter aller Saubär von Ubi was die mit den Kunden treiben.

Bin ich zublöde oder kappier ich grad nich was du willst? heulst du rum das du nur ein 32 bit system hast oder heulst du rum das das spiel nur aufm 32bit läuft?

 

[Freakless08]

Ich schätze mal das die Entwickler davon ausgehen das PC Spieler zu zeiten der PS4 und XBone, die technisch gesehen nur Mittelgut sind, einen PC besitzen der 64 Bit hat und 8Gig Ram.

Nein. Würdest du dir die Minimale und Normale Systemkonfiguration anschauen steht hier dabei das 32bit und 4GB unterstützt werden. Also daran wird es wohl nicht liegen.

Wenn sich jemand weigert jahrelang nicht aufzurüsten hat meiner ansicht nicht das Recht zu jammern das 2014er Spiele nicht mehr für 2006er PCs entwickelt werden, sondern an den neuen Maßstäben angelehnt werden.

Eher wird schlampiger programmiert so das viel Rechenzeit eher für unnötige Sachen draufgehen, denn "man hat genug Power die das irgendwie überspielt damit man nichts merkt".

 

[AchtBit]

Nochmal zum mitschreiben, 64bit OS tendieren noch immer mehr in Richtung Resourcenverschwendung als in Richtung Leistungsverbesserung. Weshalb sollte ich ein OS installieren, für das weniger als 20%, der vorhandenen Software, mit nativer Unterstützung existieren? KVG, weist was das heißt!?

MMX ist auf dem technischen Standard von vor 10 Jahren

Und es ist ein reines 32bit Programm, das unerklärlicherweise nur auf einem 64bit OS voll funktioniert. Die Frage ist eh mehrfach, in unterschiedlichen Formulierungen, im Homeforum drinne. Es ist bisher noch keine Antwort erfolgt. Da warten schon viele.

Nein. Würdest du dir die Minimale und Normale Systemkonfiguration anschauen steht hier dabei das 32bit und 4GB unterstützt werden. Also daran wird es wohl nicht liegen.

Na dann guck mal ins offizielle Forum. Da herrscht mächtig dicke Luft, was ich durchaus verstehe.

 

[VikingGe]

Nochmal zum mitschreiben, 64bit OS tendieren noch immer mehr in Richtung Resourcenverschwendung als in Richtung Leistungsverbesserung. Weshalb sollte ich ein OS installieren, für das weniger als 20%, der vorhandenen Software, mit nativer Unterstützung existieren?

Also dass die Software-Industrie in der Windows-Welt (und irgendwie auch nur da) bei nativem 64bit-Support auch mehr als eine Dekade nach dem Athlon 64 und den ersten 64bit-Pentium IVs sowie mehr als vier Jahre nach dem Release von dem als 64bit-Version absolut brauchbaren Windows 7 nicht aus dem Quark kommt, ist jetzt nicht die Schuld von Windows oder von Microsoft.

Ich meine, mich regt das auch auf, dass RAM-Fresser wie Skyrim nicht als native 64bit-Version kommen, weil die nicht nur performancemäßig profitieren würden, sondern eben auch von dem erweiterten Addressraum. Das war im Jahre 2011 schon arm und das heute erst recht arm. Aber trotzdem, wenn die Entwickler 10 Jahre nach der Einführung einer heute längst etablierten Technologie verlangen, dass ihre Nutzer darauf setzten, dann sollen sie es meinetwegen tun - welches Spiel läuft rein leistungsmäßig noch auf Rechnern von vor 10 Jahren? Da wirds ja selbst bei den anspruchslosesten aller Indie-Games knapp.

Ob das im konkreten Fall nun technisch irgendwie zu rechtfertigen ist, ist zwar eine andere Sache, aber genau so gibt es aus technischer Sicht keinen Grund, 32bit-Systeme auf 64bit-Hardware laufen zu lassen. Und jetzt komm mir nicht mit den paar Prozent Größenunterschied.

 

[AchtBit]

Ob das im konkreten Fall nun technisch irgendwie zu rechtfertigen ist, ist zwar eine andere Sache, aber genau so gibt es aus technischer Sicht keinen Grund, 32bit-Systeme auf 64bit-Hardware laufen zu lassen. Und jetzt komm mir nicht mit den paar Prozent Größenunterschied.

Genau so wenig kann man ein 64bit OS rechtfertigen, denn defakto existiert weder für low Level noch für hi Level eine native 64bit Programmiersprache. 64Bit Unterstützung ist bei einigen wenigen Tools manuell optimiert, um so effizient wie möglich die 64bit Registerbreite zu nutzen. Die meisten 64bit Unterstützungen sind mittels einer Routine, die den Maschinencode automatisch für optimale 64bit Busbreitennutzung, compiliert. auto optimierter Code erreicht max. 80% Effizienz. Handopotimiert bis zu 95%. Schliesslich ist es aber nur ein 32bit Source Code denn es gibt nicht mehr als ein paar vereinzelte Klassen Objekte die tatsächliche native 64bit Methoden und Funktionen bieten. Das Grow in allen Sprachen, sind Elemente, die 32 bit, 16 bit , 8 bit breite Maschinen Funktionen, in Form eines Befehl, Funktion, Parameter oder Operator je Sprache, unterschiedlich bezeichnen. Je nach Sprache gibt es Befehle die bis zu 4 Maschinen Instruktion zusammenfassen und eine varible Menge an Daten gleichzeit verarbeiten können. Ums ganz klar zu sagen, für Befehlssätze die Code erzeugen um eine zeitnahe Opcode Encodierung zu gewährleisten, sind mit 32bit bereits optimal performant. Gelinde gesagt sind 64bit Makros ineffektiv. Ich bin eza ned ganz sicher, aber ich glaube x86 Instruktionen sind encodiert, bis zum Faktor 8 verkleinert und math. Operanden um den Faktor 2.

Blah Blah hin Bok Bok her, 64bit Instruktionen sind unötige Resourcenfresser, denn allgemein besteht die Datenverarbeitung, wie das Wort schon sagt, zu 80% aus Daten, unterschiedlicher Art und Grösse. 64Bit bringen nur Vorteile wenn all Grössen < 64bit restlos in 64bit Musterblöcke zusammengesetzt werden können. Zu 95% wahrscheinlich. Sinnlos für multimediatypische Flussdaten von 32 - 64bit weil die keine Perfomance von der Datenbusbreite gewinnen sondern von einer Registerreihnenschaltung(8x64bit pro Takt oder 8 processing Ticks per Takt) die bis 512 bit je Takt verarbeiten können.

Summa Sumarum,

Adressierung 64bit

wer, ausser Perry Rodan, besitzt einen Positronenrechner der entsprechend viel Slots fürs Dimm parat stellt????
der Rest ist verschwendete noop, 2.5x je Takt + CPU Leistungsverlust für Addressierung von bis zu 64bit Address Reichweiten

contra 64bit OS

Speichereffizienz 64bit

unter Standard Bedingungen, ist ein Mehrbedarf an Ram von 20 - 30% realistisch. Wer dafür einen Performance - Gewinn erwartet, der wartet am falschen Ende. Nur nativer oder manuell optimierter 64bit kann die Performance verdoppeln, Gesetz dem Fall, dass die 64bit Daten ausser optimal breit auch doppelt so schnell verarbeitet werden können, wie eine identische Instruktion in 32bit.

contra 64bit OS, denn der Perfomance Vorteil steht in keinem Verhältnis zur ineffizienten Speichernutzung.

So richtig wüßte ich jetzt keinen Punkt mehr.
Vielleicht die endlos lang Liste mit den Vorteilen vom 32 Bit OS zum 64 bit OS.


Ein 64bit breiter Vorteil fällt mir doch ein.

Kein Programmierer braucht mehr ein Speichermanagement für seine Software zu schreiben. Ausser, einmalig die GetGlobalMemEX Export Funktion zu nutzen um die min. RAM Anforderung gegenzuchecken, ist keinerlei Rücksicht auf den Speicher mehr nötig. Tür auf zu 'den unendlichen Weiten des Addressraums, 5 Tb vom System Kernel enfernt ist der Speicherblock mit seiner 2000 64kb Speicherseiten Belegung, auf der Suche nach fremden Zugriffsverletzungen und neuen unbekannten Speicher Seiten'

32bit-Systeme auf 64bit-Hardware

Das Eine unterscheidet sich maßgelich vom Anderen. Auf System Ebene ist Codierung besser als Optimierung und das verhält sich im Umkehrschluss zur Hardware

 

[JimSim3]

Alles schön und gut. Ändert nichts an der Sache, dass du gegen den Wind pisst. Programmierer in der Spielebranche sind nun mal die am schlechtesten bezahlten Programmierer und das merkt man halt auch bei den Spielen. Da ist halt nix optimiert, wenn es nicht unbedingt sein muss.

Das sie da 32-Bit kompatibel drauf schreiben und dann sowas abliefern ist zu bedauern. Aber im Jahr 2014 machts halt Sinn nen 64-Bit System zu verwenden, wenn du darauf auch spielen willst. Theorie und Praxis sind halt doch unterschiedliche Dinge...

 

[VikingGe]

Das Grow in allen Sprachen, sind Elemente, die 32 bit, 16 bit , 8 bit breite Maschinen Funktionen, in Form eines Befehl, Funktion, Parameter oder Operator je Sprache, unterschiedlich bezeichnen. Je nach Sprache gibt es Befehle die bis zu 4 Maschinen Instruktion zusammenfassen und eine varible Menge an Daten gleichzeit verarbeiten können. Ums ganz klar zu sagen, für Befehlssätze die Code erzeugen um eine zeitnahe Opcode Encodierung zu gewährleisten, sind mit 32bit bereits optimal performant.

Okay, ich habe zwar keine Ahnung, was du mir eigentlich sagen willst, aber optimal performant sind komplexere, rechenintensive Funktionen in x86-32-Code allein schon deshalb selten, weil es da einfach an Registern fehlt. 6 frei nutzbare General Purpose-Register sind recht schnell mit Pointern und Zählern schlicht und einfach voll, da sind 14 Register schon besser. Die 16 statt 8 XMM- (bzw. bei AVX auch YMM-)Register kommen auch ganz gelegen. Will heißen: Weniger Overhead durch Stackoperationen oder direkte Cache-Zugriffe, damit auch weniger potentielle Probleme beim Store-to-Load-Forwarding und ggf. insgesamt weniger Instruktionen. Und das erlaubt dann auch Calling Conventions, wo eine größere Anzahl an Funktionsparametern gar nicht erst auf dem Stack landen, sondern direkt per Register übergeben werden. Gibt auch genug Software, die davon profitiert - ich stelle mal nen Link auf einen Phoronix-Test in den Raum.

Dafür braucht man auch keine "native 64bit-Programmiersprache" - was immer das sein soll - sondern nen vernünftigen Compiler und gegebenenfalls ne handoptimierte Implementierung der jeweiligen Standardbibliothek. Wenn man direkt in Assembler codet, muss man den Code sowieso anpassen, weil natürlich keine 32bit-Addressierung mehr funktioniert.

Und da hab ich jetzt nicht ein einziges Mal die Registerbreite als Performancevorteil erwähnt. Warum? Weil 64bit-Arithmetik nun nicht an jeder Ecke gebraucht wird. In den Fällen kann man getrost auf die 32bit-Varianten ausweichen - mit dem Vorteil, dass Multiplikation und Division tatsächlich je nach CPU schneller sind. Additionen, Subtraktionen und einfache Logikbefehle haben sowieso überall eine Latenz von einem Takt. Die 16- bzw. 8-bit-Varianten gibts natürlich auch noch, aber die sind deutlich langsamer wegen falscher Abhängigkeiten.
Und wenn man es dann doch mal braucht: Ja, natürlich muss der Code darauf abgestimmt sein. Aber wenn einem der 32bit-Tellerrand nicht zu hoch ist, dann bekommt man auch mit stumpfem C-Code die Ergebnisse, die man erwartet.

Gelinde gesagt sind 64bit Makros ineffektiv. Ich bin eza ned ganz sicher, aber ich glaube x86 Instruktionen sind encodiert, bis zum Faktor 8 verkleinert und math. Operanden um den Faktor 2.

Über das Encoding weiß ich jetzt auch nicht sonderlich viel, aber typische x86-64-Opcodes haben ca. 1-3 Bytes ohne Operanden. Registeroperanden sind klein. Immediates werden aber auch nicht immer gleich mit acht Bytes codiert, sondern, wenn es passt, auch mit 1, 2 oder 4 Bytes. Insofern gehören Befehle mit mehr als 7 Bytes zur aussterbenden Gattung - und selbst wenn, bei einer Instruction Fetch-Rate von 32 Bytes pro Takt liegen die Flaschenhälse wohl eher woanders.

Kein Programmierer braucht mehr ein Speichermanagement für seine Software zu schreiben. Ausser, einmalig die GetGlobalMemEX Export Funktion zu nutzen um die min. RAM Anforderung gegenzuchecken, ist keinerlei Rücksicht auf den Speicher mehr nötig.

... soll ich darauf jetzt ernsthaft eingehen?

Vielleicht die endlos lang Liste mit den Vorteilen vom 32 Bit OS zum 64 bit OS.

Die ich nicht sehe.
- Ich könnte wahlweise nur die Hälfte meines RAMs benutzen...
- ... oder nen PAE-Kernel starten. Das ist dann aber richtig langsam. Unter Windows funktioniert das glaube ich gar nicht erst, aber da weiß ich jetzt nicht so wirklich bescheid.
- Software, die mehr als 4GB RAM haben will, funktioniert schlicht und ergreifend nicht. Passiert mir zwar selten, aber es passiert - zum Beispiel, wenn man irgendwas größeres als ein Hello World-Programms mit Link Time Optimizations compiliert. Oder Minecraft spielt.
- 64bit-Software läuft aus den genannten Gründen in der Regel einfach nen Tacken schneller. Also hier unter Linux wirklich jedes Programm bis auf Steam.

 

[DarthLAX]

Also dass die Software-Industrie in der Windows-Welt (und irgendwie auch nur da) bei nativem 64bit-Support auch mehr als eine Dekade nach dem Athlon 64 und den ersten 64bit-Pentium IVs sowie mehr als vier Jahre nach dem Release von dem als 64bit-Version absolut brauchbaren Windows 7 nicht aus dem Quark kommt, ist jetzt nicht die Schuld von Windows oder von Microsoft.

Ich meine, mich regt das auch auf, dass RAM-Fresser wie Skyrim nicht als native 64bit-Version kommen, weil die nicht nur performancemäßig profitieren würden, sondern eben auch von dem erweiterten Addressraum. Das war im Jahre 2011 schon arm und das heute erst recht arm. Aber trotzdem, wenn die Entwickler 10 Jahre nach der Einführung einer heute längst etablierten Technologie verlangen, dass ihre Nutzer darauf setzten, dann sollen sie es meinetwegen tun - welches Spiel läuft rein leistungsmäßig noch auf Rechnern von vor 10 Jahren? Da wirds ja selbst bei den anspruchslosesten aller Indie-Games knapp.

Ob das im konkreten Fall nun technisch irgendwie zu rechtfertigen ist, ist zwar eine andere Sache, aber genau so gibt es aus technischer Sicht keinen Grund, 32bit-Systeme auf 64bit-Hardware laufen zu lassen. Und jetzt komm mir nicht mit den paar Prozent Größenunterschied.

eben!

wer heute noch ein 32er OS verwendet (oder Gott bewahre (arg und dabei bin ich Atheist ^^): EINES KAUFT!) dem ist glaub ich echt nimmer zu helfen (ich meine ich würde es verstehen, wenn die Technik neu bzw. erst 2-3 Jahre raus wäre, aber es sind echt schon an die 10 Jahre (hatte damals einen Athlon 64 3500+ .... war nen nettes maschinchen ^^) und da sollte man mal hardware getauscht haben bzw. ein neues OS erworben haben (ich meine die 32er gibt es doch IMHO nur noch, weil es noch office-rechner gibt die nur des können...für zocker sollte es aber ganz normal sein, sowas nicht zu haben bzw. nicht zu kaufen/verwenden, wenn es unsinn ist!)

mfg LAX

 

[AchtBit]

@VikingGe, den Mythos, nur 4gb adressierbar mit 32bit win, hat M$ zu verantworten. Ab XP können alle OS 16gb adressieren indem die 36bit Adressierung, seit PentiumPro, unterstützt wird. Die Enterprise Server Variante vom XP, kann 16gb adressieren und je weiter die Lizenz abgespeckt ist deto weniger Ram kann adressiert werden. XP Pro konnte bis SP1 8gb adressieren. M$ hat mit SP2 die 4gb Grenze gesetzt. Alle 32bit Desktopvarianten sind von M$(bis auf eine Starter 2gb Variante) 4gb limitierte Lizenzen. Bis auf XP sp3(da hat M$ ständig die System Adressen umbelegt) kann jedes 32bit wind OS, durch booten eines gepatchten User Kernel, 4,8,16,32 oder 64gb adressieren.

Ich hab als 2t OS selbst win7 64bit installiert und einen direkten Vergleich. Trotz 6gb Ram ist das 64er im Vergleich zum 32er XP(3,5gb Ram + 2,5gb virueller Speicher im Ramdrive) träge und sperrig. Überhaupt kein vergleich zum XP, dass sich fast derrennt. Zugegeben manche Software läuft mit dem 64er schneller aber eben nur manche, besonders Benchmarks. Das Groh ist aber mit dem XP schneller. Ein Vergleich z.b. Mit U. Heaven, im XP ist der d3d Mode halb so schnell wie im W7 aber wenn ich opengl verwende und die gleichen Optionen wie im Win7 mit dx11, dann ist die ogl Version im XP genau so schnell wie die dx11 Version im W7 64bit.

Wie auch immer, der grösste Minuspunkt ist das OS an sich. Solange es geht, verwende ich daher primär das wesentlich leichtfüssigere XP. Und das 64bit OS frisstet sein Dasein auf der Ersatzbank.

 

[DarthLAX]

und wie spielst du "neue" spiele (also alles was DX-Support ab 10.1 (gab es das noch für XP...glaub nämlich net) braucht (DX 11 gab es auf jeden fall nicht mehr (aber ich meine mich zu erinnern, das bei DX9 schluss war mit XP))

mfg LAX
ps: nicht das ich von Win7/8 weg wollte (auch wenn XP schlanker ist und ich mich - immer noch - wohl besser damit auskenne )

 

[dmxcom]

Trolololol

 

[AchtBit]

toll, etz hab ich mir den 8,7gb Patch reingeladen und der versaut einem doch glatt die Saves.

Wenn ich das gewusst hätte aber laut Patch Info muss kein 'Neues Spiel' gestartet werden. Muss auch nicht

siehe Anhang. Diesmal war es endgültig das letzte was ich von UBI gekauft hab. Damit mein ich jetzt auch die Schleuderpreisangebot vom Ramschtisch.