staging.inyokaproject.org

redknight schrieb:

danke für deine Messwerte, ich habe nicht geglaubt, dass der Unterschied so deutlich ist.

Ja da war ich auch überrascht, da ich ja Deinen Erfahrungsschatz und Deine Argumente bzgl. des Speicherverbrauchs – zumindest heimlich – auch nicht unterschätzt hatte. Noch mehr hat mich aber überrascht, dass die 32-Bit-Version auch schneller läuft, zumindest was das Laden in den Speicher betrifft. Könnte daran liegen, dass in so einem damals 300-€-Gerät nicht die schnellste IO verbaut ist, da nützt dann die schnellste CPU nichts, wenn der Speicherzugriff lahmt.

Zu den einzelnen Messpunkten:

• Die Reaktionszeit, die du beim Tabwechsel

Hab' keinen Tabwechsel getestet. Ob der aber 1,5 oder 2 Sekunden für's Nachladen beansprucht, wäre für mich nicht maßgeblich.

(für mich sind Brwoserprofile mit 70 Tabs schon fern der Realität, aber mag ja sein, dass andere Leute das anders sehen)´,

Ja, schlechte Gewohnheit von mir, die aber bei mit der Realität enspricht, dass ich mir schnell mal "zwischendurch" was Neues anschaue, und dann vernachlässige, unnötiges wieder zu schließen. Zmindest für diesen Test war sie aber mal nützlich.

auswertest, lässt sich so nicht einbeziehen. Wie Du selbst sagst, an der Stelle ist dein RAM einfach voll und IRGENDWAs wird vom Kernel abgeschossen, um das System weiter zu erhalte,

Ach Du meinst den Wechsel von 77 auf 210 Tabs ? Auf dem 32-Bit-System war der Speicher dabei eben noch nicht voll, und der Kernel musste nichts abschießen.

das Ergebnis ist nicht reporduzierbar.

Warum nicht? Hab's mehrfach wiederholt mit gleichem Ergebnis.

• Geschwindigkeit: Du misst den Start des Browsers. Der hängt unter anderem davon ab, wie schnell das Profil eingelesen werden kann, ob du Tabs beim Start automatisch aktualisierst, etc. Das halt ich niciht für aussagekräftig, je nachdem was deine Platte grade zu tun hat oder auch nicht.

Das gesamte Profil, also mit allen Addons etc. und nicht nur die Manager-Sitzungen, hat ca. 100 MB, das schafft eine Festlatte in < 10 Sekunden, daran kann's nicht liegen. Während des Starts und der 2..4 Minuten des Wechsels war die Festplatte größtenteils still, das Aufbauen der Datenstrukturen im Speicher (viele Adresszeiger!) muss so lange gedauert haben. Die Tabs wurden dabei weder geladen noch automatisch aktualisiert. Warum der Sitzungsmanager, ohne die Seiten zu laden, also nur für die Meta-Daten, pro Tab ca. 2 MiB (bei 64 Bit) verbrät, ist mir allerdings auch ein Rätsel. Wenn ich die 210 Tabs alle nacheinander anklicke und damit das Laden der Seiten erzwinge, kollabiert der Speicherbedarf sowieso. Aber wie auch immer, das wird auf beiden Architekturen nach den gleichen Algorithmen ablaufen, warum soll der Vergleich zwischen diesen nicht aussagekräftig sein?

Wie bereits gesagt, der Gewinn wird bei Kompressions- und Verschlüsselungsoperationen zB erzielt.

Das mag sein, das ist für mich aber verschmerzbar, ob der Seitenaufbau 2, 4 oder 6 Sekunden dauert, oder wie lange eine E-Mail-Verschlüsselung dauert, da dürfte die Internetbandbreite, bei mir 10/0,7 MBit/s (down/up), der Flaschenhals sein, der Knackpunkt ist, wann das System zu swappen anfängt, erst recht wenn evtl. noch weitere Programme geöffnet sind.

