32 bit vs 64 bit

@Web-Schecki ist ja auch der einzigste Cache im System ?

nein ..
 
Dein Hauptproblem ist ganz einfach:
Du kannst auf einem 32 Bit Betriebssystem keine 64 Bit Software installieren. Umgekehrt aber schon.

Solange die 4 GB RAM (WIN 10 32 Bit kann exakt 4GB) für deine Anwendungen ausreichen, macht es keinen unterschied ob 32 oder 64 Bit Windows 10. Dennoch würde ichimmer 64 Bit installieren, wegen der Softwarekompatibilität.
 
Also unter Linux ist ein 64-Bit-Kernel und -Userspace spürbar schneller (aus dem Gefühl sagen wir mal 20%) als die 32-Bit-Äquivalente, selbst bei weniger als 4GB RAM. Es gibt einfach zahlreiche Dinge, die mit 64 Bit schneller sind (natürlich z.B. Handling von 64-Bit-Ints, aber vermutlich auch memcpy und so weiter).
 
  • Gefällt mir
Reaktionen: gaym0r
@GrumpyCat Dazu muss man aber auch sagen, dass man bei 64bit naturgemäß von viel neueren CPUs ausgehen kann, entsprechend legt man hier beim Kompilieren eine viel neuere Architektur mit entsprechenden Optimierungen zugrunde, als bei 32bit, wo vermutlich manche Kernel bis heute noch auf i386 rumkrebsen. Ich glaube noch längst nicht alle, sofern überhaupt noch vorhanden, legen i686 zugrunde.
 
Es gibt unter Windows verschiedene Dinge zu beachten, an die man vielleicht nicht sofort denkt:
  • Durch reservierte Bereiche lassen sich bei 32-Bit-Systemen nicht die vollen 4 GB nutzen, sondern meist um ca. 3,0 - 3,5 GB.
  • Windows Server können auch als 32 Bit bis zu 64 GB RAM nutzen.
  • Ein 64-Bit-System verbraucht mehr Speicher. Bei weniger als 4 GB RAM ist es also ein Nachteil.
  • Ein 32-Bit-Prozess kann maximal 2 GB Speicher adressieren. Das kann je nach Anwendung ebenfalls limitierend wirken.
  • 32-Bit-Programme können nicht direkt auf einem 64-Bit-System ausgeführt werden. Sie werden emuliert (WOW64) und laufen dadurch minimal langsamer.
  • 16-Bit-Anwendungen (oder auch bloß 32-Bit-Anwendungen mit einem 16-Bit-Installer) können gar nicht auf einem 64-Bit-System ausgeführt werden.
Da es aber Windows 11 nicht mehr als 32 Bit gibt, spielt 32 Bit im Prinzip auch keine Rolle mehr.
 
Zuletzt bearbeitet:
Amaoto schrieb:
Sie werden emuliert
Nein, es ist eine "leichtgewichte Übersetzungsschicht", wie der von dir verlinkte Wikipedia Artikel ja besagt. Das ist keine Emulation, sondern eine 32bittige Laufzeitumgebung als Schicht. Laufen tut der Prozess weiterhin nativ auf System und Hardware. Es entsteht geringfügiger Verwaltungsoverhead dadurch, das ist alles.
 
ArrorRT schrieb:
Also warum sind dann nur 3,2 nutzabar?
Die 4GB stehen nicht ausschließlich der Adressierung von RAM zur Verfügung. Sondern auch PCIe Karten blenden Speicherbereiche in diesen Adressraum ein.
 
In der Tat. Ich nehme alles zurück und behaupte das Gegenteil. Mir war nicht bekannt, dass WOW64 wirklich Kernelaufrufe abfängt und ging von einer einfachen Übersetzungsschicht bzw. Laufzeitumgebung aus.
 
xxMuahdibxx schrieb:
Hast du es selbst gelesen? Scheinbar ja nicht mal das erste Wort "CPU-Caches", denn von denen habe ich ja anfangs gesprochen. Wie dort beschrieben wird sind die natürlich nicht adressierbar. Übrigens genauso wenig wie Caches auf der GPU, oder mögliche Festplatten/SSD-Caches.

Die Frage bleibt also offen: Welche Caches sind adressierbar?
 
Grimba schrieb:
@GrumpyCat Dazu muss man aber auch sagen, dass man bei 64bit naturgemäß von viel neueren CPUs ausgehen kann, entsprechend legt man hier beim Kompilieren eine viel neuere Architektur mit entsprechenden Optimierungen zugrunde, als bei 32bit, wo vermutlich manche Kernel bis heute noch auf i386 rumkrebsen.
Mag sein (die 20% in meiner Erfahrung kamen allerdings meine ich beim Umstieg von 686 zu amd64).

Ich würde aber tatsächlich auch die Bedeutung von uint64 nicht unterschätzen, da geht es eben NICHT nur um Speicherpointer. Dateigrößen? Heutzutage 64 Bit. Timestamps? 64 Bit. Bitfelder/Sets sind bei 64 Bit auch wesentlich mächtiger als bei 32.
 
@Web-Schecki

Ja die erste Zeilen gelesen...

CPU-Caches sind aus Cache-Zeilen aufgebaut. Diese sind die kleinsten adressierbaren Einheiten im Cache

Und auch mehr gelesen...

Gibt da eine große Diskrepanz zwischen deiner Aussage ohne Beweis und dem was man über eine Cache/Memory Abfrage der MMU macht...
 
Zuletzt bearbeitet:
xxMuahdibxx schrieb:
Und auch mehr gelesen...
Aber offensichtlich mal überhaupt nicht verstanden...

Der Cache hat (bei x86) keinen eigenen Adressraum, den das Betriebssystem verwenden könnte. Er ist damit für das OS nicht adressierbar. Du kannst nicht explizit auf eine Cache-Line zugreifen, ohne, bei Cache-Miss, die Antwort aus dem Hauptspeicher zu bekommen.
Cache-Lines haben logischerweise Adressen. Die ergeben sich aber, wie du deiner eigenen Quelle entnehmen kannst, direkt aus der virtuellen oder der physischen Adresse. Kein eigener Adressraum.

xxMuahdibxx schrieb:
was man über eine Cache/Memory Abfrage der MMU macht...
Und inwiefern ist das, was die MMU intern tut, für den Adressraum des Betriebssystems relevant? Richtig, überhaupt nicht. Das ist der Punkt. Das Betriebssystem muss sich nicht um den Cache kümmern - und könnte das auch gar nicht. Aus Sicht der CPU sind das alles einfach nur Hauptspeicheradressen.
 
  • Gefällt mir
Reaktionen: whats4
Zurück
Oben