staging.inyokaproject.org

Reinarden schrieb:

Der recht komplexe Flightgear-Flugsimulator läuft auf diesem 64-Bit-Xubuntu mit 2 GB RAM gerade noch so – er lagert aber regelmäßig aus (Swap). Da würden die ~30% weniger RAM-Verbrauch einer 32-Bit-Version sicher meßbare Unterschiede im Gesamtlaufverhalten ergeben.

Könnte sein. Wenn Du noch n' bisschen Platz auf der Platte hast, probier' mal die 32er-Xubuntu und vielleicht auch Swapspace, brauch weniger Platz, hab' gute Erfahrungen damit gemacht.

Da ich mich mit AMD/Intel-Maschinencode nicht auskenne, hier meine laienhafte Frage: genügt es bereits, wenn ich unter so einem 64-Bit-Ubuntu die 32-Bit-Version von Flightgear („flightgear:i386“) benutze, oder müßte es ein 32-Bit-Ubuntu mit 32-Bit-Applikationen sein, um ähnliche Ergebnisse wie Deine früher zitierten 32-64-Bit-Vergleiche zu sehen?

Hm, da kann ich nur etwas ins Blaue raten. Wird sicher auch weniger Speicher brauchen, aber bzgl. der Einbindung im 64er-OS könnte da bzgl. der Geschwindigkeit auch der Schuss nach hinten los gehen. Zumindest die Schnittstellen zum Kernel müssten dann vermutlich dennoch mit 64-Bit-Adresszeigern bedient werden. Für die reinen Grafikberechnungen dürften die gleichen Schlüsse gezogen werden müssen, wie für mein Filmbeispiel, also die Fähigkeiten der CPU und der GPU werden so gut wie unter 4. möglich ausgenutzt. Aber zugegeben reine Spekulation.

P.S. War nicht noch ein Punkt beim Thema „Java schneller als C“ der, daß, im Gegensatz zu statisch compiliertem Maschinen-Code, die JVM das Laufzeitverhalten der Routinen untersucht und dann diese besonders optimiert, eben anhand des Laufzeitverhaltens? Während ja der statische Compiler vom Laufzeitverhalten gar nichts wissen kann.

Genau das meinte ich mit "gibt es in der JVM weitere Optimierungen".

Developer92 schrieb:

Ich denke redknight meinte, dass die Java-Laufzeitumgebung nur auf diejenigen Funktionen zugreifen kann, welche vom Kernel angeboten/freigegeben werden.

Das ist richtig, das betrifft aber programmatische Funktionen, nicht CPU-Maschinenbefehle, um die es hier geht, die können nicht durch Kernel-Funktionen aufgerufen werden, weder grundlegende Befehle z.B. für Ganzzahl-Addition noch ausgefuchste für AES. Der Programmcode selbst besteht aus solchen Maschinenbefehlen, mit dessen Hilfe es überhaupt erst Kernelfunktionen aufrufen kann. Ein Musiker kann nur mit Zugang zum Konzertsaal Musik machen, dann aber mit allen Instrumenten, die dort stehen.

Moment, denn: Wenn ich ein Stück Hardware habe (Kryptobeschleuniger oder ähnliches),

"Ähnliches" wäre z.B. das Addierwerk, beide sind integraler Teil der Hardware Namens "CPU" und müssen einem Programm zur Verfügung stehen um überhaupt Kernelfunktionen aufrufen zu können, siehe oben. Genauso wie der Kernel nicht darüber entscheiden kann, ob Du auf der Hardware "Drucker" nur bestimmte Buchstaben benutzen darfst.

und der Kernel die Hardware nicht direkt ansprechen kann (sprich für den Kryptobeschleuniger keine Schnittstelle anbietet),

Der Kernel hat weder für den Addierer noch für den Kryptobeschleuniger eine Schnittstelle. Beides steht sowohl im Kernel-Mode als auch im User-Mode zur Verfügung.

