Microsoft geht keinen neuen und keinen anderen Weg. Das von euch beschriebene Konzept ist genau das gleiche, was sich in jeder anderen modernen JS-Engine auch findet: ein Interpreter der mit einem JIT gekoppelt ist. Die JVM arbeitet genauso. Also: Wo ist die Innovationshöhe? Und wo durchbricht die Microsoft mit diesem altbekannten Konzept die nächste Performance-Schallmauer?
Krilltickeler schrieb:
--------------------------------------------------------------------------------
> Microsoft geht keinen neuen und keinen anderen Weg. Das von euch
> beschriebene Konzept ist genau das gleiche, was sich in jeder anderen
> modernen JS-Engine auch findet: ein Interpreter der mit einem JIT gekoppelt
> ist. Die JVM arbeitet genauso. Also: Wo ist die Innovationshöhe? Und wo
> durchbricht die Microsoft mit diesem altbekannten Konzept die nächste
> Performance-Schallmauer?
Komplett falsch. Der Klassische ansatz einer VM ist: Quellcode in Bytecode übersetzen, Bytecode an 'Interpreter' verfüttertn und 'Interpreter' mit JIT optimieren. Der Modernere Ansatz ist: Quellcode in Maschinencode übersetzen und direkt ausführen und vom JIT optimieren lassen. In jedem Fall findet vorher ein Übersetzungsvorgang des Quellcodes statt der Zeit kostet.
Microsoft geht nun einen anderen Weg und lässt den Übersetzungsvorgang parallel ablaufen bevor es das Ergebnis nutzt. Das ist so tatsächlich neu, oder zumindest bei keinem der bekannten Lösungen in dem Bereich realisiert. Vielleicht hat Microsoft das ja von irgendeinem Exoten oder Akademiker geklau^h^h^h^h^kopiert.
Bloed nur, dass das Kompilieren eines durchschnittlichen JS-Anteils pro Webseite meist weit weniger als eine Sekunde dauert und daher unerheblich ist. Javascript-Frameworks z.B. bringen zwar viel mehr JS-Code mit, dessen Kompilieren schon mal mehrere Sekunden dauern kann. Dafuer passiert das jedoch nur 1x in einer ganzen Zeitspanne (je nach Serverkonfiguration bzgl. Cache-Verhalten i.d.R. mehreren Tagen). Auch der langsamste Browser der Welt wird durch so ein theoretisches Rumgetrickse die meisten nicht ansatzweise einholen koennen. Auch wenn der FF ohne Frage der zweitlangsamste Browser ist, sind die Benchmarkergebnisse jedoch sehr kritisch zu sehen - Benchmarks zeigen immer nur Statistiken unter ganz bestimmten Bedingungen; wenn M$ diese Bedingungen analysiert und den Browser genau hier etwas optimiert, zeigen die Ergebnisse ein falsches oder zumindest mit anderen Browsern nicht ohne weiteres vergleichbares Bild...
Für die meisten Seiten mag es stimmen, das der JS-Anteil so gering ist, dass sich ein Kompilieren nicht lohnen würde. Es gibt aber immer mehr Web-Anwendungen. Da wollen Leute online Bildbearbeitung machen oder MP3s schneiden. (Vom Sinn oder Unsinn mal abgesehen) Für Web-Anwendungen ist es schon wichtig wie performant Javascript ausgeführt wird. Hier macht auch ein jit-Compiling Sinn.
Deshalb ist die Idee doch gar nicht so abwegig zweigleisig zu fahren. Ich denke es geht hier nicht darum den ein oder anderen Benchmark auszutricksen.
Der Kommunist schrieb:
--------------------------------------------------------------------------------
> Bloed nur, dass das Kompilieren eines durchschnittlichen JS-Anteils pro
> Webseite meist weit weniger als eine Sekunde dauert und daher unerheblich
> ist. Javascript-Frameworks z.B. bringen zwar viel mehr JS-Code mit, dessen
> Kompilieren schon mal mehrere Sekunden dauern kann. Dafuer passiert das
> jedoch nur 1x in einer ganzen Zeitspanne (je nach Serverkonfiguration bzgl.
> Cache-Verhalten i.d.R. mehreren Tagen).
Du glaubst also der Kompilierte und optimierte Code wird die ganze Zeit im Cache oder sogar RAM gehalten?
> Auch der langsamste Browser der Welt wird durch so ein theoretisches Rumgetrickse die meisten nicht
> ansatzweise einholen koennen.
Es geht um die reaktionszeit im Betrieb, nicht die endleistung. Ein Merkmal von Ajax ist auch das nachladen von von Code-Teilen. Dort auf schnellere reaktion zu optimieren kann für den Anwender durchaus vorteile haben.
adama schrieb:
--------------------------------------------------------------------------------
> Für die meisten Seiten mag es stimmen, das der JS-Anteil so gering ist,
> dass sich ein Kompilieren nicht lohnen würde. Es gibt aber immer mehr
> Web-Anwendungen. Da wollen Leute online Bildbearbeitung machen oder MP3s
> schneiden. (Vom Sinn oder Unsinn mal abgesehen)
Wie ich schon schrieb: "Javascript-Frameworks z.B. bringen zwar viel mehr JS-Code mit, dessen Kompilieren schon mal mehrere Sekunden dauern kann. Dafuer passiert das jedoch nur 1x in einer ganzen Zeitspanne (je nach Serverkonfiguration bzgl. Cache-Verhalten i.d.R. mehreren Tagen)."
Der Kern von Webanwendungen wird 1x runtergeladen (js-Dateien), compiliert und bleibt dann in diesem Status, bis die Cache-Zeit abgelaufen ist, was je nach Konfiguration z.B. 14 Tage dauert. Und ganz ehrlich: Alle 14 Tage beim Aufruf meiner -->sinnfreien<-- Web(!)app(!) 3 Sekunden warten kann nicht das Problem sein. Und selbst wenn jemand laenger warten muss, ist er doch selbst schuld, wenn er Bild- und Audiobearbeitung nicht mit einem gescheiten Programm erledigt. BTW: Gerade bei der Audiobearbeitung sollte die Wartezeit fuer den Upload weit laenger als die Kompilierzeit fuer JS sein... Und von Daten-/Urheberschutz will ich gar nicht erst anfangen, wenn es um Online-Anwendungen geht...
> Deshalb ist die Idee doch gar nicht so abwegig zweigleisig zu fahren.
Gegen die Idee habe ich nichts, bezweifle allerdings den Praxisnutzen. Naja, wir werden es vllt. sehen.
> Ich denke es geht hier nicht darum den ein oder anderen Benchmark
> auszutricksen.
Oh doch - von dieser Firma kenne ich ueberhaupt nichts anderes!
K.A.I.N. schrieb:
--------------------------------------------------------------------------------
> Du glaubst also der Kompilierte und optimierte Code wird die ganze Zeit im
> Cache oder sogar RAM gehalten?
Sinnvoll waere das allemal - die einzige Alternative waere das Neukompilieren bei jedem Seitenaufruf, was es nicht sein kann und auch nicht ist.
> Es geht um die reaktionszeit im Betrieb, nicht die endleistung. Ein Merkmal
> von Ajax ist auch das nachladen von von Code-Teilen.
Das ist aber ein schlechter Stil. Erstens ist der meiste Code einer guten Webapp in JS-Dateien ausgelagert, die nur 1x vom Browser angefordert und dann gecached werden. Zweitens ist das bisschen Code, was mit einem durchschnittlichen Ajax-Response kommt so klein, dass der Compiler hierfuer vielleicht 50ms braucht, was der Anwender nicht wahrnimmt - die Reaktionszeiten der meisten Webserver sind laenger und dazu kommt noch die Ausfuehrungszeit auf Serverseite, die Datenuebertragungsdauer und ggf. die Geschwindigkeit des Browsers, die Seite zu veraendern. Gerade bei letzterem hat der IE massive Defizite - so viel zum Thema "Reaktionszeit".
> Dort auf schnellere
> reaktion zu optimieren kann für den Anwender durchaus vorteile haben.
Jup, solange er wirklich was davon mitbekommt und das nicht nur aus irgendwelchen Benchmarks entnimmt und damit rumprahlen muss.
Der Kommunist schrieb:
--------------------------------------------------------------------------------
> > Du glaubst also der Kompilierte und optimierte Code wird die ganze Zeit
> im
> > Cache oder sogar RAM gehalten?
> Sinnvoll waere das allemal - die einzige Alternative waere das
> Neukompilieren bei jedem Seitenaufruf, was es nicht sein kann und auch
> nicht ist.
Mit guter Hoffnung argumentieren ist kein guter Stil.
> > Es geht um die reaktionszeit im Betrieb, nicht die endleistung. Ein
> Merkmal
> > von Ajax ist auch das nachladen von von Code-Teilen.
> Das ist aber ein schlechter Stil.
Falsch.
Ob da Bytecode dazwischen ist oder nicht tut nichts zur Sache. Der Ansatz ist NICHT neu. Punkt.
Krilltickeler schrieb:
--------------------------------------------------------------------------------
> Ob da Bytecode dazwischen ist oder nicht tut nichts zur Sache. Der Ansatz
> ist NICHT neu. Punkt.
Die Welt ist auch nicht neu, alles schon von Sekunde eins an festgelegt.
Die Parallelen liegen so offensichtlich auf der Hand. Wer die nicht sieht, kann einfach nur Null Ahnung haben ...
Krilltickeler schrieb:
--------------------------------------------------------------------------------
> Die Parallelen liegen so offensichtlich auf der Hand. Wer die nicht sieht,
> kann einfach nur Null Ahnung haben ...
Immer wieder die "überzeugendste" Art der Argumentation: Wer nicht einsieht, dass ich recht habe, ist dumm.
Kommentare: 247 | letzter Beitrag 01:02 Uhr
Kommentare: 214 | letzter Beitrag 01:20 Uhr
Kommentare: 212 | letzter Beitrag 01:02 Uhr
Kommentare: 145 | letzter Beitrag 23.05. 14:08
Kommentare: 139 | letzter Beitrag 01:03 Uhr
E-Mail an news@golem.de
Das neue iPhone 5 soll nicht nur mit einem neuen, kleineren Dock-Anschluss ausgestattet werden, sondern auch ein größeres Display mit einer höheren Auflösung als sein Vorgänger erhalten.
Der wichtige Microsoft-Partner Dell glaubt nicht daran, dass Firmenkunden sofort auf Windows 8 setzen werden. Steve Ballmer hatte sich zuvor sehr enthusiastisch über die Erwartungen für das neue Betriebssystem geäußert.
Ein kleines Gerät soll die Interaktion mit dem Computer revolutionieren, verspricht das Startup Leap Motion: Leap erlaubt eine millimetergenaue Steuerung des Computers mit der Hand, ohne dass dieser dabei berührt wird.
Der weltgrößte PC-Hersteller HP will 8 Prozent seiner Beschäftigten loswerden. Besonders betroffen ist die Enterprise Services Group.
Googles Betriebssystem Android verletzt Oracles Patente nicht. So das eindeutige Urteil der Jury im Rechtsstreit zwischen Oracle und Google.
Das Aussehen der Facebook-Profile könnte sich demnächst ändern. Während die ganze Welt den Börsenstart des Unternehmens verfolgt, arbeitet Facebook heimlich, still und leise an einem Redesign der Chronik.