Ob/ Wie du das geprüft hast, kann ich deinen Werten nicht entnehmen.

Stimmt! Ich habe aber mal zum Test diesen Film hier ablaufen lassen. Auf dem 32-Bit-System schwankte die CPU-Zeit zwischen 16 und 22 % und auf den 64er zwischen 14 und 20 %, im praktischen Betrieb also vernachlässigbar, auf beiden Systemen lief der Film absolut flüssig wie auch alles andere.

Ich kann mir das nur so erklären: Gängige Programme dürften so kompiliert sein, dass sie erkennen, auf welcher CPU sie laufen, und dann zumindest für die kritischen Routinen den passenden Code auswählen, der die auf der CPU zur Verfügung stehenden Register und Maschinenbefehle voll ausnutzt, auch unter einem 32-Bit-OS. Auf dem 32-Bit-OS kommt dann sogar der Vorteil zum Tragen, dass die zahlreichen Adresszeiger schneller aus dem RAM und wieder zurück geladen werden und der CPU-Cache nicht so schnell ausgereizt ist.

apt-ghetto schrieb:

UlfZibis schrieb:

In welchen Modus läuft denn dann mein Ubuntu-32, wenn nicht im EFI-Modus?

Schwierig zu sagen. Je nach UEFI ist es möglich einen Installationsstick entweder im EFI- oder BIOS-Modus zu starten, ohne dass die Einstellung geändert werden muss.

Ich nehme an, Du meinst das im Sinne der Antwort von Benno-007. Die Frage bezog sich aber auf die Festplatten-Installation, da wird gemäß dieser Antwort auch beim 32-Bit-System vom EFI-Modus ausgegangen. Wir haben immer noch nicht klargestellt, was unter "läuft im EFI-Modus" genau zu verstehen ist.

Wurde dein 32-bit Ubuntu von os-prober gefunden?

Ja, vom 64-Bit-System aus mittels update-grup, dabei wurde aber ro quiet splash $vt_handoff im 32-Bit-Menüeintrag nicht eingetragen, sodass beim Start die OS-Meldungen über den Bildschirm sausen statt dem violetten Hintergrund.

Oder hast du manuell mittels 40_custom einen Eintrag hinzugefügt?

Wurde aber von update-grup angelegt.

Ausserdem habe ich heute folgendes gefunden:

• https://wiki.ubuntu.com/EFIBootLoaders → Scheinbar werden auch die 32-bit Kernel so kompiliert, dass sie mittels EFISTUB geladen werden können. Dann brauchst du gar keinen Grub.

• http://askubuntu.com/questions/510856/how-to-boot-load-the-kernel-using-efi-stub-efistub-loader → Ich habe es nicht ausprobiert. Bei Archlinux mountet man die EFI-System-Partition direkt nach /boot.

Interessant, habe ich aber nicht auch noch Zeit zu, das zu testen.

UlfZibis schrieb:

redknight schrieb:

das Ergebnis ist nicht reporduzierbar.

Warum nicht? Hab's mehrfach wiederholt mit gleichem Ergebnis.

Weil es dir auch passieren kann, dass alle für dich notwendigen Prozesse bestehen bleiben und Du trotz überlaufendem RAM weitermachen kannst 😉

• Geschwindigkeit: Du misst den Start des Browsers. Der hängt unter anderem davon ab, wie schnell das Profil eingelesen werden kann, ob du Tabs beim Start automatisch aktualisierst, etc. Das halt ich niciht für aussagekräftig, je nachdem was deine Platte grade zu tun hat oder auch nicht.

[...]Aber wie auch immer, das wird auf beiden Architekturen nach den gleichen Algorithmen ablaufen, warum soll der Vergleich zwischen diesen nicht aussagekräftig sein?

Weil dieser Vorgang - wie du selbst feststellst - I/O-lastig ist. Die Seite wird ja zunächst aus dem Cache geladen und neu gerendert. Wenn zufällig grade was anderes gelesen/geschrieben wird, dauert das laden halt länger.