so kann ich auch aus dem Userspace heraus die Hardware nicht verwenden. Denn hierzu muss der Kernel, auch wenn das Gerät nicht direkt vom Kernel verwendet werden kann, ja trotzdem eine Möglichkeit haben damit zu kommunzieren.

Bildlicher Vergleich: Der Musiker kommuniziert nicht mit dem Instrument, sondern mittels dessen mit dem Publikum. Hat das Instrument nur 6 Saiten, muss er Hilfsgriffe verwenden, um nicht direkt vorliegende Töne spielen zu können. Auf einem Klavier kann er deswegen mehr Töne in gleicher Zeit spielen.

D.h. irgendeine Schnittstelle brauche ich ja.

Ja, die Tür zum Konzertsaal.

Insofern bedingt eine vom Userspace aus erreichbare Hardware auch eine gewisse Unterstützung vom Kernel.

Der Meister wie der Schüler können das Klavier benutzen, sofern sie Zugang zum Konzertsaal haben.

Ohne großartig zu wissen wie der Java-HotSpot-JIT-Compiler arbeitet: Prinzipiell könnte man in Java eine API anbieten, die bspw. mittels AES verschlüsselt.

Ja.

Ich schreibe dafür dann ein Programm. Wie dann die AES-Verschlüsselung implementiert ist hängt dann aber von meiner JVM ab, und die könnte dann beispielsweise die Verschlüsselung in Software machen (als Fallback), oder, sofern der Kernel das AES-NI-Modul geladen hat, auch direkt auf entsprechende Hardware zurückgreifen.

Der Kernel kann keine AES_(Befehlssatzerweiterung) laden, entweder hat die CPU eine, oder eben nicht. Nur im ersten Fall macht es für den JIT Sinn, Dein Programm so kompilieren, dass deren Schnelligkeit genutzt wird, muss er aber nicht (Fallback). Wenn kein Klavier zum Ensemble gehört, sondern nur eine Gitarre, müssen Gitarren-Noten (=Maschinencode) erzeugt werden.

In meinen vorherigen Posts ging ich aber davon aus, dass wir von Sprachen reden, die keine JVM oder ähnliches benötigen, also bpsw. kompilierten C-Code, der direkt (nativ) ausführbar ist. Hierbei muss ich entsprechende Hardwareunterstützung selbst entwickeln (oder auf bestehende Lösungen zurückgreifen die dann einkompiliert werden), aber der Kernel wird mir hier nicht dazwischenfunken und sagen "Hey, du hast da ja AES per Software implementiert, ich mach das jetzt aber einfach in Hardware weil's schneller geht". Das war ursprünglich mein Punkt.

Jain ! Der Linux-Kernel zensiert und interpretiert Deine Software nicht (ein Windows-Virenscanner, der vor dem Kernel sitzt, schon 🦆 ), das ist richtig, doch hat er für das Userprogramm Adressenbereiche, die direkt auf Hardware-Komponenten wie z.B. Laufwerke gehen, gesperrt. Von daher kann ein Userprogramm normalerweise keine Hardware "unterstützen". Das Rechenwerk in der CPU, das sowohl einfache als auch AES-Befehle (falls implementiert) ausführt, hat aber keine solche Adresse, die gesperrt werden könnte.

Ich behaupte also, dass ein C-Programm und ein Java-Programm, welche gut implementiert sind, auf identischer Hardware und bei gleicher Ausnutzung der Hardwarefunktionen gleich schnell laufen.

Das kann hinkommen, wenn Du für alles das "Rad neu erfindest", also keine fertigen Bibliotheken nutzt, und es genau für diesen einen x86-abc-xyz-Revision-14-Prozessor kompilierst. Das wird aber dann nur auf genau dieser Maschine, und nicht auf jeder x-beliebigen mit Ubuntu-32 laufen. Freaks kompilieren aus genau diesem Grund Ihr Ubuntu selber, um das letzte an Speed noch herauszuholen.

Und gcc wird nicht Befehlssatzerweiterungen verwenden, die nur begrenzt verfügbar sind, wenn ich diese nicht explizit aktiviere.

