Windows 7

Blog von Microsoft Deutschland

Internet Explorer 9 Platform Preview 7 mit neuem Geschwindigkeitsrekord!

Internet Explorer 9 Platform Preview 7 mit neuem Geschwindigkeitsrekord!

  • Comments 8
  • Likes

Nur drei Wochen nach der Veröffentlichung von Internet Explorer 9 Platform Preview 6 (IE9 PP6) auf der PDC legt Microsoft heute mit der Platform Preview 7 (PP7) nach. Wir veröffentlichen neue Platform Preview-Versionen immer dann, wenn wir größere Schritte in der Weiterentwicklung von Internet Explorer 9 erreicht haben. Mit PP7 haben wir jetzt weitere, signifikante Geschwindigkeitsverbesserungen insbesondere im Hinblick auf die Performance unserer JavaScript-Engine “Chakra” implementiert.

IE9 Platform Preview 7 herunterladen

Microsoft legt bei der Weiterentwicklung des Internet Explorers schon seit langem Wert auf die Geschwindigkeit beim Darstellen echter Webseiten. Die JavaScript-Engine ist zwar nur eines von vielen Subsystemen eines Browsers, die in Summe das Geschwindigkeitserlebnis des Internetnutzers beeinflussen. Die Messung der JavaScript-Geschwindigkeit mit synthetischen Benchmarks ist jedoch sehr populär und wird von vielen fälschlicherweise als alleiniger Gradmesser für die Beurteilung der Gesamtgeschwindigkeit eines Browsers benutzt.

Die Geschwindigkeit wird jedoch von vielen weiteren Dingen beeinflusst, die jenseits der einzelnen Browsersubsysteme liegen. Wie gut schützt ein Browser Internetnutzer vor langsamen Add-Ins? Vor schlecht entwickelten Webseiten, die zum Crash neigen? Wie sehr integriert ein Browser Webanwendungen zukünftig in das Betriebssystem? Muss man erst den Browsers starten und zu der gewünschten Webseite navigieren oder kann man Webseiten direkt an die Startleiste anzuheften und mit einem Klick auf die Webseite wechseln? Die Geschwindigkeitsvorteile, die man durch die Nutzung des Grafikprozessors zur Hardwarebeschleunigung sowie mehrerer Prozessorkerne moderner Multi-Core-CPUs erzielen kann, sind immens.

Geschwindigkeit für echte Webseiten

Echte Webseiten nutzen JavaScript, um zum Beispiel Benutzereingaben zu verarbeiten, Zeichenketten zu manipulieren oder Objekte auf dem Bildschirm zu steuern und zu bewegen. Wir konzentrieren uns daher bei der Weiterentwicklung unabhängig von synthetischen Benchmarks besonders auf die am häufigsten verwendeten Funktionen von echten Webseiten. Im Rahmen der Internet Explorer 9 Platform Preview-Veröffentlichungen haben wir deshalb eine Test Drive-Seite unter www.ietestdrive.com bereitgestellt. Diese Test Drive-Seite umfasst Webseiten und Anwendungen, die insbesondere Funktionen, die in echten Webseiten oft genutzt werden, in einem realistischen Szenario darstellt.

Diese Seiten zeigen besonders deutlich die Unterschiede zwischen aktuellen Browsern wie zum Beispiel in der letzten Beta 7 von FireFox 4 oder einer aktuellen Version von Google Chrome. Man sieht dabei die Unterschiede im Zusammenspiel aller Subsysteme eines Browsers. Welche Geschwindigkeit am Ende des Tages auf realistischen Webseiten zu erwarten ist, kann man darüber viel besser beurteilen als als das alleinige Messen der Geschwindigkeit einzelner Subsysteme mit Microbenchmarks es erlaubt.

