Notiz Mozilla Firefox: 64-Bit-Version wird Standard für kompatibles Windows
- Ersteller Mahir
- Erstellt am
- Zur Notiz: Mozilla Firefox: 64-Bit-Version wird Standard für kompatibles Windows
Der-Orden-Xar
Commander
- Registriert
- Okt. 2007
- Beiträge
- 2.823
Die Lösung kein Java mehr nutzen 
Im ernst: Mit Ausnahme von Flash sind derartige (dh NPAPI) PlugIns nicht mehr Lauffähig, die einzige Möglichkeit, die du noch bis Anfang nächsten Jahres hast, ist, die 52ESR-version zu nutzen - und dir zu überlegen, ob und wenn ja wie du ohne Java auskommen kannst.
Im ernst: Mit Ausnahme von Flash sind derartige (dh NPAPI) PlugIns nicht mehr Lauffähig, die einzige Möglichkeit, die du noch bis Anfang nächsten Jahres hast, ist, die 52ESR-version zu nutzen - und dir zu überlegen, ob und wenn ja wie du ohne Java auskommen kannst.
Hauro schrieb:
Hauro, kannst du diesen Fehler mit der Nightly 57 bestätigen? https://webcompat.com/issues/9002
Sorry für OT
Hauro
Fleet Admiral
- Registriert
- Apr. 2010
- Beiträge
- 13.632
Für mich nicht reproduzierbar mit Stylo (layout.css.servo.enabled): true (enabled by default)
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 - Windows 10 64-Bit Home
und
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 - Windows 7 64-Bit Enterprise
Habe noch einen Test mit einem neuen Profil gemacht. Auch hier tritt das Phänomen nicht auf. Spontan mal mit einem neuen Profil gegen prüfen, um Add-on(s) auszuschließen.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 - Windows 10 64-Bit Home
und
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 - Windows 7 64-Bit Enterprise
Habe noch einen Test mit einem neuen Profil gemacht. Auch hier tritt das Phänomen nicht auf. Spontan mal mit einem neuen Profil gegen prüfen, um Add-on(s) auszuschließen.
Zuletzt bearbeitet:
(Ergänzung)
A
Alex Große
Gast
Ich finde es schade das heute noch nicht alle Programme und Systeme 64-Bit sind das sollte grundsätzlich Standard werden schon alleine wegen der Geschwindigkeit und denn anderen vorteilen einer 64-Bit Anwendung/System. Wann kommt das 265-Bit System?
R
RalphS
Gast
Kannst Du jetzt schon haben: Einfach vier CPU-Befehle als "einen" definieren und fertig ist der Laden. So funktioniert amd64 schließlich auch und das nicht schlecht.
Nachteil: Performanceeinbruch, weil ein Befehl nun den Platz von vieren einnimmt, ergo vorher 100%, hinterher 25% Performance. Plus, signifikant höherer Ressourcenverbrauch, weil ein Datenwort nun den vierfachen Platz benötigt (benötigt auf ein 64bit-Wort). Mit anderen Worten, die RAM-Effizienz sinkt auf denselben Stand wie die CPU-Leistung, nämlich 25% (bezogen auf 64bit-Adressierung).
Und nein. Es entsteht, entgegen aller Beteuerungen des Gegenteils, für x86-basierte Architekturen KEIN allgemeiner Vorteil aus einer breiteren Architektur. Ob mein Datenwort jetzt - bildlich gesprochen - aus 32 Nullen besteht und danach dann ein 32bit-Wort kommt oder ob es 224 Nullen waren und DANN das 32bit-Wort kam oder ob vorher überhaupt keine Null kam und NUR das 32bit-Wort dasteht, macht genau 0% Unterschied (geringfügige Performanceverluste wegen Verwaltungsmehraufwand ausgenommen). Dasselbe gilt, wenn es stattdessen ein 64bit breites Datenwort war... oder gar nur ein 16bit breites.
Gilt natürlich nicht, wenn man genauer rechnen möchte, oder mit größeren Werten rechnen möchte. Dann macht es natürlich einen Unterschied, ob man seine großen Zahlen irgendwie in kleinere Werte aufteilt und dann mit denen weiterrechnet oder ob man das gleich in einem Rutsch abhandeln kann. Analog: ob -überspitzt- meine Fließkommazahlen auf 0.5 genau sein können oder ob es doch bis 0.25 gehen darf. Natürlich wäre das nur ein Unterschied von 2^-1 zu 2^-2 und nicht von 2^-32 zu 2^-64, geschweige denn 2^-256: Ja, natürlich gibt es Anwendungsgebiete, wo man möglichst 100% genau sein muß; im Privatbetrieb ist das aber nicht der Fall. Und selbst so kann man sich behelfen, wenn man der CPU erklärt, es wird mit ganzzahligen Werten gearbeitet und dann Brüche als Strukturen definiert, komplett mit Ganzzahloperationen, wie man das als Mensch mit gemeinen Brüchen auch machen würde.
64bit Browser sind nur dann sinnvoll, wenn die Entwickler nicht in der Lage sind, einen Browser zu bauen, der mit 4GB RAM pro Thread auskommt. Was in Anbetracht der Tatsache, daß moderne Browser üblicherweise jeden Tab in eine einzelne Instanz auslagern, nicht so das Problem darstellen... sollte.
Nachteil: Performanceeinbruch, weil ein Befehl nun den Platz von vieren einnimmt, ergo vorher 100%, hinterher 25% Performance. Plus, signifikant höherer Ressourcenverbrauch, weil ein Datenwort nun den vierfachen Platz benötigt (benötigt auf ein 64bit-Wort). Mit anderen Worten, die RAM-Effizienz sinkt auf denselben Stand wie die CPU-Leistung, nämlich 25% (bezogen auf 64bit-Adressierung).
Und nein. Es entsteht, entgegen aller Beteuerungen des Gegenteils, für x86-basierte Architekturen KEIN allgemeiner Vorteil aus einer breiteren Architektur. Ob mein Datenwort jetzt - bildlich gesprochen - aus 32 Nullen besteht und danach dann ein 32bit-Wort kommt oder ob es 224 Nullen waren und DANN das 32bit-Wort kam oder ob vorher überhaupt keine Null kam und NUR das 32bit-Wort dasteht, macht genau 0% Unterschied (geringfügige Performanceverluste wegen Verwaltungsmehraufwand ausgenommen). Dasselbe gilt, wenn es stattdessen ein 64bit breites Datenwort war... oder gar nur ein 16bit breites.
Gilt natürlich nicht, wenn man genauer rechnen möchte, oder mit größeren Werten rechnen möchte. Dann macht es natürlich einen Unterschied, ob man seine großen Zahlen irgendwie in kleinere Werte aufteilt und dann mit denen weiterrechnet oder ob man das gleich in einem Rutsch abhandeln kann. Analog: ob -überspitzt- meine Fließkommazahlen auf 0.5 genau sein können oder ob es doch bis 0.25 gehen darf. Natürlich wäre das nur ein Unterschied von 2^-1 zu 2^-2 und nicht von 2^-32 zu 2^-64, geschweige denn 2^-256: Ja, natürlich gibt es Anwendungsgebiete, wo man möglichst 100% genau sein muß; im Privatbetrieb ist das aber nicht der Fall. Und selbst so kann man sich behelfen, wenn man der CPU erklärt, es wird mit ganzzahligen Werten gearbeitet und dann Brüche als Strukturen definiert, komplett mit Ganzzahloperationen, wie man das als Mensch mit gemeinen Brüchen auch machen würde.
64bit Browser sind nur dann sinnvoll, wenn die Entwickler nicht in der Lage sind, einen Browser zu bauen, der mit 4GB RAM pro Thread auskommt. Was in Anbetracht der Tatsache, daß moderne Browser üblicherweise jeden Tab in eine einzelne Instanz auslagern, nicht so das Problem darstellen... sollte.
Lurtz
Lt. Commander
- Registriert
- Sep. 2005
- Beiträge
- 1.257
Eylisia schrieb:Hauro, kannst du diesen Fehler mit der Nightly 57 bestätigen? https://webcompat.com/issues/9002
Sorry für OT
Habe ich auch immer wieder mal. Scheint mit uBO tendentiell schlimmer zu werden. Scheint irgendein Glitch im Rendering zu sein, das gab es auch schon vor Servo.
- Registriert
- Mai 2011
- Beiträge
- 2.004
RalphS schrieb:
Das ist Abfall den du da aufgeschrieben hast.
Zum einen weil der Browser eben auch mit 64bit großen Daten rechnet, wofür er in 32-Bit-Fassung dann doppelt so lange braucht. Heutzutage sollte man bei Gleitkommazahlen immer mit 64 Bit rechnen, außer man hat das ausgiebig getestet und die 64-Bit-Gleitkommaoperationen stellen ein Performanceproblem dar.
Weiter hat man mit der amd64-Architektur nicht nur doppelt so breite sondern auch doppelt so viele Register, also in Summe 4x so viel Daten auf die man latenzfrei zugreifen kann, was der Performance ebenfalls zu Gute kommt. Dazu kommen noch Sicherheitstechniken wie NX-Bit und diverse andere Schutzmechanismen von Windows, die aber nur bei Prozessen im 64-Bit-Mode greifen.
32-Bit-Software sollte man also möglichst meiden, da außer dem geringfügig kleineren Speichervebrauch (Pointer sind nur halb so groß) kein Vorteil besteht, einem aber eine ganze Reihe an Verbesserungen entgehen.
Außerdem gilt die Grenze von 4GB RAM nicht je Thread sondern je Prozess.
Zuletzt bearbeitet:
@Marco01_809
Das ließt sich alles in der Theorie schön. In der Praxis verpufft es vollkommen. Ich nehme aber auch einfach an die meisten Programme in 32 Bit reizen auch den PC einfach nicht aus. Um da viel zu merken.
Ok sicher hat 32 Bit keinen vorteil. Außer Kompatibilität. Wenn ich bei mir in den Taskmanager schaue läuft noch einiges an tasks in 32 Bit.
Das ließt sich alles in der Theorie schön. In der Praxis verpufft es vollkommen. Ich nehme aber auch einfach an die meisten Programme in 32 Bit reizen auch den PC einfach nicht aus. Um da viel zu merken.
Ok sicher hat 32 Bit keinen vorteil. Außer Kompatibilität. Wenn ich bei mir in den Taskmanager schaue läuft noch einiges an tasks in 32 Bit.
R
RalphS
Gast
Ja, natürlich muß eine Applikation, die nur Ganzkommazahlen bis 10 rechnet, eine 64bit-Applikation sein. Dasselbe für diejenigen Applikationen, die Fließkomma auf .25 genau berechnen sollen, oder wollen, oder müssen.
Und die 4G gelten für isolierte Einheiten. Ist mein Thread also isoliert, kann er 4G ansprechen. Ist er nicht isoliert, weil ich warum-auch-immer von außerhalb auf seinen Speicherpool zugreifen will, dann muß er sich seinen Adressraum logischerweise mit anderen teilen.
Aber ist auch egal. Memorymanagement ist eh nur für Idioten. Gibt ja 64bit und seit Threadripper hat jeder 2TB RAM verbaut. Kein Grund, beim Programmieren nachdenken zu müssen.
Und die 4G gelten für isolierte Einheiten. Ist mein Thread also isoliert, kann er 4G ansprechen. Ist er nicht isoliert, weil ich warum-auch-immer von außerhalb auf seinen Speicherpool zugreifen will, dann muß er sich seinen Adressraum logischerweise mit anderen teilen.
Aber ist auch egal. Memorymanagement ist eh nur für Idioten. Gibt ja 64bit und seit Threadripper hat jeder 2TB RAM verbaut. Kein Grund, beim Programmieren nachdenken zu müssen.
- Registriert
- Mai 2011
- Beiträge
- 2.004
Ja warum sollten sie das denn nicht sein? Ich bin sicher keiner der sagt "Neuer ist immer Besser", ganz im Gegenteil. Aber nenn doch mal einen vernünftigen Grund hier gegen den Trend zu gehen.RalphS schrieb:
Es ist bescheuert eine Anwendung in 32-Bit zu erzeugen nur weil sie nicht viele Berechnungen mit 64bit Breite anstellt. Schließlich hat 64-Bit handfeste Vorteile und 32-Bit nicht.
32-Bit kann man für alte Systeme ja zusätzlich noch erzeugen aber praktisch gibt es keine neuen x86-CPUs mehr die keine 64-Bit können und alte die noch im Betrieb sind sterben langsam aus. Das Problem ist dann eher das irgendein Depp 32-Bit Windows aufs System draufgetan hat und die 64-Bit-Anwendung dann nicht geht obwohls die Hardware kann.
Es wäre sehr gescheit langsam mal auf 100% 64-Bit zuzusteuern. Denn selbst sobald wir das erreichen müssen wir noch viele Jahre warten bis wir dann den ganzen 32-Bit-Kompatibilitätskrempel rauswerfen können.
Auf Linux merkt man das sehr deutlich: Das Grundsystem ist zu 100% in 64-Bit kompiliert. 99% aller Anwendungen auch. Nur Anwendungen wo die Sourcen nicht vorliegen werden dann gerne mal ausschließlich in 32-Bit verteilt.
Zum Beispiel Steam. Installiert man das braucht man nochmal Kopien von haufenweise Libraries in 32-Bit, die man in 64-Bit schon vorliegen hat. Was bei Steam natürlich daran liegt das von Spielen die Sourcen ebenfalls nicht vorliegen und da auch viele nicht als 64-Bit kompiliert sind. Einzige Lösung ist also 32-Bit-Neuware möglichst schnell zu verbannen damit der Anteil 32-Bit-Software abnimmt.
Ist doch auch quatsch was hier steht. 64-Bit-Anwendungen verbrauchen nicht Unmengen mehr an RAM als ihr 32-Bit-Äquivalent und 4GB ist einfach keine zukunftssichere Grenze. Viele Programme kann und will man vielleicht nicht auf mehrere Prozesse auftrennen. (Beispiel: Spiele) Und das Auftrennen kostet meist noch mehr RAM wegen Overhead jedes Prozesses.RalphS schrieb:
