Alten Ram aufstocken
-
Und noch etwas.
Du hast zwar unter 64 Bit mehr Register, aber es müssen auch mehr Bits geschaufelt werden, wenn der Rechner mit 64 Bit Adressen rumschaufeln muss. Der Cache wird auch schneller voll.
Damit schwindet ein Geschwindigkeitsvorteil durch mehr Register.
-
Und noch etwas.
Du hast zwar unter 64 Bit mehr Register, aber es müssen auch mehr Bits geschaufelt werden, wenn der Rechner mit 64 Bit Adressen rumschaufeln muss. Der Cache wird auch schneller voll.
Damit schwindet ein Geschwindigkeitsvorteil durch mehr Register.Es ist zwar so, dass die Adressen breiter sind, aber das bedeutet nicht zwangsläufig, dass das "umschaufeln" der Bits deshalb langsamer ist (Wobei anzumerken ist, dass die Adressbreite eines 32-Bit-Programms, dass im x64-OS ausgeführt wird, sowieso weiterhin 32 Bit beträgt). Aber schon allein die Tatsache, dass x64-CPUs mit 64-Bit-Datentypen umgehen können, ist ein absoluter Vorteil. Der 32-Bit-Befehlssatz sieht keine 64-Bit-Datentypen vor, d.h. wann immer ein 32-Bit-Programm mit 64-Bit-Datentypen Rechenoperationen ausführt, müssen die mehr oder weniger umständlich vom Compiler in mehrere 32-Bit-Befehle zerlegt werden.
1-2 GB frisst das OS selbst, auch bei 64 Bit. Bleiben also 2-3 GB für die Anwendung, da kannst du also gleich bei 32 Bit bleiben und sparst somit Speicherplatz, weil 32 Bit Adressen einfach kleiner sind und weniger Platz im RAM benötigen.
Das ist grober Unfug. Das OS frisst nicht 1-2 GB physischen RAM, sondern es blockiert (im Falle von Windows mit Standardeinstellungen) pauschal 2GB des virtuellen Adressraums für seine Zwecke (Zum nachlesen: https://de.wikipedia.org/wiki/4-GB-Grenze). Tatsächlich (nicht-freigebbar) allokiert ist normalerweise weniger. Das heißt, mit einem 64-Bit-System vergrößert sich der einem einzelnen Programm zur Verfügung stehende Adressraum und damit auch die tatsächlich von einer Anwendung nutzbaren Menge an RAM (dem natürlich ein gestiegener Bedarf durch längere Pointer gegenüber steht).
du könntest sogar noch 16 Bit Programme ausführen, was bei 64 Bit nicht mehr geht.
Ja. Dafür kann ich mit dem 32-Bit-OS keine 64-Bit-Programme ausführen. Wieviel 16-Bit-Software ist noch im Umlauf? Quasi keine. Wieviel 64-Bit-Software ist im Umlauf? Immer mehr. Zwar gibts meist noch eine 32-Bit-Variante, aber die ist (siehe oben) im Normalfall lahmer als eine 64-Bit-Variante.
-
Ach, nochwas: Ohne PAE (was ein normales 32-Bit-Windows nicht kann), gibt es auch kein NX-Bit im 32-Bit-OS (siehe hier: https://de.wikipedia.org/wiki/NX-Bit).
EDIT: Stimmt nicht ganz. Normales 32-Bit-Windows seit XP SP2 nutzt PAE, aber nur, um das NX-Bit zu nutzen (Was allerdings zur Folge hat, dass das System für die Seitentabellen doppelt so viel Speicher braucht). Mehr als 4GB weigert es sich trotzdem anzusprechen.
-
Mr X schrieb:
Es ist zwar so, dass die Adressen breiter sind, aber das bedeutet nicht zwangsläufig, dass das "umschaufeln" der Bits deshalb langsamer ist
Der Bandbreitenbedarf steigt und der 1st Level Cache wird schneller voll.
(Wobei anzumerken ist, dass die Adressbreite eines 32-Bit-Programms, dass im x64-OS ausgeführt wird, sowieso weiterhin 32 Bit beträgt).
Es geht hier eher um SW, bei der man wahlweise zwischen 32 Bit oder 64 Bit wählen kann. Wenn man ein 64 Bit OS installiert, dann ist das OS selbst schon einmal in 64 Bit und wenn man etwas von den zusätzlichen Registern haben will, dann wird man auch die SW in 64 Bit installieren.
Wer sowieso nur 32 Bit SW verwendet, bei einem Rechner mit nur 4 GB RAM, der kann auch gleich bei eine 32 Bit OS bleiben.Aber schon allein die Tatsache, dass x64-CPUs mit 64-Bit-Datentypen umgehen können, ist ein absoluter Vorteil. Der 32-Bit-Befehlssatz sieht keine 64-Bit-Datentypen vor, d.h. wann immer ein 32-Bit-Programm mit 64-Bit-Datentypen Rechenoperationen ausführt, müssen die mehr oder weniger umständlich vom Compiler in mehrere 32-Bit-Befehle zerlegt werden.
Das ist zwar richtig, aber wie oft kommt das schon vor, dass gewöhnliche Anwendungssoftware 64 Bit breite Datentypen dringend benötigt?
1-2 GB frisst das OS selbst, auch bei 64 Bit. Bleiben also 2-3 GB für die Anwendung, da kannst du also gleich bei 32 Bit bleiben und sparst somit Speicherplatz, weil 32 Bit Adressen einfach kleiner sind und weniger Platz im RAM benötigen.
Das ist grober Unfug. Das OS frisst nicht 1-2 GB physischen RAM, sondern es blockiert (im Falle von Windows mit Standardeinstellungen) pauschal 2GB des virtuellen Adressraums für seine Zwecke
Das hatte ich zuvor schon gesagt. Kontext beachten! Aus dem Kontext geht das hervor, danach habe ich mich auf fressen beschränkt um mir die Schreibarbeit zu vereinfachen.
(dem natürlich ein gestiegener Bedarf durch längere Pointer gegenüber steht).
Das ist das Problem.
du könntest sogar noch 16 Bit Programme ausführen, was bei 64 Bit nicht mehr geht.
Ja. Dafür kann ich mit dem 32-Bit-OS keine 64-Bit-Programme ausführen.
Die meisten 64 Bit Programme liegen immer noch in 32 Bit Versionen vor.
Die meisten verwenden sogar immer noch 32 Bit.Wie viel und welche Alltags SW kennst du, die 64 Bit zwingend voraussetzt?
Wieviel 16-Bit-Software ist noch im Umlauf? Quasi keine.
Es gibt genug alte Schatzerl für die es bis heute keinen Ersatz gibt.
Das fängt ja schon bei dem ein oder anderen Spiel an.Abschließend würde ich dem TS empfehlen, gönne dem Rechner 8 GB RAM und die Diskussion um 32 Bit oder 64 Bit OS ist kein Thema mehr.
-
Ach ja noch etwas, die Treiberunterstützung für Althardware ist bei einem 32 Bit Windows auch besser.
-
Das ist zwar richtig, aber wie oft kommt das schon vor, dass gewöhnliche Anwendungssoftware 64 Bit breite Datentypen dringend benötigt?
Quasi alle Software, natürlich aber nicht alle in gleichem Ausmaß. Beispielsweise ist time_t der Standardbibliothek üblicherweise als 64-Bit-Int implementiert. Dazu kommt, dass 64-Bit-Software immer SSE nutzen kann, während bei 32-Bit-Kompilaten das oftmals nicht gemacht wird, um Kompatibilität zu wahren.
Das hatte ich zuvor schon gesagt. Kontext beachten! Aus dem Kontext geht das hervor, danach habe ich mich auf fressen beschränkt um mir die Schreibarbeit zu vereinfachen.
Ja, aber bezogen auf den physischen Speicher ist es schlicht falsch. Windows braucht die 2GB nicht vollständig auf (abgesehen davon, dass freier Speicher zum Caching verwendet wird - aber Caches lassen sich auch wieder verkleinern). Und damit bleiben mehr als 2GB für Anwendungen, die von einer einzelnen Anwendung nur sinnvoll genutzt werden können, wenn das System nicht 2GB des 4GB großen virtuellen Adressraums blockieren würde.
Die meisten 64 Bit Programme liegen immer noch in 32 Bit Versionen vor.
Die meisten verwenden sogar immer noch 32 Bit.Wie viel und welche Alltags SW kennst du, die 64 Bit zwingend voraussetzt?
Wenig, die es zwingend voraussetzt (wobei es angeblich ein paar PC-Spiele geben soll). Ich persönlich habe keine Lust mehr, 32-Bit-Systeme zu unterstützen und liefere Software standardmäßig in 64-Bit aus. Wie lange ich als Fallback noch XP-kompatible 32-Bit-Kompilate ausliefern werde, weiß ich nicht, aber sobald ich XP fallen lasse, fliegen auch die 32-Bit-Versionen weg.
Es gibt genug alte Schatzerl für die es bis heute keinen Ersatz gibt.
Das fängt ja schon bei dem ein oder anderen Spiel an.Die sind aber nicht so leistungshungrig, dass man die nicht notfalls in einem Emulator laufen lassen könnte. Zumal es mit Windows neuer als XP sowieso bei manchen älteren Spielen Probleme gibt, unabhängig von 64-Bit.
Es geht hier eher um SW, bei der man wahlweise zwischen 32 Bit oder 64 Bit wählen kann. Wenn man ein 64 Bit OS installiert, dann ist das OS selbst schon einmal in 64 Bit und wenn man etwas von den zusätzlichen Registern haben will, dann wird man auch die SW in 64 Bit installieren.
Natürlich. Ich habe nicht dafür plädiert, 32-Bit-Programme auf x64-Systemen laufen zu lassen, wenn man die Wahl hat; ganz im Gegenteil. Aber wenn man es doch tut, sind deren Pointer weiterhin 32 Bit breit.
Ach ja noch etwas, die Treiberunterstützung für Althardware ist bei einem 32 Bit Windows auch besser.
Was nur dann eine Rolle spielt, wenn man derartige Hardware einsetzen will...
-
Mr X schrieb:
Beispielsweise ist time_t der Standardbibliothek üblicherweise als 64-Bit-Int implementiert.
Also ob du eine Datenmenge von Zig Terrabyte an time_t Datentypen herumschaufeln müsstest.
-> Argument ist daher Unfug.Dazu kommt, dass 64-Bit-Software immer SSE nutzen kann, während bei 32-Bit-Kompilaten das oftmals nicht gemacht wird, um Kompatibilität zu wahren.
Ich würde sagen, dass man heutzutage die 32 Bit Software auf die Rechner optimiert, die auch problemlos ein Windows ausführen können, das noch mit Sicherheitsupdates versorgt wird.
Der Gemeinsame Nenner wäre da also Windows 7.
Bei den Rechnern kann man also von typischen CPUs aus einer Zeit, bei der die Rechner schon mehr als 2 GB, wenn nicht sogar 4 GB RAM hatten, ausgehen und da hat man dann CPUs die in der Regel schon alle SSE2 und das NX Bit beherrschen.
SSE2 wäre somit als kleinster gemeinsamer Nenner durchaus wählbar.Ansonsten, wenn man wirklich Uralt CPUs unterstützen muss, dann kann man auch für die 32 Bit Versionen mehrere Compilate bereitstellen.
Und damit bleiben mehr als 2GB für Anwendungen, die von einer einzelnen Anwendung nur sinnvoll genutzt werden können, wenn das System nicht 2GB des 4GB großen virtuellen Adressraums blockieren würde.
Ich sagte ja, 2-3 GB sind für Anwendungen auch auf 32 Bit Systeme reservierbar, je nach Einstellung. Wer die 3 GB haben will, der muss natürlich etwas nachhelfen, es geht aber.
Es gibt genug alte Schatzerl für die es bis heute keinen Ersatz gibt.
Das fängt ja schon bei dem ein oder anderen Spiel an.Die sind aber nicht so leistungshungrig, dass man die nicht notfalls in einem Emulator laufen lassen könnte.
Es sind am ehsten sogar noch alte Spiele und die fressen auch in einer Emulation viel Leistung.
Zumal es mit Windows neuer als XP sowieso bei manchen älteren Spielen Probleme gibt, unabhängig von 64-Bit.
Das kann ich nicht bestätigen.
Bisher habe ich jedes meiner Windowsspiele, die kein 16 Bit Compilat waren unter Win 7 64 Bit zum Laufen bekommen.
Es war nicht eines dabei, das nicht Lief.Die Problemfälle dürften sich daher auf Starforce Geschütze Spiele beschränken, die Systemtreiber voraussetzen, die es dann nur für WinXP gibt.
Aber das war schon damals absehbar, als diese Spiele und StarForce ganz neu waren. Die haben also nur Deppen gekauft. Ich habe diese Spiele einfach gemieden und schlichtweg nie gekauft, genau aus diesen Gründen, die aber alle damals schon bekannt und abzusehen waren, bevor Windows Vista und später überhaupt das Licht der Welt erblickten.Ach ja noch etwas, die Treiberunterstützung für Althardware ist bei einem 32 Bit Windows auch besser.
Was nur dann eine Rolle spielt, wenn man derartige Hardware einsetzen will...
[/quote]
Jo, z.b. die Audigy 2 und früher.
Die ist nämlich nur innerhalb der ersten 2 GB des Adressraums adressierbar, weil der Chiphersteller aus Kostengründen die 32-igste Datenleitung einfach weggelassen hat.
Will man nun Speicher aus dem RAM in die HW einblenden, dann muss das der Bereich unterhalb von 2 GB sein.
Auf 64 Bit Systemen kann das zu Problemen führen, weil da auch Speicher aus den oberen 2 GB eingeblendet werden könnten, die die HW aber nicht nutzen kann.Ich musste jedenfalls mein 64 Bit Windows auf 2 GB RAM maximal beschränken, wenn ich die Audigy 2 im vollen Umfang nutzen wollte.
Mittlerweile habe ich einen neuen Rechner, in den keine PCI Karte mehr reinpasst, damit hat es sich erledigt.
Aber bei meinem alten Core2Duo war das so.
-
Dabelju schrieb:
Audigy 2 (...)
Mittlerweile habe ich einen neuen Rechner, in den keine PCI Karte mehr reinpasst, damit hat es sich erledigt.
Aber bei meinem alten Core2Duo war das so.Sei froh, der SRC in der Audigy 2 war nicht unbedingt einer der besten
-
hustbaer schrieb:
Dabelju schrieb:
Audigy 2 (...)
Mittlerweile habe ich einen neuen Rechner, in den keine PCI Karte mehr reinpasst, damit hat es sich erledigt.
Aber bei meinem alten Core2Duo war das so.Sei froh, der SRC in der Audigy 2 war nicht unbedingt einer der besten
Stellt sich nur die Frage, ob der auf meinem Mainboard besser ist. Ich habe nämlich keine neue Soundkarte mehr verbaut.
-
Dann macht es wohl die CPU, und die von z.B. Windows verwendeten SRC Implementierungen sind soweit ich weiss recht gut.