Wie bereits gesagt, der Gewinn wird bei Kompressions- und Verschlüsselungsoperationen zB erzielt.

Das mag sein, das ist für mich aber verschmerzbar, ob der Seitenaufbau 2, 4 oder 6 Sekunden dauert, oder wie lange eine E-Mail-Verschlüsselung dauert, da dürfte die Internetbandbreite, bei mir 10/0,7 MBit/s (down/up), der Flaschenhals sein, der Knackpunkt ist, wann das System zu swappen anfängt, erst recht wenn evtl. noch weitere Programme geöffnet sind.

Wie bereits schon mal geschrieben: RAM ist der Teil Performance, der mittlerweile am billigsten zu erweitern ist. Wenn das System zu swappen anfängt, dann brauche ich offensichtlich RAM ( auch wenn es unter 32-Bit nur kurz davor ist) und dann werfe ich da 70€ drauf anstatt Zeit im Wert von 150 Euro für die Optimierung zu verwenden 😉

Ob/ Wie du das geprüft hast, kann ich deinen Werten nicht entnehmen.

Stimmt! Ich habe aber mal zum Test diesen Film hier ablaufen lassen. Auf dem 32-Bit-System schwankte die CPU-Zeit zwischen 16 und 22 % und auf den 64er zwischen 14 und 20 %, im praktischen Betrieb also vernachlässigbar, auf beiden Systemen lief der Film absolut flüssig wie auch alles andere.

Was schon mal den Unterschied zwischen den Powerstates ausmachen kann. Auf einem Mobilgerät damit dann auch, wie lange der Akku hält.

Ich kann mir das nur so erklären: [...]

Nö. Programme interagieren mit dem Kernel und nicht mit der CPU direkt. Es ist also die Frage, welche instruktionssätze der kernel unterstützt.

UlfZibis schrieb:

Oder hast du manuell mittels 40_custom einen Eintrag hinzugefügt?

Wurde aber von update-grup angelegt.

ne ne ne → update-grub schreibt die grub.cfg neu, aber macht keine Einträge in die 40_custom.

Mir wird das ganze mittlerweile zu chaotisch - keinen Bock mehr darauf, weitere kostbare Zeit zu investieren → Bedankt

Frieder108 schrieb:

ne ne ne → update-grub schreibt die grub.cfg neu, aber macht keine Einträge in die 40_custom.

Hast mich erwischt, ich war müde und wollte mich kurz fassen. Also genauer gesagt, ich hatte irgendwann noch 'ne '41_custom, 'ne '42_custom, 'ne '43_custom und 'ne '44_custom, hab' aber auch mit Grub-Customizer rumgespielt und konnte nicht mehr genau nachvollziehen, wer die jeweils erzeugt hat.

redknight schrieb:

Warum nicht? Hab's mehrfach wiederholt mit gleichem Ergebnis.

Weil es dir auch passieren kann, dass alle für dich notwendigen Prozesse bestehen bleiben und Du trotz überlaufendem RAM weitermachen kannst 😉

Also bei mir war es reproduzierbar, sowohl in der gleichen Login-Sitzung als auch nach Neustart, womit sich die Prozesse im RAM wohl aufgelöst haben sollten.

Weil dieser Vorgang - wie du selbst feststellst - I/O-lastig ist.

Versteh' ich nicht. Auch wenn die I/O-Lastigkeit der Grund für die unterschiedlichen Ergebnisse ist, ist es für mich von Aussagekraft, dass das Laden und Ausführen eines Programms – hier Firefox, der für mich zum üblichen Workflow gehört – auf dem 64-Bit-System länger dauert, als auf dem 32er.

Die Seite wird ja zunächst aus dem Cache geladen und neu gerendert.

Die Seiten in den Tabs werden erst dann aus dem Cache geladen und neu gerendert, wenn ich die Tabs anklicke. Da ich das nicht getan habe, hatte das auch keinen Einfluss auf meine Messwerte.

