staging.inyokaproject.org

Hallo,

ich stehe vor der Frage, auf einem ASUS F200M mit nur 2 GiB RAM ein Ubuntu 32-Bit oder 64-Bit zu installieren.

Hat da jemand Erfahrungswerte, wie hoch da der Unterschied z.B. bzgl. Speicherverbrauch ist.

Ich denke, es könnte schon mal das Zünglein an der Waage sein, wann das System anfängt zu "swappen" wenn man gleichzeitig Firefox mit einigen Addons und offenen Tabs, Thunderbird mit mehreren E-Mail-Konten und vielleicht noch 2..3 andere größere Anwendungen offen hat. Auf meinem anderen Ubuntu 64-Bit-System mit 4 GiB RAM greift sich Firefox nach einiger Zeit durchaus schon mal 2 GiB Speicher, und je nach weiterer Auslastung kommt es auch da zum "swappen".

Ich glaube nicht, dass das messbar ist. in 64-Bit-Systemen sind einzelne Variablen größer, zB ein Int ist nicht 32 sondern 64 bit breit. Frei allokierte Speicherbereiche sind gleich groß, genauso wie Binärinhalte...

Was Du allerdings messen kannst, ist dass ein 32-Bit-Kernel den kleinsten gemeinsamen Nenner bedient und daher neuere Prozessorerweiterungen nicht benutzt werden, auch wenn sie vorhanden sind, weil sie nicht in allen 32-Bit-Systemen vorhanden sind.

Ich finde es nicht einfach, dazu die verschiedenen Meinungen im Netz zu bewerten. Laut Wikipedia verbrauchen 64-Bit-Versionen 25 - 30 % mehr Speicher, das würde ein 32-Bit-System bei nur 2 GiB RAM schon rechtfertigen. Hier mal ein paar Links, die ich zu dem Thema gefunden habe:

• https://de.wikipedia.org/wiki/64-Bit-Architektur#Nachteile

• http://www.hardwareschotte.de/magazin/32-bit-vs-64-bit-wo-ist-der-unterschied-a41592#id-vor-und-nachteile-von-64-bit

• https://forum.ubuntuusers.de/topic/kubuntu-32-bit-oder-64-bit/#post-7154908

• http://www.pcwelt.de/ratgeber/64_Bit_vs_32_Bit_-_Welches_Linux-System_darf_es_sein_-Hardware-Architektur-8778073.html

• http://www.gutefrage.net/frage/linux-32-oder-64-bit

Hintergrund der Frage ist dieses Problem.

Ein weiterer Grund ist die Überlegung, ob sich das alte J-Pilot auf einem 32-Bit-System evtl. mit meinem Palm Treo 650 verträgt. Auf meinem 64-Bit-System tut es das nämlich nicht. Von Windows habe ich die Erfahrung, dass der der Palm-Desktop-Software beigepackte USB-Treiber nur auf Windows 32 funktioniert, könnte bei J-Pilot ja vielleicht auch der Fall sein.

Also den Speicherverbrauch kannst du leicht vergleichen, installier die 32 und 64 Bit Varianten in virtuellen Maschinen und vergleiche. Bei 2 GB Ram würde ich wohl eine ressourcenschonendere Oberfläche wählen, z.B. LXDE, dafür dann 64 Bit.

Oder boote die live.

UlfZibis schrieb:

Ich finde es nicht einfach, dazu die verschiedenen Meinungen im Netz zu bewerten.

Richtig lesen und dann bewerten. In zB deinem Link "Hardwareschotte" wird auf die Verfügbarkeit von 64-Bit-Treibern für Windowssysteme hingewiesen, ein Umstand der unter Linuxsystemen entfällt. Die Aussage ist für die Fragestellung hier also irrelevant.

Auch die Antwort bei "gutefrage" lautet "Bei einem Linuxsystem kein Problem".

Ich kann grade an Hand der von dir genannten Links nicht verstehen, was da schwer zu bewerten ist.

Offtopic: Das liest sich irgendwie alles wie die Warnungen vor IPv6 vor 5-10 Jahren.

Laut Wikipedia verbrauchen 64-Bit-Versionen 25 - 30 % mehr Speicher, das würde ein 32-Bit-System bei nur 2 GiB RAM schon rechtfertigen.