Wir haben mit der Veröffentlichung von IE9 PP7 neue Beispiele hinzugefügt:

  • In Shakespeare’s Tag Cloud kann man die Geschwindigkeitsvorteile von kompiliertem JavaScript und ECMAScript5 bei scriptintensiven Operationen sehen. IE9 kann viel schneller eine sehr große Menge an Text zu einer Tag Cloud verarbeiten.
  • ECMAScript5 kombiniert mit HTML5 Canvas ermöglicht ein HTML5 Sudoku Lösungsprogramm, mit dem IE9 PP7 derartige Rätsel viel schneller lösen kann als andere Browser.
  • Mit Galaxy kombinieren wir die schnelle Ausführung von JavaScript mit Hilfe der hardwarebeschleunigten Grafikausgabe zu einer interaktiven 3D Experience. Die Bildwiederholrate ist dabei in IE9 PP7 viel höher als bei allen anderen existierenden Browsern.
Geschwindigkeitsrekord mit IE9 im Sunspider Benchmark

Trotzdem werden Webbrowser am häufigsten durch einen Microbenchmarks bewertet: Webkit SunSpider. Wir haben seit der Vorstellung unsere neue JavaScript-Engnie “Chakra” daher jedes Mal auch die Steigerung der Geschwindigkeit veröffentlicht, die wir bei diesem vielzitierten Benchmark errreichen. Gegenüber der ersten veröffentlichten Version von “Chakra” beschleunigten wir IE9 um >300%. Wir holten nicht nur Firefox 3 und 4 ein, sondern sind heute mit IE9 PP7 die #1 in Sachen JavaScript Performance im Webkit SunSpider-Test.

SunSpider_Benchmark image

Mittlerweile liegen die Unterschiede zwischen den einzelnen Browsern in diesem Microbenchmark nur noch im Bereich von Microsekunden. Das ist viel kürzer, als ein einzelner Wimpernschlag. Man muss die Tests schon viele, viele Male wiederholen, um überhaupt noch Unterschiede messen zu können. IE9 erreicht die deutlichen Performanceverbesserungen insbesondere durch einen optimierenden JavaScript Compiler, welcher JavaScript in native Maschinensprache umsetzt und dabei optimiert. Optimierungen können für viele Code-Muster Performancegewinne bis zum 100fachen der ursprünglichen Geschwindigkeit ermöglichen. Derartige Compilertechniken werden bisher zum Beispiel von C++ Entwicklern für native Windows-Anwendungen benutzt. Mit IE9 PP7 können zukünftig Webentwickler auch optimiert kompiliertes JavaScript nutzen.

Nun wird vorgeschlagen, diesen Benchmark als obsolet anzusehen und auf die Entwicklung neuerer Microbenchmarks zu setzen. Gerade als aktueller “Gewinner” in diesem Benchmark möchten wir die Gelegenheit nutzen, um an dieser Stelle wieder auf unsere Position hinzuweisen, dass synthetische Benchmarks der Subsysteme kein geeigneter Weg sind, generelle Aussagen über die Geschwindigkeit eines Browsers bei echten Webseiten zu machen. Sie helfen Entwicklern bei der Beurteilung der einzelnen Komponenten - sie sagen aber nichts aus über das Verhalten eines Browsers bei der täglichen Nutzung. Wenn man sich zu sehr an Microbenchmarks orientiert, kann das möglicherweise auch zu einer ungesunden Form des Wettbewerbs führen, bei dem es nur noch darum geht, ein Produkt auf bessere Benchmarkergebnisse hin zu optimieren.

Diesen Weg halten wir für falsch. Das Beurteilen eines Browsers anhand der Messungen eines Subsystems allein ist zu ungenau und kann daher kontraproduktiv sein. Es entspricht auch nicht dem Verhalten von echten Webseiten und bietet daher keinen Mehrwert.

IE9 verbindet jetzt die schnellste JavaScript-Performance mit branchenführenden Innovation rund um die Hardwarebeschleunigung im Browser. Die Vorteile von IE9 liegen in seinem einzigartigem Ansatz:

  • Optimieren auf die Hardware vs. Abstrahieren der Hardware durch Softwarelayer
    • Nutzen aller Vorteile, die moderne Hardware unter Windows bietet.
    • Massiver Geschwindigkeitsvorteil im Vergleich zu anderen Browsern, die jetzt anfangen, die Idee von Hardwarebeschleunigung auch zu adaptieren  (Firefox & Chrome).
  • Fokussieren auf echte Szenarien, nicht auf Microbenchmarks
    • Verstehen der Muster echter Webseiten.
    • Sicherstellen der besten Zusammenarbeit aller Subsysteme eines Browsers.