Wenn zufällig grade was anderes gelesen/geschrieben wird, dauert das laden halt länger.

Die Zufälle fielen aber immer wieder "zufällig" zugunsten des 32-Bit-Systems aus, und wie gesagt, die Festplatte war dabei im wesentlichen still.

Wenn das System zu swappen anfängt, dann brauche ich offensichtlich RAM ( auch wenn es unter 32-Bit nur kurz davor ist) und dann werfe ich da 70€ drauf anstatt Zeit im Wert von 150 Euro für die Optimierung zu verwenden 😉

Erst mal investiere ich nicht 70 € in ein Gerät, dass kaum mehr Wert ist, und 2. wären die komplett aus dem Fenster geworfen, da das Gerät keinen Steckplatz hat, wo ich die reinstecken könnte, wie ich schon berichtete, alles RAM da drin ist fest verlötet. Ziel ist es auch nicht, Wirtschaftlichkeit mit Maß an westlichen Stundensätzen zu generieren, sondern ein für meinen Zweck funktionsfähiges Gerät bestmöglich zu nutzbar zu machen, statt es der Müllpresse zu überlassen. Ich will das Gerät im wesentlichen als stromsparendes handliches Gerät zum Abspielen für Musik auf der Heimanlage oder außerhalb und zum leichtgewichtigen gelegentlichen Surfen und Arbeiten unterwegs nutzen.

Stimmt! Ich habe aber mal zum Test diesen Film hier ablaufen lassen. Auf dem 32-Bit-System schwankte die CPU-Zeit zwischen 16 und 22 % und auf den 64er zwischen 14 und 20 %, im praktischen Betrieb also vernachlässigbar, auf beiden Systemen lief der Film absolut flüssig wie auch alles andere.

Was schon mal den Unterschied zwischen den Powerstates ausmachen kann. Auf einem Mobilgerät damit dann auch, wie lange der Akku hält.

Ist das in der Praxis relevant, ob der Akku 7,5 oder 8 Stunden durchhält, bzw. merklich umgekehrt, wenn das Gerät unnötig Leistung zum Swappen verbrät?

Ich kann mir das nur so erklären: [...]

Nö. Programme interagieren mit dem Kernel und nicht mit der CPU direkt. Es ist also die Frage, welche instruktionssätze der kernel unterstützt.

Du meinst jeder Maschinencode des Userprogramms wird erst durch den Kernel geschleift und da auf dessen Zulässigkeit überprüft bevor er zu Ausführung kommt? Kannst Du mir einen Programmierer Deines Vertrauens nennen, der das bestätigen kann? Außerdem zeigen die Messwerte, dass im 64-Bit-System die Kernel-Tätigkeit zu keinem Zeitpunkt nennenswert schneller ausgeführt wurde.

Nur mal so als Einwurf bzgl. Reproduzierbarkeit, weil mich das Ergebnis auch überrascht hat: Es gäbe da diverse Benchmarks, die man mal laufen lasse könnte. Dann hätte man reproduzierbare Ergebnisse die man dann vergleichen kann ☺

UlfZibis schrieb:

redknight schrieb:

Weil dieser Vorgang - wie du selbst feststellst - I/O-lastig ist.

Versteh' ich nicht. Auch wenn die I/O-Lastigkeit der Grund für die unterschiedlichen Ergebnisse ist, ist es für mich von Aussagekraft, dass das Laden und Ausführen eines Programms – hier Firefox, der für mich zum üblichen Workflow gehört – auf dem 64-Bit-System länger dauert, als auf dem 32er.

Sinn ist es eigentlich Komponenten isoliert betrachten zu können. Damit erhält man dann auch übertragbare Ergebnisse.

Ist das in der Praxis relevant, ob der Akku 7,5 oder 8 Stunden durchhält, bzw. merklich umgekehrt, wenn das Gerät unnötig Leistung zum Swappen verbrät?