Damit wird auf den Festplattenplatz angespielt - in einem anderen deiner Links wird darauf hingewiesen, dass dieser Unterschied nicht feststellbar sei.

Ein weiterer Grund ist die Überlegung, ob sich das alte J-Pilot auf einem 32-Bit-System evtl. mit meinem Palm Treo 650 verträgt. Auf meinem 64-Bit-System tut es das nämlich nicht.

Eine Frage, die sich mit einem Livemedium klären liesse. Ob dir jemand anderes Fragen zur Nutzbarkeit einer Hardware von vor 12 Jahren beantworten kann, stelle ich mal in Frage.

Von Windows habe ich die Erfahrung, dass der der Palm-Desktop-Software beigepackte USB-Treiber nur auf Windows 32 funktioniert, könnte bei J-Pilot ja vielleicht auch der Fall sein.

Auf genau den Umstand weisen deine Recherchen hin. Unter Linux sind die Treiber in der Regel im Kernel inkludiert und daher in der von dir genutzten Architektur vorhanden.

redknight schrieb:

Danke für Deine wertvollen Bewertungen der Links.

Laut Wikipedia verbrauchen 64-Bit-Versionen 25 - 30 % mehr Speicher, das würde ein 32-Bit-System bei nur 2 GiB RAM schon rechtfertigen.

Damit wird auf den Festplattenplatz angespielt - in einem anderen deiner Links wird darauf hingewiesen, dass dieser Unterschied nicht feststellbar sei.

Da steht aber auch: "Ihre Speicherung verbraucht daher im RAM und in den Caches doppelt so viel Platz." und "... und dadurch auch RAM und Cache („Cache miss“) stärker belasten können."

Ein weiterer Grund ist die Überlegung, ob sich das alte J-Pilot auf einem 32-Bit-System evtl. mit meinem Palm Treo 650 verträgt. Auf meinem 64-Bit-System tut es das nämlich nicht.

Eine Frage, die sich mit einem Livemedium klären liesse. Ob dir jemand anderes Fragen zur Nutzbarkeit einer Hardware von vor 12 Jahren beantworten kann, stelle ich mal in Frage.

Von Windows habe ich die Erfahrung, dass der der Palm-Desktop-Software beigepackte USB-Treiber nur auf Windows 32 funktioniert, könnte bei J-Pilot ja vielleicht auch der Fall sein.

Auf genau den Umstand weisen deine Recherchen hin. Unter Linux sind die Treiber in der Regel im Kernel inkludiert und daher in der von dir genutzten Architektur vorhanden.

"Normale" USB-Treiber gibt es ja für Windows 32- und 64-Bit, doch der der Palm-Software beigepackte USB-Treiber ist nötig für die speziellen Funktionen des HotSync, die den normalen Windows-USB-Treibern fehlen. Ob diese speziellen Funktionen für den Palm-HotSync im Linux-Kernel implementiert sind stelle ich mal in Frage. Immerhin gibt es einen 64-Bit-Treiber von einem Fremdanbieter, der tatsächlich auf meinem 64-Bit Windows 7 funktioniert. Ich würde aber sehr gerne diesbezüglich endlich mal von der Abhängigkeit von Windows für die Datensicherung meiner Palm Treo-Daten loskommen. Deinem Tipp, es mal mit J-Pilot auf einem Live-System zu versuchen werde ich mal nachgehen.

UlfZibis schrieb:

Da steht aber auch: "Ihre Speicherung verbraucht daher im RAM und in den Caches doppelt so viel Platz." und "... und dadurch auch RAM und Cache („Cache miss“) stärker belasten können."

Siehe dazu meinen ersten KOmmentar - bei weitem nicht alles braucht wirklich mehr Platz. Zahlen größer als Int32 haben vorher zweiSpeicherblocks gebraucht und passen nun in einen. Binärdaten etc bleiben wie sie sind. Ich bleibe dabei, dass ich nicht glaube, dass das messbar ist (unter Linux).

"Normale" USB-Treiber gibt es ja für Windows 32- und 64-Bit, doch der der Palm-Software beigepackte USB-Treiber ist nötig für die speziellen Funktionen des HotSync, die den normalen Windows-USB-Treibern fehlen.

