Alten Ram aufstocken



  • Weis ich nicht. Könnte man evtl. abschätzen anhand der wichtigsten Eckdaten meines PCs:
    -Mainboard: ASUS P5Q pro
    -CPU: Quadcore Q9550 @ 2.83GHz
    -RAM: 4GB OCZ 1066 MHZ PC2 8500 DDR2
    -GPU: Geforce GTX 260²
    -Keine SSD

    Im Moment nerven mich Lade- und Bootzeiten.
    Die Festplatte bremst eine Menge aus, was wohl auch an den nur 4GB Ram liegt (Auslagerungsdatei).



  • Auch ein rohes Windows ohne zusätzlich gestartete Großprogramme braucht keine 4 GB RAM.

    Was dich an der Bootzeit also ausbremmst ist die Festplatte.
    Ich würde dir empfehlen eine SSD zu kaufen.
    Die bringt sogar auch dann noch etwas, wenn man nur einen IDE Anschluss haben sollte.
    Bei dem Rechner gehe ich aber davon aus, dass der schon SATA hat, denn den hat ja selbst mein alter Core2Duo. Insofern bräuchtest du nicht einmal einen Adapter.
    Eine große SSD rein und darauf Windows und die Programme die du am häufigsten benötigst oder zur Bootzeit notwendig sind installieren, fertig und schon geht der Rechner wieder ab wie die Post.

    8 GB RAM wären sinnvoll, aber wie schon gesagt, da hast du eben das Problem mit den Preisen.

    Bei 4 GB RAM würde ich dir übrigens zur 32 Bit Version von Windows raten.



  • Dabelju schrieb:

    Bei 4 GB RAM würde ich dir übrigens zur 32 Bit Version von Windows raten.

    Weil 32-Bit-Programme ja auch 4GB nutzen können... De facto können sie das in der Regel nicht (/LARGEADRESSAWARE), also lohnt x64 auch bei 4GB. Von der erhöhten Zahl von Registern, den Vorteilen beim rechnen mit 64-bit-Zahlen, der standardmäßigen Nutzung von SSE, etc. ganz zu schweigen.

    SATA wird der Rechner wohl schon haben und dem Tipp zur SSD würde ich mich anschließen. Wird wahrscheinlich mehr bringen als mehr RAM, außer, es gibt ein konkretes sehr speicherhungriges Programm, dass Du nutzen willst.

    Falls auf dem System Windows 7 läuft: Es gibt außerdem ein Hotfix (https://support.microsoft.com/de-de/kb/2775511), der unter anderem auch die Bootzeit senkt.



  • Mr X schrieb:

    Dabelju schrieb:

    Bei 4 GB RAM würde ich dir übrigens zur 32 Bit Version von Windows raten.

    Weil 32-Bit-Programme ja auch 4GB nutzen können... De facto können sie das in der Regel nicht (/LARGEADRESSAWARE), also lohnt x64 auch bei 4GB. Von der erhöhten Zahl von Registern, den Vorteilen beim rechnen mit 64-bit-Zahlen, der standardmäßigen Nutzung von SSE, etc. ganz zu schweigen.

    Ich habe nirgends gesagt, dass die auch 4 GB nutzen würden.
    Es geht darum, dass Windows für sich selbst schon einen Adressraum von 2 GB in Beschlag nimmt und die anderen Prozesse dann sowieso nur 2 GB, mit Tweaks auf 3 GB, reservieren können und da das RAM mit nur 4 GB so knapp ist und es in der Praxis somit sowieso nicht mehr als etwa 2 GB zu reservieren gibt, fährt man mit 32 Bit besser, weil bei 32 Bit schon allein die Zeiger weniger Platz benötigen.
    Was man hier nämlich nicht vergessen sollte ist, dass 64 Bit schon allein viel Platz verschlingt.

    Daraus folgt, wer 64 Bit fahren will, der sollte auch mindesten 8 GB RAM haben.



  • Es geht darum, dass Windows für sich selbst schon einen Adressraum von 2 GB in Beschlag nimmt und die anderen Prozesse dann sowieso nur 2 GB, mit Tweaks auf 3 GB, reservieren können

    Verwechsele den physischen nicht mit dem virtuellen Adressraum. Der virtuelle Adressraum eines 64-bit-Systems ist wesentlich größer als 4 GB, egal, wieviel physischer Speicher verbaut ist. Und wenn Windows 2GB des virtuellen Adressraums belegt, ist das bei einem 64-bit-System herzlich egal, bei einem 32-bit-System nicht. Außerdem gibts auch noch die Auslagerungsdatei.

    da das RAM mit nur 4 GB so knapp ist

    Nö, ist es nicht. Mein Rechner mit 4GB und x64-Windows läuft prima.



  • Mr X schrieb:

    Es geht darum, dass Windows für sich selbst schon einen Adressraum von 2 GB in Beschlag nimmt und die anderen Prozesse dann sowieso nur 2 GB, mit Tweaks auf 3 GB, reservieren können

    Verwechsele den physischen nicht mit dem virtuellen Adressraum. Der virtuelle Adressraum eines 64-bit-Systems ist wesentlich größer als 4 GB, egal, wieviel physischer Speicher verbaut ist. Und wenn Windows 2GB des virtuellen Adressraums belegt, ist das bei einem 64-bit-System herzlich egal, bei einem 32-bit-System nicht. Außerdem gibts auch noch die Auslagerungsdatei.

    Ich verwechsle gar nichts, du verstehst nichts.
    Die 64 Bit bringen hier nichts, weil gar nicht genug RAM vorhanden ist.
    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. Unterm Strich steht der Anwendung also letzten Endes dadurch mehr RAM bei einem 32 Bit OS zur Verfügung bei DIESER HW Konfiguration, das gilt nicht, wenn der Rechner mehr als 4 GB RAM hat.

    da das RAM mit nur 4 GB so knapp ist

    Nö, ist es nicht. Mein Rechner mit 4GB und x64-Windows läuft prima.

    Das ist ne Nullaussage.
    Mit 32 Bit wäre der Speicherverbrauch geringer, der Rechner würde besser laufen und du könntest sogar noch 16 Bit Programme ausführen, was bei 64 Bit nicht mehr geht.



  • 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.


Anmelden zum Antworten