Genau, und wenn Du sie aktivierst, dann musst Du die CPU-Flags abfragen und dazu passende langsamere "Fallbacks" parallel dazu einkompilieren. Ausgefuchste speed-geile Software, wie z.B. Flightsimulator, MPEG4-Encoder etc., wird genau davon Gebrauch machen, behaupte ich jetzt mal frech, und deshalb laufen die zeitkritischen Routinen auf dem gleichen Prozessor unter Ubuntu-32 genauso schnell wie unter Ubuntu-64, ... und wenn komplizierte Datenstrukturen aufgebaut werden müssen, sogar schneller, weil die 64-Bit-Adresszeiger einfach mehr "Masse" darstellen, die bewegt werden muss.

Reinarden schrieb:

Ist eine Tatsache, kein Gerücht; sehr vereinfacht gesagt wegen dynamischem Compilat (JIT) in einer VM versus statischem Compilat (Exe).

Kurz gesagt: Nein. Wenn mein Java-Programm schneller läuft als mein C-Programm habe ich bei meinem C-Programm Mist gebaut. Wenn mein C-Programm meine Hardware optimal ausnutzt kann auch mein Java-Programm dieselbe Aufgabe nicht schneller ausführen. Wie soll das denn gehen?

Ausführlich beschrieben und belegt in der Fachliteratur, welche ich tatsächlich gelesen habe vor Jahren.

Wenn du entsprechende Fachliteratur verlinken würdest, könnte ich mir das ja ansehen…

UlfZibis schrieb:

In jeder Programmiersprache ist man darauf angewiesen, fertige vorkompilierte Bibliotheken zu verwenden.

Nicht direkt. Ich kann alles von Hand machen, ist halt wahnsinnig aufwendig, aber es geht. Für Mikrocontroller habe ich das schon diverse Male gemacht, aber man hängt tagelang wirklich nur in der Doku des Mikrocontrollers um eine Software zu schreiben die dann genau auf einem einzigen Controller läuft. Abgesehen von den von der Sprache definierten Konstrukten natürlich, die sind nunmal vorgegeben.

Macht halt normalerweise kein Mensch, weil Standardbibliotheken gut laufen und es keinen Sinn macht, diese jedes Mal neu zu implementieren.

Hat man z.B. eine Bibliotheksfunktion, die die Sinus-Funktion berechnet, ist die im Fall von C schon statisch in Maschinencode compiliert, und zwar so, dass sie auf allen x86-Varianten läuft, für die sie spezifiziert ist. Manche x86-CPU's haben aber erweiterte Befehlssätze, mit denen ein Sinus schneller ausgerechnet werden kann. Für den Fall kann der Ersteller der Bibliothek vorsorgen, indem er eine Abfrage einbaut, die den tatsächlichen Befehlssatz der vorliegenden CPU feststellt, und parallel mehrere Routinen für die Sinusberechnung für unterschiedliche Befehlssätze einkompiliert, die dann abhängig vom Ergebnis der vorherigen Abfrage ausgeführt werden. Hierbei ist aber zu bedenken:

1. Nicht jeder Bibliotheksentwickler treibt diesen Aufwand.

2. Selbst wenn, werden dabei, um den Aufwand in Maßen zu halten, nicht alle theoretisch verfügbaren Befehlssätze berücksichtigt.

Ähm, das ist doch das, was ich geschrieben hatte, und ebenso auf Java übertragbar. Auch Java berücksichtigt nicht zwingend alle Befehlssatzerweiterungen sondern eben auch nur die, welche implementiert wurden. Man verschiebt das Problem vom Programm in die JVM, mehr nicht.

Beim JAVA-JIT-Compiler sieht die Sache anders aus, da die in JAVA-Bytecode vorliegenden Bibliotheken "dynamisch" erst zur Laufzeit in Maschinencode kompiliert werden:

1. Dieser Aufwand entfällt.