Aber wieder kein Hinweis darauf, ob das generell unter Linux so ist. Es könnte ja sein, dass diese spezielle Funktion auch unter einem 32-Bit-Linux nicht tut, also generell unter Linux nicht implementiert ist.

Ob diese speziellen Funktionen für den Palm-HotSync im Linux-Kernel implementiert sind stelle ich mal in Frage. Immerhin gibt es einen 64-Bit-Treiber von einem Fremdanbieter, der tatsächlich auf meinem 64-Bit Windows 7 funktioniert. Ich würde aber sehr gerne diesbezüglich endlich mal von der Abhängigkeit von Windows für die Datensicherung meiner Palm Treo-Daten loskommen.

Wie gesagt, Hardware von 2004. In Hundejahren gerechnet ist das Gerät lang im Rentenalter.

redknight schrieb:

Aber wieder kein Hinweis darauf, ob das generell unter Linux so ist. Es könnte ja sein, dass diese spezielle Funktion auch unter einem 32-Bit-Linux nicht tut, also generell unter Linux nicht implementiert ist.

Es ist eben viel einfacher, andere für sich denken und recherchieren zu lassen, als vielleicht einfach mal mit einem Live-System zu testen, ob das benötigte Feature zur Verfügung steht …

redknight schrieb:

UlfZibis schrieb:

Da steht aber auch: "Ihre Speicherung verbraucht daher im RAM und in den Caches doppelt so viel Platz." und "... und dadurch auch RAM und Cache („Cache miss“) stärker belasten können."

Zahlen größer als Int32 haben vorher zweiSpeicherblocks gebraucht

... die aber bei 32 Bit nur halb so groß sind. Adresszeiger und kleine Zahlen, die eher häufiger vorkommen, verbrauchen auf einem 64-Bit System aber immer 8 Byte, auf dem 32-Bit-System nur 4 Byte.

Aber wieder kein Hinweis darauf, ob das generell unter Linux so ist. Es könnte ja sein, dass diese spezielle Funktion auch unter einem 32-Bit-Linux nicht tut, also generell unter Linux nicht implementiert ist.

Wenn das so wäre, dann würde J-Pilot ja nirgendwo lauffähig sein. Ich vermute aber eher, dass für die Palm-Hotsync-Funktionen ein, sagen wir, Zwischen-Treiber nötig ist, der auf dem vorhandenen OS-USB-Treiber aufbaut. Das scheint bei Windows so zu sein, und der ist dann ausschliesslich mit dem 32-USB-Treiber kompatibel. Da war meine Vermutung, dass das bei J-Pilot vielleicht so ähnlich ist, und ich deshalb auf dem 64-Bit-Ubuntu nicht synchronisieren konnte. Da das schon 2 Jahre her ist, habe ich es heute noch mal probiert, und HURRA, jetzt klappt's auf meinem 64-Bit-Ubuntu. Diese Bedenken wären dann also vom Tisch. ☺ Also wie sagt man so schön: "Sorry for the noise."

Wie gesagt, Hardware von 2004. In Hundejahren gerechnet ist das Gerät lang im Rentenalter.

Leider, doch wurden seit dem keine vernünftigen SmartPhones mehr gebaut, die einhändig, z.B. im schaukelnden Bus oder auf dem Fahrrad, bedienbar sind, wo der Akku 10 Jahre durchhält und außerdem auswechselbar ist, wo meine Daten nicht in irgendeiner Cloud herumgeistern und man nicht alle Nase lang einen Glaser braucht.

UlfZibis schrieb:

redknight schrieb:

UlfZibis schrieb:

Da steht aber auch: "Ihre Speicherung verbraucht daher im RAM und in den Caches doppelt so viel Platz." und "... und dadurch auch RAM und Cache („Cache miss“) stärker belasten können."

Zahlen größer als Int32 haben vorher zweiSpeicherblocks gebraucht

... die aber bei 32 Bit nur halb so groß sind.

Darauf wollte ich hinaus: Eine Zahl größer als 32Bit hat vorher 2*32 Bit gebraucht und passt jetzt in einen 64-Bit-Block. Noch besser wirds bei Berechnungen (man hat die Zahlen ja, um was damit zu machen) damit: Die Zahl musste vorher umständlich in 2 Register geladen werden und auf 2 Registern rumoperiert werden, jetzt steht sie in einem Register und kann mit Standardoperationen behandelt werden.