Natürlich. Schnellere Wechsel in energiesparendere Modi bedeutet in der Regel auch geringere Abwärme, seltener drehende Lüfter, etc. Auch wenn ein paar Prozent jetzt nicht als so viel erscheinen…

Nö. Programme interagieren mit dem Kernel und nicht mit der CPU direkt. Es ist also die Frage, welche instruktionssätze der kernel unterstützt.

Öh, Zwischenfrage: Welche Instruktionen verwendet werden hängt doch davon ab, welche Compilerflags ich nutze. Das ist doch dem Kernel egal, oder nicht? Ich kann es halt dann möglicherweise nicht ausführen…

Developer92 schrieb:

Nur mal so als Einwurf bzgl. Reproduzierbarkeit, weil mich das Ergebnis auch überrascht hat: Es gäbe da diverse Benchmarks, die man mal laufen lasse könnte. Dann hätte man reproduzierbare Ergebnisse die man dann vergleichen kann ☺

Schick' doch mal 'n Link zum Benchmark Deines Vertrauens, möglichst aus dem Canonical-Repository.

Natürlich. Schnellere Wechsel in energiesparendere Modi ...

bleiben allerdings aus, wenn das Swappen losgeht, und das passiert im 64-Bit-System viel eher.

Öh, Zwischenfrage: Welche Instruktionen verwendet werden hängt doch davon ab, welche Compilerflags ich nutze. Das ist doch dem Kernel egal, oder nicht?

Sehe ich auch so!

Ich kann es halt dann möglicherweise nicht ausführen…

Welcher Mechanismus soll das den entscheiden?

UlfZibis schrieb:

Developer92 schrieb:

Nur mal so als Einwurf bzgl. Reproduzierbarkeit, weil mich das Ergebnis auch überrascht hat: Es gäbe da diverse Benchmarks, die man mal laufen lasse könnte. Dann hätte man reproduzierbare Ergebnisse die man dann vergleichen kann ☺

Schick' doch mal 'n Link zum Benchmark Deines Vertrauens, möglichst aus dem Canonical-Repository.

Der Faden wurde zu meiner Überraschung geteilt. Mit dem Thema geht es nun hier weiter.

Hier gibt es nun eine Anleitung zum Thema.

Developer92 schrieb:

matze31 schrieb:

Es läuft auch wunderbar, jetzt mal die Frage, was kann passieren wenn ich es mit einen 32bit Rechner betreibe? Bisher hab ich nichts negatives festgestellt.

Öhm, die 64bit Variante wird auf einem 32bit Rechner nicht laufen, ganz einfach. Falsche Architektur ☺

Umgekehrt aber schon da ich eine 32 Bit Version schon auf Amd64 installiert hatte. AM2 Sockel bzw X2 Cpu läuft aber besser damit. Am besten eine 32 Bit Version ziehen und gut.

DPITTI schrieb:

Umgekehrt aber schon da ich eine 32 Bit Version schon auf Amd64 installiert hatte. AM2 Sockel bzw X2 Cpu läuft aber besser damit. Am besten eine 32 Bit Version ziehen und gut.

Da musst du aber auf Software die es nur für 64-Bit gibt verzichten, zb. SkypeforLinux,Google Chrome,...

DPITTI schrieb:

Umgekehrt aber schon da ich eine 32 Bit Version schon auf Amd64 installiert hatte.

Nicht immer. "Reine" 64Bit Prozessoren können das nicht, die hauptsächlich verwendeten Prozessoren sind allerdings x68_64, und unterstützen daher beide Architekturen.

AM2 Sockel bzw X2 Cpu läuft aber besser damit. Am besten eine 32 Bit Version ziehen und gut.

Schlechte Idee. Das Maximum holt man aus einem aktuellen Prozessor nur heraus, wenn man auch entsprechend Software nutzt. D.h. konkret: 64Bit Prozessor → 64Bit Betriebssystem und Software. Zumal 32Bit in Zukunft immer schlechter unterstützt wird, weil 64Bit Prozessoren seit mehr als 10 Jahren (!) Standard sind. Erste Linuxdistributionen haben den 32Bit-Support bereits eingestellt.