Geschwindigkeit + Webstandards + Dynamik = Neue Möglichkeiten für Entwickler

Diese Fortschritte bei der Geschwindigkeit eines Browsers nützt Entwicklern und am Ende des Tages Endanwendern gleichermaßen. Entwickler können zukünftig durch die Unterstützung von den neuen, sich gerade etablierenden Webstandards mit IE9 darauf setzen, Code nur noch einmal schreiben zu müssen, der dann auf allen aktuellen Browsern läuft. IE9 ist unser am schnellsten vom Markt angenommene Webbrowser mit mittlerweile über 13 Millionen Downloads in nur 2 Monaten.

Daher der Aufruf an alle Webentwickler: Wer noch nicht mit IE9 Beta an Bord gegangen ist, sollte jetzt bei der neuen Platform Preview den Zug nicht verpassen!

  1. Holt das Beste aus der Unterstützung von Internet Explorer 9 mit HTML5, CSS3, SVG, DOM, ES5 und mehr heraus.
  2. Schaut Euch das Entwicklerhandbuch für IE9 an! Vermeidet Browserweichen, die auf Versionsnummern basieren und testet auf die benötigten Funktionen!
  3. Testet Eure Seiten in IE9 Standards Mode für die beste Performance und Interoperabilität und nutzt mit nur wenigen Zeilen Code die Vorteile für Eure Webseiten in Windows 7 mit der Integration in die Taskbar und die Nutzung von Sprunglisten!

Auf www.internet-explorer9.de stellt Microsoft eine Produktübersicht zur Verfügung. Weiterführende Informationen rund um den Internet Explorer 9 finden Administratoren auf Microsoft TechNet und Entwickler auf MSDN.

Daniel Melanchthon
Senior Technology Evangelist
Microsoft Developer & Platform Evangelism Group (D&PE)