Adresszeiger und kleine Zahlen, die eher häufiger vorkommen, verbrauchen auf einem 64-Bit System aber immer 8 Byte, auf dem 32-Bit-System nur 4 Byte.

Korrekt gerechnet, falsch interpretiert –> 32 Bit Adressbreite führt zB zu dem bekannten Phänomen, dass nur 4 GB RAM adressiert werden können. Es führt auch zu anderen speicherbezogenen Problemen, die bei Techniken wie PAE (standardmässig an) umgangen werden indem man weitere Variablen dafür hernimmt. Schon braucht deine Table genausoviel Speicher, nutzt aber immer noch die Vorteile nicht.

Abgesehen davon: Wieviele INTS brauchst Du so im Betrieb, wie viele Binärstreams und wieviele Strings (binär und Strings sind genausogroß in der Regel, siehe oben). Dein Adresspointer von Programmen wird in der Regel in einem Register gehalten, ist also egal wie groß er sit, er braucht eh immer ein Register. Ob ich beim Wehcsel eines Tasks nun 4 oder 6 BYTE (sic) in meine 4-32 (je nach Rechner) GibiByte Hauptspeicher schreibe (wir reden also von einer Rate von 1:1.000.000.000 ), ist nicht messbar.

Wie gesagt, Hardware von 2004. In Hundejahren gerechnet ist das Gerät lang im Rentenalter.

Leider, doch wurden seit dem keine vernünftigen SmartPhones mehr gebaut, die einhändig, z.B. im schaukelnden Bus oder auf dem Fahrrad, bedienbar sind, wo der Akku 10 Jahre durchhält und außerdem auswechselbar ist, wo meine Daten nicht in irgendeiner Cloud herumgeistern und man nicht alle Nase lang einen Glaser braucht.

Wer auf dem Fahrrad ein Smartphone bedient, gehört ***zensiert*** Grüße von einem Berufspendler, der sich täglich mit solchen Spaßvögeln auseinandersetzen "darf". §Wenn ich ÖPNV fahre, bedient sich mein aktuelles Smartphone einhändig sehr gut, aber jeder soll das tun wie er will.

redknight schrieb:

Darauf wollte ich hinaus: Eine Zahl größer als 32Bit hat vorher 2*32 Bit gebraucht und passt jetzt in einen 64-Bit-Block.

So oft werden die aber nicht gebraucht, außer als Adresspointer für mehr als 4 GB RAM, die ich ja nicht habe.

Die Zahl musste vorher umständlich in 2 Register geladen werden und auf 2 Registern rumoperiert werden,

Auch 32-Bit-Prozessoren haben u.a. 64-Bit Register bzw. können die normalen zu einem Doppelregister zusammenfassen. Das Laden, Operieren und wieder Wegspeichern geht dann auch mit einem einzigen Maschinen-Code, kann aber evtl. mehr Prozessortakte kosten, den Nachteil habe ich einkalkuliert. Letzterer ist aber nichts gegen den Leistungsverlust durch Swappen.

32 Bit Adressbreite führt zB zu dem bekannten Phänomen, dass nur 4 GB RAM adressiert werden können.

Brauche ich das auf einem System mit nur 2 GB ?

Abgesehen davon: Wieviele INTS brauchst Du so im Betrieb,

Viele, für jede Zählschleife, Nummerierung, Feldindex, Enummeration, Längenvariable von Strings ... die sind in der Regel kleiner als 2³².

Dein Adresspointer von Programmen wird in der Regel in einem Register gehalten,

Um da hin zu kommen muss er aber aus dem Speicher, also auch Cache oder Programmcode, geladen und evtl. dort für spätere Verwendung wieder abgelegt werden.

Wer auf dem Fahrrad ein Smartphone bedient, gehört ***zensiert*** Grüße von einem Berufspendler, der sich täglich mit solchen Spaßvögeln auseinandersetzen "darf". §Wenn ich ÖPNV fahre, bedient sich mein aktuelles Smartphone einhändig sehr gut, aber jeder soll das tun wie er will.

