Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum werden Browser bei JS immer schneller?
=Floi=
2009-07-09, 02:32:54
Hallo
warum werden browser von version zu version bei JS immer schneller? ich verstehe das nicht so recht. es war doch schon vorher oberstes ziel eine sehr schnelle version zu bauen und auf einmal kann man nochmal 100%+X mehr geschwindigkeit rausholen? wie ist das möglich? warum nur bei JS und webdarstellung und nicht bei anderen sachen?
dieses phenomen verfolgt mich jetzt schon jahre und ich bin auf eif die antworten gespannt.
urpils
2009-07-09, 07:15:08
da liegt einzig an dem "Trend" spezielle Javascript-Engines in die Browser einzubauen.
Dabei wird der Code zur Laufzeit übersetzt, optimiert und dann mehr oder weniger nativ ausgeführt.
Man kann das vllt. mit ner JavaVM vergleichen, die ja auch zur Laufzeit erst den endgültigen Code generiert.
BlackBirdSR
2009-07-09, 07:43:33
Man kann sich hier z.B. den IE8 ansehen und Apple Safari4.
Der IE8 scheint vor der Ausfürhung den ganzen JS-Code extra zu konvertieren. Ich weiß nicht wie und was genau, aber am Ende wird jede Gleitkommaoperation wieder auf Integer zurückgeführt, dabei nutzt JS ja die die Darstellung der Werte Gleitkomma.
Der Safari macht das nicht, er setzt sogar auf eine optimierte SSE2 (packed, scalar) Umgebung. Nicht übermäßig, aber doch vorhanden. Das macht sicher nicht alles aus, ist aber ebenfalls einer der Boni. Wen wundert das auch, Safari muss auf MAC ja nur eine Platform bedienen, die komplett über SSE2/3 verfügt. Da kann man verschmerzen, dass die Werte für Safari4 auf einem AthlonXP ohne SSE2 stark abfallen.
Shink
2009-07-09, 09:01:42
dieses phenomen verfolgt mich jetzt schon jahre
Hmmm.... also richtig angefangen hat die Verfügbarkeit von JS-Compilern aber erst Ende 2008.
Diese übersetzen wie schon erwähnt die Scripts in Byte- oder Maschinencode und cachen diese übersetzten Versionen des Scripts. Deshalb kann dann bei jeder Verwendung auf die übersetzte, schnellere Version zugegriffen werden.
es war doch schon vorher oberstes ziel eine sehr schnelle version zu bauen
Nein, wie kommst du darauf? Früher ging es vor allem um Speicherverbrauch.
Man kann sich hier z.B. den IE8 ansehen und Apple Safari4.
Der IE8 scheint vor der Ausfürhung den ganzen JS-Code extra zu konvertieren. Ich weiß nicht wie und was genau, aber am Ende wird jede Gleitkommaoperation wieder auf Integer zurückgeführt, dabei nutzt JS ja die die Darstellung der Werte Gleitkomma.
Kann ich mir irgendwie kaum vorstellen. Als der erste IE mit JavaScript rauskam war Floating-Point schon immer schneller als Emulation über Integer und JavaScript spezifiziert IEEE754 als einzigen numerischen Datentyp.
Und selbst wenn müssten sie das spätestens im IE8 endlich geändert haben.
Der Safari macht das nicht, er setzt sogar auf eine optimierte SSE2 (packed, scalar) Umgebung. Nicht übermäßig, aber doch vorhanden. Das macht sicher nicht alles aus, ist aber ebenfalls einer der Boni. Wen wundert das auch, Safari muss auf MAC ja nur eine Platform bedienen, die komplett über SSE2/3 verfügt. Da kann man verschmerzen, dass die Werte für Safari4 auf einem AthlonXP ohne SSE2 stark abfallen.
Wie erklärst du dir dann, dass Safari 4 auch auf PPCs Javascript schneller verarbeitet?
Ganon
2009-07-10, 09:41:53
Wie erklärst du dir dann, dass Safari 4 auch auf PPCs Javascript schneller verarbeitet?
Weil der JS-JiTC auch für PPC vorhanden ist? ;)
e.v.o
2009-07-10, 10:57:55
Werden hier schon wieder Äpfel und Birnen verglichen?
Klar,.. beides Obst, aber trotzdem unterschiedliches "Flavors" ;)
...Safari muss auf MAC ja nur eine Platform bedienen, die komplett über SSE2/3 verfügt.
Mich hat nur diese pauschale Aussage gestört ;)
Ganon
2009-07-10, 11:31:46
Mich hat nur diese pauschale Aussage gestört ;)
Stimmt ab SnowLeopard doch. Und außerdem war seine Aussage wohl eher der Vergleich zwischen JS unter IE und JS unter Safari. Im x86-Bereich kann Apple unter OS X nunmal davon ausgehen eine SSE2/3 CPU zu haben, während man unter Windows davon ausgehen muss eine CPU ohne SSE2 zu haben.
The_Invisible
2009-07-11, 19:22:20
naja, früher brauchte man javascript ja auch nicht so sehr, da kam vielleicht ein alert(), prompt() oder confirm() und das wars.
heute wird damit ja wirklich schon jeder schei* gemacht der auch rechenintensiv ist. darum wird javascript jetzt auch mal optimiert.
so eine regexp suche durch eine liste mit tausenden einträgen ist zb halt auch nicht billig, vor allem wenn man moderne browser mit alten vergleicht.
mfg
BlackBirdSR
2009-07-15, 10:40:09
Nein, wie kommst du darauf? Früher ging es vor allem um Speicherverbrauch.
Kann ich mir irgendwie kaum vorstellen. Als der erste IE mit JavaScript rauskam war Floating-Point schon immer schneller als Emulation über Integer und JavaScript spezifiziert IEEE754 als einzigen numerischen Datentyp.
Und selbst wenn müssten sie das spätestens im IE8 endlich geändert haben.
Ich hab die Performancecounter ausgelesen. Der IE8 nutzt beim K8 keinerlei x87 oder SSE2-Code. Ich sehe mal nach, was er beim PentiumM ausspuckt.
Die Ergebnisse des Atom sprechen auch für sich, der hängt den K7 bei Safari ab, sieht beim IE8 jedoch kein Land mehr.
Update1:
Irgendwas macht der IE8 auf jedenfall anders.
K7 Sunspider
IE8: ~1-1.2 µOps / Takt
Safari: ~0.5 - 0.7 µOps / Takt
Vorteil Safari beinahe 300% bei weniger CPU-Auslastung. Details kann ich beim K7 leider nicht auslesen.
@PPC...
geht jetzt die Körnersuche los? War das nicht eindeutig, dass es hier um x86 geht?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.