Developer92 schrieb:

DPITTI schrieb:

AM2 Sockel bzw X2 Cpu läuft aber besser damit. Am besten eine 32 Bit Version ziehen und gut.

Schlechte Idee. Das Maximum holt man aus einem aktuellen Prozessor nur heraus, wenn man auch entsprechend Software nutzt. D.h. konkret: 64Bit Prozessor → 64Bit Betriebssystem und Software.

Das stimmt nur, wenn man genügend RAM hat, sonst ist man auch auf einem 64-Bit-Rechner im Regelfall besser mit einem 32-Bit-Ubuntu beraten, siehe!

matze31 schrieb:

Heißt das ich muss bald mein geliebten Laptop "wegschmeißen" und einen neuen kaufen, oder unterstützt Ubuntu noch ein bisschen die 32bit Version?

Nein, erstmal haben wir ja festgestellt, dass Du in Wirklichkeit einen 64-Bit-Rechner hast. Wenn der aber wenig RAM hat, kann wie oben beschrieben, darauf dennoch ein 32-Bit-Ubuntu Sinn machen, und wenn es ein EFI-BIOS hat, gibt es dazu hier eine Anleitung.

UlfZibis schrieb:

Das stimmt nur, wenn man genügend RAM hat, sonst ist man auch auf einem 64-Bit-Rechner im Regelfall besser mit einem 32-Bit-Ubuntu beraten, siehe!

Ich war an der Diskussion beteiligt, und warte immer noch auf reproduzierbare Ergebnisse auf Basis von Benchmarks 😉

Auch wenn deine Werte trotzdem beeindruckend sind. Ich hätte damals auch nicht gedacht, dass das so viel Unterschied macht. Aber ich vertrete trotzdem meine oben genannte Meinung: Kann der Prozessor 64Bit, installiert man auch 64Bit. Man kann ja auch den RAM noch aufrüsten sollte man weniger als 4GB verbaut haben (und das bringt zumindest einiges an Geschwindigkeit. SSD noch dazu und fertig).

Developer92 schrieb:

Ich war an der Diskussion beteiligt, und warte immer noch auf reproduzierbare Ergebnisse auf Basis von Benchmarks 😉

Welches Benchmark hättest Du denn gerne? Es müsste ja eins sein, dessen Ergebnis vom unterschiedlichen Speicherverbrauch einer 32- ./. 64-Bit-Architektur abhängig ist.

Auch wenn deine Werte trotzdem beeindruckend sind. Ich hätte damals auch nicht gedacht, dass das so viel Unterschied macht. Aber ich vertrete trotzdem meine oben genannte Meinung: Kann der Prozessor 64Bit, installiert man auch 64Bit. Man kann ja auch den RAM noch aufrüsten sollte man weniger als 4GB verbaut haben

Letzteres ging bei dem Rechner nicht, wie damals schon deutlich genug hervorgehoben. Eins der Netbooks, wo das RAM fest verlötet ist. Mein Credo für Ubuntu-32 ist immer im Zusammenhang mit der fixen RAM-Begrenzung zu sehen, nicht mit der theoretischen RAM-Aufrüstmöglichkeit. Hab' vor einiger Zeit sogar ein 1-GB Netbook mit Ubuntu-32 ausgestattet mit dem Hinweis an den Nutzer, dass man es für 30 € auch auf 2 GB aufrüsten könne. Er ist bisher bestens zufrieden, da er auf Reisen damit weder 100 Tabs im Firefox aufmachen will, noch mehrere fette Anwendungen gleichzeitig nutzen.

SSD noch dazu

Ersten will man bei so einem Sparrechner dafür nicht unbedingt noch 100 € ausgeben, zweitens soll es Menschen geben, die mit resourcenschonender Gesinnung unterwegs sind, und drittens wird dadurch kaum was besser, wenn das RAM voll ist.