Das war ja klar, dass so ein Kommentar kommen musste. 👿 Auf Wanderwegen, breiten Radwegen, im Park, zu Fuß mit einer Tasche oder was auch immer in der anderen Hand, im schaukelnden Bus, hast Du mit Deiner Karre nichts zu suchen 😉

verdooft schrieb:

Also den Speicherverbrauch kannst du leicht vergleichen, installier die 32 und 64 Bit Varianten in virtuellen Maschinen und vergleiche. Bei 2 GB Ram würde ich wohl eine ressourcenschonendere Oberfläche wählen, z.B. LXDE, dafür dann 64 Bit.

Das ist natürlich immer eine Überlegung wert. Ich habe mich aber schon ziemlich an die schöne Oberfläche von Ubuntu mit den schmalen Rahmen gewöhnt. Auf dem kleinen Bildschirm von dem "Netbook" verschwendet LXDE ganz schön Platz und zudem gibt's da kein HUD, was bei jedem Fenster die Menüleiste einspart.

Moin,

nutze 64 bit schon sehr lange auf meinem HP-Notebook mit 2 GB und läuft. Theorie und Praxis hängen da ein bisschen. Habe gerade Plasma und den FF offen, schreibe diese Nachricht, Speicherverbrauch 875 MB

Daher kann ich nur sagen teste beides und nimm nach Möglichkeit 64Bit.

peace

UlfZibis schrieb:

Auch 32-Bit-Prozessoren haben u.a. 64-Bit Register bzw. können die normalen zu einem Doppelregister zusammenfassen. Das Laden, Operieren und wieder Wegspeichern geht dann auch mit einem einzigen Maschinen-Code, kann aber evtl. mehr Prozessortakte kosten, den Nachteil habe ich einkalkuliert. Letzterer ist aber nichts gegen den Leistungsverlust durch Swappen.

Zusätzlich: Wenn Register zu Doppelregistern zusammengefasst werden, sind weniger Register verfügbar. Es müssen mehr Daten in anderen - langsameren - Speichern bleiben.

32 Bit Adressbreite führt zB zu dem bekannten Phänomen, dass nur 4 GB RAM adressiert werden können.

Brauche ich das auf einem System mit nur 2 GB ?

Brauchen ist relativ: Oben sprach ich an, dass der 32-Bit-Kernel gewisse Prozessorinstruktionen nicht nutzt, weil nicht jeder unterstützte Prozessor diese Instruktionen hat. Ich persönlich würde zB nicht mehr auf Kryptoerweiterungen verzichten wollen, in der ansonsten komplexe Operationen in nur wenigen Takten vorgenommen werden können. Zumindest nicht in Zeiten, in denen mir Händler RAM gefühlt nachwerfen, damit er bloß keine Lagerkosten verursacht.

Gleiches gilt für spezielle Operationen zur Dekompression - viele deiner Datenformate sind mit gzip verpackt, die meisten Webserver schicken ihre Inhalte per gzip an den Browser, wenn der es unterstützt. Dieser Geschwindigkeitseinbruch ist dann in der Tat fühlbar, je nach Webseiten die man so ansurft.

Abgesehen davon: Wieviele INTS brauchst Du so im Betrieb,

Viele, für jede Zählschleife, Nummerierung, Feldindex, Enummeration, Längenvariable von Strings ... die sind in der Regel kleiner als 2³².

Dein Adresspointer von Programmen wird in der Regel in einem Register gehalten,

Um da hin zu kommen muss er aber aus dem Speicher, also auch Cache oder Programmcode, geladen und evtl. dort für spätere Verwendung wieder abgelegt werden.

Siehe oben. Ob ich nun weniger Register habe und nachladen muss oder größere Zahlen nachladen muss, halte ich nich für messbar. Und wenn doch, ist es ein Problem, das man mit dem billigsten aller Performancebooster beheben kann.

Wer auf dem Fahrrad ein Smartphone bedient, gehört ***zensiert*** Grüße von einem Berufspendler, der sich täglich mit solchen Spaßvögeln auseinandersetzen "darf". §Wenn ich ÖPNV fahre, bedient sich mein aktuelles Smartphone einhändig sehr gut, aber jeder soll das tun wie er will.

Das war ja klar, dass so ein Kommentar kommen musste. 👿

Das Argument ist einfach hanebüchen:

Auf Wanderwegen, breiten Radwegen, im Park, zu Fuß mit einer Tasche oder was auch immer in der anderen Hand,

Auch da bist Du einer von vielen Verkehrsteilnehmer und hast gefälligst alle anderen zu beachten. Ob die nun mit dem Rad, zu Fuß, einen Kinderwagen schiebend oder mit dem Rollator unterwegs sind.

im schaukelnden Bus, hast Du mit Deiner Karre nichts zu suchen 😉

Wie gesagt, ich bediene mein Smartphone mit einer Hand, auch im ÖPNV oder auf einer schaukelnden Autofähre. Man scheint das also lernen zu können, wenn man es denn will. Aber das ist zugegebenermaßen Offtopic.

Bleibt also wie von 2 Vorpostern vorgeschlagen nur der Test: 32 Bit gegen 64 Bit Live-Medium. Viel Spaß beim experimentieren - wenn du es denn rausfinden willst 😉

UlfZibis schrieb:

Hallo,

ich stehe vor der Frage, auf einem ASUS F200M mit nur 2 GiB RAM ein Ubuntu 32-Bit oder 64-Bit zu installieren.

Hat da jemand Erfahrungswerte, wie hoch da der Unterschied z.B. bzgl. Speicherverbrauch ist.

Marginal.

https://forum.ubuntuusers.de/topic/32-bit-lubuntu-oder-64-bit-lubuntu-oder-server/#post-8606113

Ich denke, es könnte schon mal das Zünglein an der Waage sein, wann das System anfängt zu "swappen" wenn man gleichzeitig Firefox mit einigen Addons und offenen Tabs, Thunderbird mit mehreren E-Mail-Konten und vielleicht noch 2..3 andere größere Anwendungen offen hat. Auf meinem anderen Ubuntu 64-Bit-System mit 4 GiB RAM greift sich Firefox nach einiger Zeit durchaus schon mal 2 GiB Speicher, und je nach weiterer Auslastung kommt es auch da zum "swappen".

Linux alloziert, anders als Windows, so viel Speicher, wie der Hauptspeicher her gibt. Programme bekommen virtuell mehr Speicher als eigentlich vorhanden ist, und die HD bekommt auch noch was ab. Erst, wenn gar nichts mehr geht, fängt das System an zu 'swappen', damit es nicht hängt. Der RAM Verbrauch eines Programms sagt daher gar nichts aus. Ein Unity mit 64 Bit läuft locker auf 512 MB RAM, wenn man nicht alles gleichzeitig 'aufmacht' und etwas warten kann (kleiner Cache).

Ein nicht unerheblicher Teil des RAM wird als Cache verwendet. Z.B. habe ich bei mir ein 64 Bit System mit 16 GB RAM. Aktuell werden davon ca. 1.8 GB für die laufenden Programme 'verbraucht', was schon sehr großzügig ist. Der Rest ist Bequemlichkeit vom System, Cache, Buffer usw.

Anderes Beispiel:
Ubuntu-Unity mit 32 GB RAM, 7 virtuelle Maschinen unter KVM, jede davon 'sieht' 4-8 GB RAM.
Der RAM Verbrauch liegt bei 8GB. Der Rest ist Cache, 22GB und noch einige Buffer.
D.h. der Kernel mit KVM gibt jeder VM die angeforderte Menge RAM, alloziert aber selbst deutlich weniger, um IO in den VMs zu bevorzugen. Und dann ist der Kernel in der Lage, identische Speicherseiten zu deduplizieren, was bei ähnlichen Daten viel RAM spart.

Maw. Linux optimiert sich automatisch, je nach Verfügbarkeit des RAM. Damit sind 32 Bit Systeme obsolet geworden. Wenn die CPU es kann, immer 64 Bit, nix anderes.

Und was den angeblichen RAM Verbrauch durch die doppelte Wortbreite angeht, das ist wirklich marginal. Die meisten Programme haben 8 Bit Strukturen, ASCII, Bilder IO/Daten, Nur die relativ wenigen Pointer, um an die Daten heranzukommen, haben 64 Bit. (siehe das oben angegeben Posting)

I hope this helps

rleofield