Nein, denn die Funktion musste ja auch erst einmal in den JIT oder die JVM implementiert werden. Vorteil ist, dass man eben nur eine aktuelle JVM braucht um davon Gebrauch machen zu können, wohingegen ich bei C-Programmen mich selbst darum kümmern muss. Aber das ist bei direkt lauffähiger Software und Sprachen, die eine VM nutzen, ja generell der Fall.

1. Der Aufwand, alle denkbaren Befehlssätze zu berücksichtigen, fällt im JAVA-JIT-Compiler nur einmal an, und kann dann von allen Bibliotheken genutzt werden.

Ich kann auch meine Software entsprechend kompilieren, Gentoo bietet das meines Wissens nach an. Oder eben Software nutzen/schreiben, die das zur Laufzeit erkennt…

Dann gibt es in der JVM weitere Optimierungen, die bei C und vor allem C++ mit statischen Vererbungen systembedingt entfallen. Googelt mal "Java schneller als C".

Dir ist schon bewusst, dass "Java" und "C" in deinem Beispiel beliebig austauschbar sind, auch durch die Namen anderer Programmiersprachen?

Und wie schon gesagt, der Kernel ist da außen vor, und hat da keinen Einfluss drauf.

Natürlich hat der Kernel darauf Einfluss. Wenn ich meinem Kernel sage, er soll drei der vier Kerne in meiner CPU abschalten, dann macht er das. Und die Kerne können dann auch von Java nicht verwendet werden. Wenn ich das AES-NI-Modul blackliste kann auch Java nicht darauf zugreifen. Dann wars das mit dem Kryptobeschleuniger. Der Kernel kümmert sich um den Zugriff auf Ressourcen. Tatsächlich macht systemd als Initsystem von diesen Funktionen des Kernel sogar ausgiebig Gebrauch, siehe Cgroups. Könnte die JVM auch nur eine dieser Beschränkungen umgehen wäre das fatal (und zudem ein potentieller Exploit, da man damit Sicherheitsmechanismen umgehen könnte).

Nachtrag: Da fällt mir noch etwas ein: Als die erste Version des Raspberry Pi herausgekommen ist hatten die meisten Distributionen hierfür keine VFP-Unterstützung. Da half es auch nicht das Programm mit VFP-Unterstützung zu kompilieren, die Software lief erst als auch der Kernel entsprechend kompiliert wurde. War im Prinzip das gleiche Problem.

Developer92 schrieb:

Beim JAVA-JIT-Compiler sieht die Sache anders aus, da die in JAVA-Bytecode vorliegenden Bibliotheken "dynamisch" erst zur Laufzeit in Maschinencode kompiliert werden:

1. Dieser Aufwand entfällt.

Nein, denn die Funktion musste ja auch erst einmal in den JIT oder die JVM implementiert werden.

Für den Programmierer, der ein unter der jeweiligen Umgebung lauffähiges Programm schreibt, davon sprach ich, entfällt dieser Aufwand im Fall von JAVA schon.

Vorteil ist, dass man eben nur eine aktuelle JVM braucht um davon Gebrauch machen zu können,

Genau deshalb.

wohingegen ich bei C-Programmen mich selbst darum kümmern muss.

Genau den Aufwand meinte ich.

1. Der Aufwand, alle denkbaren Befehlssätze zu berücksichtigen, fällt im JAVA-JIT-Compiler nur einmal an, und kann dann von allen Bibliotheken genutzt werden.

Ich kann auch meine Software entsprechend kompilieren, Gentoo bietet das meines Wissens nach an. Oder eben Software nutzen/schreiben, die das zur Laufzeit erkennt…

Genau das meinte ich ja. Wenn Du eine Software (statisch kompilierte Bibliothek) nutzt, z.B. zur Sinusberechnung, die das kann, muss die dennoch bei jedem Aufruf für eine Sinusberechnung anhand der CPU-Flags entscheiden, welchen Code sie dann zu Berechnung des Sinus nehmen kann. Das kostet immer wieder ein bisschen Zeit (siehe meinen 4. Punkt, den kannst Du nicht einfach wegdiskutieren), und wenn das über eine Kernelfunktion geht, weil der Zugriff auf die Flags im User-Mode evtl. gesperrt ist, dauert's noch länger.

Natürlich hat der Kernel darauf Einfluss. Wenn ich meinem Kernel sage, er soll drei der vier Kerne in meiner CPU abschalten, dann macht er das.

Wie fein-granuliert im User-Mode Teilkomponenten der CPU gesperrt werden können, darüber kenne ich mich nicht so genau aus (1:0 für Dich hier), doch warum sollte ein Linux-32-Bit-Standard-Kernel das tun, und so auf effektive Befehle der vorhandenen CPU verzichten ... um den Benutzern den 64-Bit-Kernel aufzunötigen? Macht doch keinen Sinn.
Dennoch bleibt meine Aussage, dass da keine Kernel-Schnittstelle ins Spiel kommt, über die das Userprogramm die Funktionalität aufrufen muss, und die dem 32-Bit-Kernel theoretisch fehlen könnte. Wenn im Userprogram ein bestimmter Maschinencode vorkommt, der im Usermode gesperrt wurde, stürzt das Programm einfach "nur" ab, andernfalls wird er einfach nur ausgeführt ohne Zuhilfenahme einer Schnittstelle.

Wenn ich das AES-NI-Modul blackliste kann auch Java nicht darauf zugreifen. Dann wars das mit dem Kryptobeschleuniger.

Ich weiß nicht genau, was Du mit AES-NI-Modul meinst. Wenn das eine Software-Komponente im Kernel ist, die, wenn vorhanden, die AES_(Befehlssatzerweiterung) nutzt, kann der Kernel die natürlich sperren. Aber weder Java noch ein anderes Programm muss diese Schnittstelle nutzen, sondern kann mittels passendem Maschinenbefehl die AES_(Befehlssatzerweiterung) (=Kryptobeschleuniger) direkt nutzen.

Der Kernel kümmert sich um den Zugriff auf Ressourcen. Tatsächlich macht systemd als Initsystem von diesen Funktionen des Kernel sogar ausgiebig Gebrauch, siehe Cgroups.

Zunächst: Link geht hier nicht. Es geht da um Software-Ressourcen, denen Hardware zugeordnet ist, nicht um Hardware im engeren Sinn, außer bzgl. Adressraumgrenzen. (1:0 für mich)

Nachtrag: Da fällt mir noch etwas ein: Als die erste Version des Raspberry Pi herausgekommen ist hatten die meisten Distributionen hierfür keine VFP-Unterstützung.

Kann nicht finden, was VFP ist ... Neugier.

UlfZibis schrieb:

Genau deshalb. […] Genau den Aufwand meinte ich. […] Genau das meinte ich ja.

Oh, gut, dann sehen wir das ja doch gleich 😬

Developer92 schrieb:

Natürlich hat der Kernel darauf Einfluss. Wenn ich meinem Kernel sage, er soll drei der vier Kerne in meiner CPU abschalten, dann macht er das.

Wie fein-granuliert im User-Mode Teilkomponenten der CPU gesperrt werden können, darüber kenne ich mich nicht so genau aus (1:0 für Dich hier)

Sieg nach Punkten 😀

Spaß beiseite: Soweit ich weiß kann man Komponenten relativ schön einzeln deaktivieren, mittels entsprechender Kernelfunktionen müsste man das auch je nach Anwendung granular einstellen können. Aber davon habe ich ehrlichgesagt zu wenig Ahnung, das müsste jetzt jemand anderes genauer beantworten (würde mich aber auch interessieren).

doch warum sollte ein Linux-32-Bit-Standard-Kernel das tun, und so auf effektive Befehle der vorhandenen CPU verzichten ... um den Benutzern den 64-Bit-Kernel aufzunötigen? Macht doch keinen Sinn.

Theorie: Weil 64-Bit die Zukunft darstellt, und man die 32-Bit-Architektur dementsprechend verkümmern lässt. Einige Funktionen scheinen zudem 64-Bit-Addressierung zu benötigen, d.h. möglicherweise kann man diese unter 32-Bit physisch gar nicht ansprechen und daher auch nicht verwenden?!

Dennoch bleibt meine Aussage, dass da keine Kernel-Schnittstelle ins Spiel kommt, über die das Userprogramm die Funktionalität aufrufen muss, und die dem 32-Bit-Kernel theoretisch fehlen könnte. Wenn im Userprogram ein bestimmter Maschinencode vorkommt, der im Usermode gesperrt wurde, stürzt das Programm einfach "nur" ab, andernfalls wird er einfach nur ausgeführt ohne Zuhilfenahme einer Schnittstelle.

Aber das ist doch dann genau der Zugriff, den der Kernel sperren könnte, oder nicht?

Ich weiß nicht genau, was Du mit AES-NI-Modul meinst. Wenn das eine Software-Komponente im Kernel ist, die, wenn vorhanden, die AES_(Befehlssatzerweiterung) nutzt, kann der Kernel die natürlich sperren. Aber weder Java noch ein anderes Programm muss diese Schnittstelle nutzen, sondern kann mittels passendem Maschinenbefehl die AES_(Befehlssatzerweiterung) (=Kryptobeschleuniger) direkt nutzen.

Jetzt bin ich irritiert. Ich dachte genau das wäre nicht möglich?!

Es geht da um Software-Ressourcen, denen Hardware zugeordnet ist, nicht um Hardware im engeren Sinn, außer bzgl. Adressraumgrenzen.

Ah, jetzt weiß ich was du meinst. Klar, so ergibt das Sinn.

Nachtrag: Da fällt mir noch etwas ein: Als die erste Version des Raspberry Pi herausgekommen ist hatten die meisten Distributionen hierfür keine VFP-Unterstützung.

Kann nicht finden, was VFP ist ... Neugier.

VFP ist die FPU in ARM-Prozessoren (und frag mich bitte nicht, warum man das Ding nicht einfach FPU genannt hat … ich habe keine Ahnung).

Ich hatte damals das Problem, dass ich Programme, welche mit VFP-Support kompiliert waren, erst dann verwenden konnte, als auch der Kernel mit VFP-Support kompiliert wurde. Und deshalb denke ich auch, dass ich die AES-NI-Befahlssatzerweiterung im Userspace nur verwenden kann, wenn das auch der Kernel ansprechen kann. Jetzt bin ich leider etwas irritiert, wie ich oben schon geschrieben habe, denn auf der einen Seite würde es Sinn machen, wenn der Maschinencode meines Userspace-Programms einfach ausgeführt werden würde, auf der anderen Seite ging ja gerade das nicht, als ich genau dieses Problem mit der VFP auf dem Raspberry Pi hatte. Kann jetzt aber auch daran liegen, dass x86_64 und ARM zwei vollkommen unterschiedliche Architekturen sind. Hm…

Edit: Ich muss mit meiner Aussage zurückrudern. So wie es scheint kann man den Kryptobeschleuniger tatsächlich nutzen, auch wenn der Kernel nichts damit anfangen kann (wie du geschrieben hast). Maschinenbefehl muss dafür halt vorhanden sein, aber den gibt es ja in dem Falle.

Developer92 schrieb:

Benchmarks, speziell die Phoronix Test Suite soll sehr gut sein.

Ubuntu-32: https://openbenchmarking.org/result/1611201-KH-ULFZIBIS301
Ubuntu-64: https://openbenchmarking.org/result/1611200-KH-ULFZIBIS707

Huch, was ist das denn jetzt: "Ausführung von Programmen auf der CPU"

Versteht jemand, um welche Frage es bei dem Thema geht? Soll diskutiert werden ob Programme auf der CPU laufen, oder vielleicht doch woanders, vielleicht auf der Tastatur oder unter der CPU?

Hallo Moderator: Ich bitte darum, 8631333 und 8642633 wieder an den alten Thread zu binden, denn in den Benchmarks geht es um genau um die dort diskutierte Frage.

UlfZibis schrieb:

Huch, was ist das denn jetzt: "Ausführung von Programmen auf der CPU"

Versteht jemand, um welche Frage es bei dem Thema geht? Soll diskutiert werden ob Programme auf der CPU laufen, oder vielleicht doch woanders, vielleicht auf der Tastatur oder unter der CPU?

Oder auf dem Festplatten-Prozessor, wie der Equation-Virus es durch Neuprogrammieren der Festplatten-Firmware macht.

Hallo Moderator: Ich bitte darum, 8631333 und 8642633 wieder an den alten Thread zu binden, denn in den Benchmarks geht es um genau um die dort diskutierte Frage.

Hier im Forum wird streng getrennt – leider geht dabei dann manchmal auch die Diskussion verloren, wie nun geschehen.

Jedenfalls danke für Deine 32- versus 64-Phoronix-Vergleiche, die zusammen mit anderen nun in diesem Abtrennungs-Thema stehenden Artikeln zum ursprünglichen Thema „Wieviel Resourcen mehr braucht ein 64-Bit-System | Erfahrungswerte?“ gehören würden.

Der Geschwindigkeitsvorteil des 64-Bit-Testszenarios im Vergleich zum 32-Bit-Szenario ist deutlich geringer als ich gedacht hätte. Sehr interessant.

P.S. Moderierungs-Wünsche sollten per Meldeknopf mitgeteilt werden, damit die Moderatoren es sicher mitbekommen.

Reinarden schrieb:

Oder auf dem Festplatten-Prozessor, wie der Equation-Virus es durch Neuprogrammieren der Festplatten-Firmware macht.

😀

Der Geschwindigkeitsvorteil des 64-Bit-Testszenarios im Vergleich zum 32-Bit-Szenario ist deutlich geringer als ich gedacht hätte. Sehr interessant.

Ja, man sieht am Beispiel "Linux Kernel kompilieren", dass wenn speicherfressende Adresszeiger-lastige Aktivitäten ins Gewicht fallen, der 64-Bit-Vorteil verschwindet, bzw. sich z.B. im Fall von Firefox mit vielen Tabs sogar umkehrt.

P.S. Moderierungs-Wünsche sollten per Meldeknopf mitgeteilt werden, damit die Moderatoren es sicher mitbekommen.

Danke, habe ich gemacht.

Jetzt wollte ich dazu noch eine Ergänzung melden, zweimal melden geht aber nicht. Ich schreibe sie dann mal hier hin:

Das Nebenthema fing ungefähr schon hier an, dann überlagerten sich beide Themen eine Zeit lang. IMHO nicht einfach, das zu trennen.

UlfZibis schrieb:

Ja, man sieht am Beispiel "Linux Kernel kompilieren", dass wenn speicherfressende Adresszeiger-lastige Aktivitäten ins Gewicht fallen, der 64-Bit-Vorteil verschwindet, bzw. sich z.B. im Fall von Firefox mit vielen Tabs sogar umkehrt.

An sich völlig logisch, aber über solche Zusammenhänge denken wir im Benutzer-Alltag oft nicht nach. Im Gegenteil hat man eher im Hinterkopf, daß alles, was größer klingt (64 > 32), ja automatisch besser sein muß. Merken wir uns die Ergebnisse also.

Nun verstehe ich auch besser, warum die Raspberry-Pi-Stiftung für ihr Pi3 mit 1 GB RAM und 64-Bit ARM8-Prozessor weiterhin jenes Debian-basierte Raspbian mit 32-Bit-Applikationen ausliefert, welches auch auf einem 32-Bit ARM6- und ARM7-Prozessor des Pi1 und Pi2 läuft – lediglich ist beim Pi3 die Kerneldatei 64-Bit statt 32-Bit. (Übrigens Ulf, erstklassiges Oracle-Java8 auf dem ARM-Pi.)

Das Nebenthema fing ungefähr schon hier an, dann überlagerten sich beide Themen eine Zeit lang. IMHO nicht einfach, das zu trennen.

Unmöglich diesmal, es zu trennen. Daher: besser sein lassen. Ordnung ist sehr wichtig, aber sie muß immer einem Zweck dienen. Wie beim Badewasser und dem Säugling. ☺