Comments
  • Glueckwunsch, dabei habt ihr nur ein ganz klein bischen geschummelt dieses mal:

    digitizor.com/.../internet-explorer-9-caught-cheating-in-sunspider-benchmark

    Wie waer es mal mit ehrlicher Arbeit und ehrlichen Ergebnissen? Aber wahrscheinlich haben die IE9-Entwickler in der Schule bei ihren Klassenkameraden auch immer abgeschrieben.

    Wenn ihr sowas wie ein klein bischen Anstand habt, dann nimmt ihr diese Messreihe sofort zurueck und entschuldigt euch bei euren Kunden. Ansonsten macht ihr euch nur noch mehr zum Obst und irgendwann nimmt keiner mehr dieses Unternehmen ernst.

    Adrian

  • Hallo Adrian,

    der Artikel, den Du zitierst, ist gelinde gesagt "sensationsheischend". Lies mal die Diskussion auf deren Seite über den Artikel selbst. Mittlerweile wurde auch schon der Titel abgeschwächt in "Did Internet Explorer 9 Cheat In The SunSpider Bechmark?"

    Die Erklärung ist recht simple: IE9 erreicht die deutlichen Performanceverbesserungen insbesondere durch einen optimierenden JavaScript Compiler, welcher JavaScript in native Maschinensprache umsetzt und dabei optimiert.

    Optimierungen können für viele Code-Muster Performancegewinne bis zum 100fachen der ursprünglichen Geschwindigkeit ermöglichen. Vor allem auf realen Webseiten.

    Derartige Compilertechniken werden bisher zum Beispiel von C++ Entwicklern für native Windows-Anwendungen benutzt. Mit IE9 PP7 können zukünftig Webentwickler auch optimiert kompiliertes JavaScript nutzen.

    Falls es Dich interessiet, solltest Du Dir auch mal den originalen Post durchlesen, den Rob Sayre Anfang September auf seinem Mozilla Blog geschrieben hat und aus dem der von Dir zitierte Artikel seine Argumente für die wilde Spekulation bezieht.

    Das klingt dort natürlich nicht so sexy, wie das, was daraus bei digitizor.com gemacht wurde, aber schau selbst: blog.mozilla.com/.../js-benchmarks-closing-in sowie danach folgend blog.mozilla.com/.../reporting-a-bug-on-a-fragile-analysis und die Diskussion auf news.ycombinator.com/item ist auch sehr lesenswert.

    VG, Daniel

  • Hallo Daniel,

    vielen Dank fuer deine Antwort, obwohl ich ehrlich gesagt etwas aufbrausend war, nun gut, war nicht so gemeint ;).

    Also, mir geht es darum, dass hier gross angekuendigt wurde, dass die JS-Engine des IE9.0 sensationell schnell sein soll und jene von Chrome und Co nun endlich schlaegt. Soweit die Theorie. Die Praxis zeigt aber, dass dieser angebliche Vorsprung voellig irrelevant oder gar manipuliert ist.

    Was hier naemlich von dem Mozilla-Entwickler vollzogen wurde, ist eine ganz einfache Methodik der Wissenschaft. Wenn man ueberpruefen moechte, ob eine Aussage oder wie in diesem Fall, eine Engine, eben universell gueltig bzw. einsetzbar ist, dann nimmt man kleine Modifikationen vor. Im Falle der JS-Engine vom neuen Internet Explorer scheint das fatale Auswirkungen zu haben, da ja der Benchmark offensichtlich voellig in der Performance einbricht, waehrend die Konkurenz weiterhin auf fast gleichem Niveau bleibt.

    Und gerade das ist doch in der Praxis relevant. Dass der Browser und seine einzelnen Komponenten unter allen Bedingungen immer schoen performant sind. Und nicht nur, wenn ich um 12 Uhr mittags, Oslo-Zeit bei Microsoft auf der Website rumsurfe, davon habe ich naemlich in der Praxis hinterher nichts.

    Da wirst du mir ja sicherlich zustimmen, oder?

    Und die Tatsache, dass der IE nun JavaScript vor der Ausfuehrung kompiliert ist ja nun ein alter Hut. Google hat das ja mit Chrome als allererstes gemacht, weshalb die beim Erscheinen des Browsers auch einfach mal um ein bis zwei Groessenordnungen vor der Konkurrenz lagen, da alle anderen bis dato den Code normal interpretiert haben.

    Und ja, selbst wenn die JS-Engine einen JIT-Compiler verwendet, ist das noch lange keine Entschuldigung dafuer, dass die Engine bei derart leichten Variationen so eklatant in der Performance einbricht.

    Dies laesst nunmal objektiv gesehen nur zwei Schluesse zu: Entweder wurde bei der Implementation geschlampt oder man hat die JS-Engine bewusst auf den Sunspider-Benchmark optimiert. Wobei letzteres wirklich unschoen waere, aber in der Vergangenheit durchaus vorgekommen ist. Es gibt genuegend Beispiele, in denen nVidia und ATI ihre Treiber so programmiert haben, dass sie bestimmte Benchmarks erkennen und in diesem Falle automatisch eingebaute Optimierungen verwenden. Wenn man sowas naemlich fuer einen einzelnen, speziellen Anwedungsfalls, naemlich einem Benchmark, handoptimiert, ist es keine grosse Kunst, die Konkurrenz weit hinter sich zu lassen.

    Ich finde nicht, dass deine Ausfuehrungen die Anschuldigungen entkraeften. Eine "simple" und vor allem plausible Erklaerung waere, dass die JS-Engine hier noch einen kleinen Bug hat, den man vor dem Release noch ausraeumen wird. Dass es aber grundsaetzlich am JIT-Compiler liegen soll, halte ich fuer ausgemachten Unsinn. Denn Opera, Google und Mozilla zeigen ja, dass deren JIT-Compiler nicht so leicht zu Fall zu bringen sind und ihre Performance auf gleich gutem Niveau halten.

    Viele Gruesse aus Oslo,

    Adrian

  • Hallo Daniel,

    nochmal ein kurzer Nachtrag. Also ich habe mir mal die dazu gehoerenden diffs angesehen. Und sowohl bei dem zusaetzlichen "true"-statement [1] als auch bei dem redundanten "return" [2] sollte die JS-Engine unter keinen Umstaenden so dermassen in der Performance einbrechen.

    Du kannst das gerne mal mit einem C/C++-Compiler deiner Wahl nachstellen. Schreibe eine Funktion, die "void", also nichts zurueckliefert und fuege am Ende einmal ein "return" ein und beim anderen mal nicht. Unter normalen Umstaenden werden 1 Million sequentielle Aufrufe dieser Funktion exakt die gleiche CPU-Zeit benoetigen, ansonsten stimmt etwas mit dem Compiler nicht.

    Ein "return" steht naemlich auch bei einer Funktion ohne Rueckgabewert schon implizit an dieser Stelle. Sobald der Compiler daraus nativen Code erzeugt, steht an dieser Stelle im Assembler-Code ein "ret", ob da nun im JavaScript/C/C++/C#-Code ein "return" steht oder nicht. Ansonsten wuesste die CPU ja am Ende der Funktion nicht wo sie mit der Ausfuehrung fortsetzen sollte, wenn nicht an der Stelle, wo sie zuletzt in die Funktion gesprungen ist.

    Es gibt daher wirklich nur zwei Erklaerungen. Entweder hat der JIT-Compiler/die JS-Engine einen ziemlich fiesen Bug oder hier wird bewusst Quellcode erkannt und dann handoptimierter, eingebauter Code ausgefuehrt statt den tatsaechlichen Code zu just-in-time zu kompilieren und auszufuehren.

    Adrian

    [1] people.mozilla.com/.../diff1.html

    [2] people.mozilla.com/.../diff2.html

  • Hallo Adrian,

    ja, IE9.0 ist sensationell schnell und schlägt mittlerweile Chrome und Co nicht nur in der Theorie, sondern auch in der Praxis. Ich bin da ganz bei Dir, dass ein synthetischer Benchmark wie SunSpider nicht geeignet ist, die Geschwindigkeit des Browsers bei realen Webseiten zu messen. Der Vorsprung, den wir uns erarbeitet  haben, ist gerade bei realen Webseiten besonders zu spüren. Schau Dir die JavaScript-Performance-Beispiele auf dem IE TestDrive an, dann kannst Du die Unterschiede zwischen den einzelnen Browsern sehr gut sehen.

    das IE-Team hat zu dem "Vorwurf" auch schon Stellung bezogen:

    "The IE9 JavaScript engine includes many different changes to improve the performance of real-world Web sites and applications. You can see this in action by visiting www.ietestdrive.com and trying the samples there with IE9 and other browsers. The behavior of the IE9 JavaScript engine is not a “special case optimization” for any benchmark and not a bug.

    Developers often write dead code without knowing it and can rely on compilers to optimize the code. Most modern compilers today run an extensive set of dead code elimination optimizations. So, why does this affect the math-cordic benchmark in the Webkit SunSpider suite?

    The benchmark runs an expensive loop, and then does nothing with the results; the benchmark is written exactly in a way that triggers this general optimization.
    Of course, the benchmark could be rewritten to avoid triggering this optimization, which would bring our performance on this specific benchmark in line with other browsers.

    The interest in this issue is a great example of why these microbenchmarks fail to represent the real world web. Webkit Sunspider uses an expensive JavaScript loop to approximate sine and cosine. Real world sites would actually use the much faster and CPU-optimized functions already available in JavaScript engines."

    ZDNet.de hat in einem Artikel den von Dir zitierten Vorwurf ebenfalls untersucht und schreibt in dem Artikel IE9 Platform Preview 7 soll bei Benchmarks schummeln dazu:

    „Ein Blick in den Sourcecode zeigt jedoch, dass Microsoft nichts vorzuwerfen ist. Es handelt sich um einen Bug im Benchmark-Code, der dazu führt, dass der Internet Explorer anders als Chrome und Firefox den Hauptteil dieses Tests gar nicht ausführt.Das muss er auch nicht, denn der Optimizer stellt fest, dass das Ergebnis der Berechnung für den weiteren Programmablauf nicht benötigt wird und kompiliert den Code daher konsequenterweise erst gar nicht. Das Entfernen von sogenanntem "Dead Code" ist eine Kernaufgabe des Optimizers.“

    Veränderungen an dem Benchmark, so dass der Optimized Compiler den Code nicht mehr so gut optimieren kann, haben auch nicht die von Dir beschworenen fatalen Auswirkungen. IE9 bricht doch nicht bei dem Benchmark völlig in der Performance ein:

    IE9 ist selbst dann, wenn man den "cordic"-Test so verändern würde, dass wir dort ähnlich viel Zeit brauchen wie der Rest, nur 20 bis 25 Millisekunden langsamer, was nicht ausreicht, um den IE9 von Platz eins zu verdr��ngen.

    Wenn Du hier einen Fehler erkennst, dann liegt er beim Webkit-Team als Entwickler des Benchmarks. Rob Sayre hat in seinem Blogpost übrigens auch Fehler in Google V8 und Dromaeo ("Dromaeo test suite is full of little tiny loops and unrealistic workloads") gefunden.

    Interessant finde ich, dass die Information, aus der digitizor.com jetzt einen solchen Artikel macht, schon mehr als zwei Monate alt ist und das "Problem" dort anders darstellt. Die sensationsheischende Überschrift hat digitizor.com ja gestern schon zurücknehmen müssen ("We have changed the title of the story as some commentators have rightly pointed out the previous one was too biased").

    Viele Grüße,
    Daniel

  • Hallo,

    ...die Dreipunkteliste am Ende des Artikels stößt mich darauf, dass ich bei aller Begeisterung rund um den neuen IE noch nirgendwo eine Ankündigung bzgl. MathML gelesen habe. Ist das Thema zu unpopulär, oder werden da tatsächlich keine Änderungen zu erwarten sein?

    MfG,

    solarch

  • Hallo Daniel,

    ich stimme deiner Argumentation leider immer noch nicht zu. Der Sinn und Zweck eines Benchmarks ist es nunmal, eine Messung unter definierten Messbedingungen durchzufuehren, damit man die Ergebnisse verschiedener Probanden vergleichen kann. Es liegt daher in der Natur der Sache, dass Benchmarks synthetisch sind.

    Wenn man z.B. vergleichen moechte, wie schnell verschiedene Laeufer sind, so laesst man sie auf einem 400m Rundkurs laufen und stoppt die Zeit. Wenn der Laeufer "Internet Explorer" nun aber meint, dass diese 400m Rundkurs ja voellig sinnlos sind und sich daher entscheidet, die Strecke nicht zu laufen, so hat er zwar die "schnellste" Rundenzeit erlaufen, jedoch die Messung nicht unter vergleichbaren Bedingungen durchgefuehrt. Waere er naemlich die 400m mit "Google Chrome", "Opera 10" und "Mozilla Firefox" mitgelaufen, so haette sich sehr schnell gezeigt, dass er eben nicht der schnellste Laeufer ist sondern sehr wohl den anderen hinterherlaeuft.

    Und wenn Microsoft schon die Geschwindigkeitsvorteile des Browsers anhand dieses Benchmarks bewirbt, dann muss der Browser den Benchmark auch genauso wie die anderen Browser absolvieren. Zur Not muss man diese Art von Optimierung von Code (Weglassen von Code, der keine Ergebnisse liefert) eben ausschalten, da die Ergebnisse sonst NICHT VERGLEICHBAR sind. Auf jeden Fall _muss_ so ein entscheidenes Detail in den Ausfuehrungen erwaehnt sein, alles andere ist unserioes und unwissenschaftlich.

    Solche Messungen und Ueberpruefungen mit kleiner Variation der Testbedingungen sind, wie bereits erwaehnt, eine absolut legitime und vor allem uebliche Methodik in der Wissenschaft. Ich bin selbst Physiker und ich kann dir versichern, dass mein Professor mir meine Messungen um die Ohren hauen wuerde, wenn ich ein derart entscheidenes Detail in meiner Auswertung einfach weglassen wuerde. Von der Akzeptanz solch einer wissenschaftlichen Untersuchung in "Science" und Co mal ganz zu schweigen.

    Und im uebrigen bin ich der Meinung, dass diese Optimierung ueber die Auslassung von "Dead Code" im IE9.0 zumindest noch sehr unausgereift ist. Wie ich bereits erwaehnt habe, aendern die beiden vom Mozilla-Entwickler durchgefuehrten Modifikationen absolut gar nichts an der Semantik des Codes, dieses ueberfluessige "true" optimiert jeder normale Compiler weg, vermutlich sogar Microsofts "cl.exe" und das redundante "return" muss der Interpreter/Compiler an dieser Stelle sowieso ausfuehren, ob es nun dort steht oder nicht. Der Programmablauf _muss_ an dieser Stelle zurueckspringen, da dort die Funktion zuende ist. Der Programmcode macht also vorher und nachher (vor und nach der Modifikation) _exakt_ das gleiche. Wenn der eingebaute Optimierer in JS-Engine des IE9.0 ueber solch minimale Aenderungen bereits stolpert, ist er in der Praxis absolut _unbrauchbar_.

    Gerne verweise ich dazu auch den aktuellen Artikel auf heise Online" [1]. Dass du in deinen Ausfuehrungen auf "Ziff Davis", sozusagen die BILD-Zeitung des amerikanischen Computerjournalismus, verweist, hilft deiner Argumentation wirklich nicht weiter.

    Ich moechte den neuen Internet Explorer wirklich nicht schlechtreden, ich bin sogar der Meinung, dass Microsoft seine Hausaufgaben diesmal ordentlich gemacht hat und ich mir sogar vorstellen koennte, diesen auch einzusetzen, wenn ich denn einen Windows-Rechner haette.

    Aber es ist nunmal nicht korrekt, dass hier mit Geschwindigkeitsvorteilen geworben wird, die in Wirklichkeit nicht oder nur unter ganz bestimmten Randbedigungen gegeben sind.

    Adrian

    [1] www.heise.de/.../Browser-Debatte-Hat-Microsoft-geschummelt-1138758.html

  • Hallo Adrian,

    ich stimme Dir zu, dass der Sinn und Zweck eines Benchmarks ist, eine Messung unter definierten Messbedingungen durchzuführen, damit man die Ergebnisse vergleichen kann. Das bedeutet aber nicht, dass Benchmarks immer synthetisch sind. Du vergißt dabei, was einen synthetischen Benchmark von einem Anwendungsbenchmark unterscheidet.

    Ich habe oben schon geschrieben, dass es nicht sinnvoll ist, SunSpider durch andere, synthetische Benchmarks wie Kraken (Mozilla), V8 (Google) oder ähnliche zu ersetzen, nur weil man mit SunSpider Unterschiede nur noch im Millisekundenbereich messen kann. Heise macht in dem von Dir verlinkten Artikel aber genau diesen Fehler.

    Die Aufgaben eines Webbrowsers sind heutzutage sehr umfangreich, wenn er eine moderne Webseite korrekt und schnell darstellen soll. Dein 400m-Lauf-Beispiel als Vergleich paßt da nicht. Wenn Du 400m-Läufer testen möchtest und wissen willst, wie schnell sie sind, dann kannst Du sie 400m laufen lassen und die Zeit messen. Soweit ist es einfach. Du berücksichtigst dabei aber zum Beispiel nicht die Tagesform oder die äußeren Bedingungen wie Wind, etc. Du kannst mit diesem Test auch keine Aussage für eine gemischte Gruppe von Läufern treffen, die Spezialisten für unterschiedliche Längen (100m, 400m, 10km), Strecken (Halle, Bahn, Gelände) oder Arten (Gehen vs. Laufen) enthält, indem Du sie alle die gleichen 400m laufen läßt. Siehst Du Deinen Denkfehler?

    "Benchmarks are designed to mimic a particular type of workload on a component or system. Synthetic benchmarks do this by specially created programs that impose the workload on the component. Application benchmarks run real-world programs on the system. Whilst application benchmarks usually give a much better measure of real-world performance on a given system, synthetic benchmarks are useful for testing individual components, like a hard disk or networking device."
    en.wikipedia.org/.../Benchmark_(computing)

    Wenn man also einen synthetischen Benchmark erstellt, um eine Ausage über die Real-World-Performance zu machen, muss man ihn sehr intelligent und umsichtig designen. Das ist bei keinem der derzeit populären Micro-Benchmarks (SunSpider, Dromaeo, Kraken, V8, Peacekeeper, etc.) der Fall. Der von Dir kritisierte "cordic"-Test ist schlicht ein Fehler im Benchmark und nicht im IE9. Der berühmte Dhrystone-Test hatte schon vor Jahren gezeigt, was passiert, wenn man Optimierungen von Compilern nicht beachtet.

    Denn zur Real-World-Performance gehören auch die Programmoptimierung von Compilern dazu. Compileroptimierungen sind anerkannte Techniken bei der Erstellung von Software. Daran ist nichts unseriös oder unwissenschaftlich. Neben dem deutschen Artikel, den ich im Artikel mit verlinkt hatte, gibt es auch einen umfangreicheren englischen, der einzelne Optimierungstechniken erklärt. "Dead code"-Optimierung ist nur eine davon.

    Gerade Dir als Physiker müßten doch Konzepte wie Kürzen oder Umformen aus der Mathematik bekannt sein. Wenn Du als Aufgabe bekommen würdest, 1+2+3+4+5+6+7+8+9-9-8-7-6-5-4-3-2 zu berechnen, wie lange bräuchtest Du dafür ohne Taschenrechner? Oder für 200/8800? Wenn Du es in wenigen Sekunden schaffst, weil  Du erkennst, dass (2+3+4+5+6+7+8+9) und (9-8-7-6-5-4-3-2) sich gegenseitig aufheben oder 200/8800 = 2/88 = 1/44 ist, darf ich dann laut rufen: "Adrian-caught-cheating"?

    Die Verwendung von Programmoptimierungen in unserer JavaScript-Engine hat niemand unterschlagen, wie Du in Deinem Kommentar vorwirfst. Ich hatte dem Thema extra einen eigenen Absatz gewidmet. Du suggerierst weiterhin in Deinen Kommentaren, dass IE9 in der Performance "einbrechen" würde gegenüber der Konkurrenz. Das ist nicht richtig. Vergessen wir eins nicht: IE9 PP7 wäre im SunSpider-Benchmark genauso Erster, wenn der "cordic"-Test nicht der "Dead code"-Optimierung zum Opfer gefallen wäre.

    Microsoft vertritt schon seit langem den Ansatz, dass echte Webseiten besser geeignet sind, Aussagen über die Geschwindigkeit zu geben. Nicht umsonst hatten wir zum Beispiel schon zum Launch von IE8 das berühmte Speed-Video veröffentlicht. Genau diesen Punkt habe ich in dem Artikel auch in den Vordergrund gestellt.

    Bisher wurde dieses Argument oft gekontert mit der Aussage, wir würden ja nur so argumentieren, weil wir beim SunSpider langsamer wären. Jetzt nutzen wir die Gelegenheit, auch aus der Position des Führenden auf unseren Ansatz hinzuweisen.

    Schau Dir einfach mal www.ietestdrive.com an.  Die Beispiele sind sorgfältig erstellt und man kann damit das Zusammenspiel verschiedenster Subsysteme eines Browers in einem echten Webumfeld testen. Oder nimm webvizbench.com - eine echte HTML5-Seite, die zusätzlich auch Geschwindikeitsdaten ausgibt. Die Geschwindigkeitsvorteile, für die wir beim IE9 werben, erzielen wir auch bei echten Webseiten und nicht nur, wie Du unterstellst, unter ganz bestimmten Randbedigungen in obskuren Benchmarks.

    Viele Grüße,
    Daniel

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment