Ende von 64-Bit-Firefox für Windows

  • Artikelbild
    grafik: mozilla

Sei nicht ausreichend getestet und verursache Probleme - Bisher nur als Nightly verfügbar

Wer bislang unter Windows eine 64-Bit-Version von Firefox verwenden wollte, musste sich schon in eher experimentelle Bereiche begeben. Lediglich als "Nightly" war diese Browservariante erhältlich, und damit in jenen Builds, die ohne größere Tests täglich aktualisiert werden.

Kehrtwende

Wer bislang die Hoffnung hegte, dass die entsprechende Variante künftig auch für stabile Versionen des Browsers zur Verfügung gestellt wird, sieht sich nun eines besseren belehrt. Ganz im Gegenteil: Wie The Next Web berichtet, plant Mozilla nämlich die 64-Bit-Builds wieder vollständig einzustellen.

Probleme

In einem Google-Groups-Posting argumentiert Mozilla-Entwickler Benamin Smedberg, dass die Ausgabe mehr Probleme bringe, als sie löse. So seien zahlreiche Plugins nicht in 64-Bit-Versionen verfügbar. Bei jenen, wo dies doch der Fall sei, sei wiederum nicht gesichert, dass diese überhaupt lauffähig sind.

Zweitrangig

Der aktuelle Stand sei sowohl für die NutzerInnen als auch die EntwicklerInnen extrem frustrierend, da die 64-Bit-Version als "zweitrangig" wahrgenommen werde - was sie ehrlich gesprochen auch sei. Dazu komme noch, dass man viele Bugs erhalte, die in der 32-Bit-Ausgabe gar nicht enthalten sind, aber die Entwicklung aufhielten.

Vergleiche

Entsprechend soll die 64-Ausführung also gleich ganz gestrichen werden, Firefox-NutzerInnen unter Windows müssen künftig wieder auf die 32-Bit-Version der Software zurückgreifen - die aber natürlich auch unter einem 64-Bit-Windows problemlos läuft. Unter Mac OS X und Linux gibt es übrigens schon seit einiger Zeit sehr wohl vollkommen funktionstüchtige 64-Bit-Varianten. (red, derStandard.at, 23.11.12)

Share if you care
Posting 1 bis 25 von 70
1 2

Naja, solange Microsoft nicht das 64-bit notepad wieder einstellt...

Weiter unten war ich noch traurig ...

Aber es gibt eine Lösung, die mir sehr gut gefällt:
http://www.waterfoxproject.org/index.php
Man nehme:
Die FF- Sourcen,
einen guten Compiler,
gut umrühren,
und fertig ist der superschnelle Browser *freu*
Bislang hat alles super funktioniert, inklusive Flash. ^^

So weit ich weiß, beschränken sich die Entwickler nur das Kompilieren des Sourcode. Wenn mal Fehler auftauchen wie vor paar tagen, dann müssten die diese selber beseitigen.

wozu auch

solange der adressraum von 32bit ausreicht sind die apps so effizienter, weil jeder pointer (und so mancher integer) nur den halben speicherplatz braucht. viele apps werden daher bewusst nur als 32bit kompiliert, obwohl auch 64bit gehen würden.

unter 64-bit linux ist das anders, da ist der 32-bit app support erstens nicht immer per default installiert und zweitens ein bisserl fragil. das ist den meisten wurscht, weil eh nur wenige apps 32 bit brauchen (games und so).

weiß eigentlich wer, warum linux 32bit so stiefmütterlich behandelt? effizient ist das ja nicht grad, mit gewalt jeden schmarrn auf 64bit aufzublasen.

Die 64 Bit Pointer fallen nur dann ins Gewicht, wenn man große Pointer Arrays verwendet, was in der Praxis allerdings sehr selten ist. In den meisten Fällen werden Pointer nur als temporäre Variablen genutzt und in den Registern gehalten. Außer C/C++ haben die meisten Programmiersprachen keine expliziten sondern nur implizite Pointer, was deren Verwendung weiter reduziert.

die fallen eher nur dann nicht ins gewicht, wenn man mit besonders vielen großen arrays und strings arbeitet. die meisten datenstrukturen haben einen sehr großen pointer-anteil.
was man sich so installiert ist eh mit ganz wenigen ausnahmen entweder in c/c++ geschrieben, oder bei windows in .net. bei .net ist das aber nicht anders. (ich wüsste auch nicht in welcher sprache sich das grundlegend anders verhalten sollte, aber es gibt am desktop eh sonst nix relevantes. java wäre übrigens noch schlimmer, wenn es das am desktop noch gäbe, da es im gegensatz zu c/c++ und .net keine user defined value types kennt)
implizite/explizite pointer und referenzen sind nur semantsich unterschiedlich, real unterscheiden sie sich gar nicht.

zusatzfrage, da die diskussion ins theoretische abgleitet:

Gibt es Benchmarks von FF 32 vs 64 Bit inkl. speicherverbrauch?

32 vs 64 Bit

Ganz klarer Fall: 32 Bit Programme benötigen weniger Speicher.
Aber das mit den Pointern ist so eine Sache: eine 64 Bit Architektur liest natürlich 64 Bit Pointer mit der selben Geschwindigkeit ein wie eine 32 Bit Architektur ihre 32 Bit Pointer - nur dass mit 64 Bit wesentlich mehr Speicher adressiert werden kann.
Genial ist bei 64 Bit, dass in einem Rechenzyklus doppelt soviele Daten verarbeitet werden können (vom erweiterten Befehlssatz einmal abgesehen).
Auch hat sich die Datenrate durch den breiten Bus (theoretisch) verdoppelt.
Meine persönliche Erfahrung ist eine beeindruckende Performancesteigerung.
32 Bit Programme müssen von einer 64 Bit Architektur emuliert werden- was aber unter Windows so genial klappt, dass man es kaum merkt.

Emulieren muß der 64 Bit-Prozessor bei 32 Bit Programmen nichts, er schaltet einfach in den 32 Bit Modus um, das geht ohne wesentlichen Zeitverlust. Die 64 Bit Betriebssysteme haben auch eine volle 32 Bit Schnittstelle, um 32 Bit Programme optimal bedienen zu können. Das kostet natürlich auch noch einmal eine Menge Speicher zusätzlich zu den 64 Bit Zeigern. Bei Linux x64 nimmt der Compiler defaultmäßig 64 Bit Integer, was die Portabilität meistens erleichtert, aber zusätzlich Speicher verschwendet. Der Windows Compiler nimmt defaultmäßig 32 Bit Integer im 64 Bit Modus, was Speicher spart, aber bei unsauberer Programmierung zu Schwierigkeiten führt. Hier vermute ich auch die Schwierigkeiten beim Firefox.

Welcher Windows Compiler?

GCC?
Visual C++?
Intel C++?

Es gibt eigentlich nicht "den" Windows Compiler.

warum braucht dann Linux so wenig Speicher (Ubuntu 12.10 etwa 300MB)?

Also 300 MB würde ich für IT-Latein halten. Schon alleine der gefrässige Firefox braucht selbst im 32 Bit Modus schon mehr.

aber welche app nutzt schon die volle datenbreite?. multimedia-zeug vermutlich, aber sonst?

64 bit heisst aber auch mehr register, erweiterte addressmodi und zumindest SSE2. Das Argument mit den doppelt breiten pointern die alles viel langsamer machen und doppelten speicher benötigen als 32bit halte ich für ausgemachten humbug.

Hat sich in Tests oft bewahrheitet

microbenchmarks die die performance beim pointerchasing messen sind praxisfern und daher irrelevant.

Ich spreche von real-World tests

citation needed!

da mein posting keinen enzyklopädischen charakter hat darf ich schon von eigenen erfahrungen [relevance] berichten, obwohl ich natürlich lieber statistisch relevantere aussagen zitieren könnte. aber ich hab hier ja auch eine frage gestellt, vielleicht hat jemand was belegbares.

Haben Sie Ihre Performancedefizite auch tatsächlich per ordentlichem Profiling auf die Unterschiede 32/64-bit zurückführen können?

nein, wozu? wenn ich nur einen parameter (bitness) ändere, und speicherverbrauch und laufzeit (cpu-time) ändern sich messbar, was fehlt mir dann?

und wie? profiler sagen mir, wieviel zeit in jeder funktion verbracht wird, aber nicht was das für einen zusammenhang mit der bitness hat.

Nur ändern Sie mit der Bitness in der Regel viele viele Parameter im Compiler, die man separat betrachten sollte - dann kommt man drauf welcher Faktor wirklich was verbraucht und möglicherweise lässt sich das ziemlich leicht vermeiden und ins Gegenteil umdrehen.

Man sollte beim Optimieren/Profilen jedenfalls niemals Mutmaßungen anstellen sondern wirklich messen.

sicher, man könnte noch an anderen compiler-optionen rumdrehen, vielleicht sind einfach die default-settings bei 32 bit besser als bei 64 bit. es weist aber nichts darauf hin. es hatte halt einfach schon einen sehr brauchbaren effekt, auf 32bit zu kompilieren, und wo wichtig war's dann doch nicht. aber ich weiß auch ohne profiling, dass meine laufzeit nicht in einer einzigen tight loop steckt, daher ist mir vollkommen unklar was profiling bringen soll.

Interessant wär natürlich auch - neben Profiling - eine Analyse des generierten Maschinen/Assembly-Codes was da schieflauft dass es bei 64-bit-Kompilation tatsächlich langsamer ist.

Aber klar, wenn's nicht so wichtig ist, ist's unnötiger Aufwand. Ich meinte das auch nur aus Interesse.

ich poste ja hier auch nur aus interesse, aber offenbar gibt es da keine klaren erfahrungswerte in die eine oder andere richtung. die erklärungen hier sind ja alle eher theoretischer natur, aber für die meisten programme bleibt wohl pointerlänge vs. registeranzahl. (die datenbreite nehm ich mal nicht soo ernst, weil nur wenige programme die auch nutzen)

Posting 1 bis 25 von 70
1 2

Die Kommentare von Usern und Userinnen geben nicht notwendigerweise die Meinung der Redaktion wieder. Die Redaktion behält sich vor, Kommentare, welche straf- oder zivilrechtliche Normen verletzen, den guten Sitten widersprechen oder sonst dem Ansehen des Mediums zuwiderlaufen (siehe ausführliche Forenregeln), zu entfernen. Der/Die Benutzer/in kann diesfalls keine Ansprüche stellen. Weiters behält sich die derStandard.at GmbH vor, Schadenersatzansprüche geltend zu machen und strafrechtlich relevante Tatbestände zur Anzeige zu bringen.