Reinarden schrieb:

An sich völlig logisch, aber über solche Zusammenhänge denken wir im Benutzer-Alltag oft nicht nach. Im Gegenteil hat man eher im Hinterkopf, daß alles, was größer klingt (64 > 32), ja automatisch besser sein muß. Merken wir uns die Ergebnisse also.

Jau, das sieht man an den 10-MPixel Handy-Kameras, deren Kleinst-Objektive noch nicht mal 1-MPixel scharf belichten können, obwohl 1-MPixel Sensoren rauschärmer bzw. lichtempfindlicher wären, weniger CPU-Leistung verbräuchten und kompaktere JPEG's mit eher besserer Qualität erzeugen würden. Aber Vorsicht, hier sind wir beim 4. Nebenthema.

Das Nebenthema fing ungefähr schon hier an, dann überlagerten sich beide Themen eine Zeit lang. IMHO nicht einfach, das zu trennen.

Unmöglich diesmal, es zu trennen. Daher: besser sein lassen. Ordnung ist sehr wichtig, aber sie muß immer einem Zweck dienen. Wie beim Badewasser und dem Säugling. ☺

Ja, und genau genommen hatten wir 3 Themen: das ursprüngliche, die Nutzbarkeit der Leistungsfähigkeit von 64-Bit-CPUs unter 32-Bit-Kernel und wie Java das ausnutzt und dann schneller als C werden kann. Allen drei ging es aber darum, wie die vorhandenen Ressourcen auf 32/64-Bit-Ubuntu unter welchen Bedingungen am besten genutzt werden können.

Außerdem ging es bei den Nebenthemen weder um die Shell noch um's Programmieren, keine einzige Code-Zeile wurde hier besprochen. Es geht um Entscheidungskriterien, die vor einer Installation abgewogen werden müssen.

Hallo,

In jeder Programmiersprache ist man darauf angewiesen, fertige vorkompilierte Bibliotheken zu verwenden.

Falsch. In Python verwende ich haufenweise Module (=Bibliotheken), die alleine in Python geschrieben sind. Da ist nichts vor kompiliert und die Programme laufen auf jeder Plattform, für die es eine Python-Implementierung gibt.

Und Java verhält sich doch auch so, AFAIK?

Gruß, noisefloor

noisefloor schrieb:

In jeder Programmiersprache ist man darauf angewiesen, fertige vorkompilierte Bibliotheken zu verwenden.

Falsch. In Python verwende ich haufenweise Module (=Bibliotheken), die alleine in Python geschrieben sind. Da ist nichts vor kompiliert und die Programme laufen auf jeder Plattform, für die es eine Python-Implementierung gibt.

Zugegebenermaßen eine ungünstige Formulierung. Das kommt davon, wenn man versucht zu viele Sachverhalte in einen Satz zu packen. Es müsste besser einfach nur heißen: "fertige Bibliotheken". Im Fall von C bzw. Ubuntu-Paketen oder Funktionen aus dem Kernel, um die es ja vor allem ging, dürfte das mit dem vorkompiliert aber meistens der Fall sein. Auch in der Python-Implementierung sind die Funktionen der Standardbibliothek, die zeitkritisch sind, wie z.B. der Sinus, vorkompiliert und liegen nicht in Python-Code vor. Weitere Bibliotheken liegen dann wie Du richtig bemerkst im Source-Code vor, maschinenunabhängig.

Und Java verhält sich doch auch so, AFAIK?

In Java sieht es etwas anders aus, da wird ja im Grunde 2 mal kompiliert. Bibliotheken werden üblicherweise kompiliert verteilt, aber in dem immer noch maschinenunabhängigen sogenannten Byte-Code. So ist damit auch die Distribution von "Closed Source" möglich. Die JVM kann den Byte-Code dann wahlweise direkt interpretieren oder erst intern in für die jeweils vorliegende CPU optimierten Maschinencode kompilieren und dann ausführen.

Gruß Ulf