Login


 
Newsletter
Werbung
Do, 7. Juli 2011, 15:00

Über Benchmarks

Technische Rahmenbedingungen

Nun sollte man sich auch die Relevanz der Ergebnisse betrachten. Ist die Framerate in Spielen etwas, worauf die Fenstermanager hin optimieren? Ist die Framerate in dem Zusammenhang überhaupt relevant? Linux ist nicht als Spielerplattform bekannt. Daher ist es fraglich, ob Entwickler Zeit auf die Optimierung dieser investieren sollten.

Zuerst sollte man wissen, dass OpenGL-Compositing einen erheblichen und zu erwartenden Overhead produziert. Die Entwickler sind sich dessen bewusst. Durch die »Umleitung« des Compositing-Vorgangs wird jede Anwendung zuerst in eine Off-Screen-Pixmap und anschließend vom Compositor auf den Bildschirm gezeichnet, wozu von den bereits in OpenGL gezeichneten Frames eine OpenGL-Textur generiert und dann durch den Scenegraph des Compositors geschickt wird.

Logischerweise kann jede Anwendung durch das Compositing nur noch die Framerate des Compositors erreichen, welcher in der Regel VSync ausführt. Also kann nur noch die Bildschirmfrequenz erreicht werden. Ohne Compositing kann eine Anwendung direkt in den Framebuffer zeichnen und so viele Frames zeichnen, wie sie will (auch wenn das nicht sinnvoll ist). Mit Compositing wird sie durch das Umleiten durch den Compositor gedrosselt. Anstatt einer Anwendung, die auf den Framebuffer zeichnet, sind nun drei Anwendungen involviert: das Spiel selbst, der Compositor und der X-Server.

Auch für Spiele ist es nicht sinnvoll, mehr Frames zu zeichnen, als die Bildschirmfrequenz ermöglicht. Mit dem als X-Nachfolger gehandelten Wayland Display Server scheint es sowieso nicht mehr möglich zu sein, mehr Frames zu zeichnen, als der Compositor auf den Bildschirm bringen kann. Das heißt also, dass alle getesteten Fenstermanager gleich gut skalieren, falls die Spiele mindestens die Anzahl an Frames wie der Bildschirm liefern. Es gilt nicht, dass mehr Frames zwangsläufig besser sind. Bei fast allen Tests erreichen alle Fenstermanager Werte über der Bildschirmfrequenz. Bei den Tests, bei denen dies nicht der Fall ist, scheinen die Grafikkarte oder die Treiber an ihre Grenzen zu kommen, da Full-HD-Bildschirme verwendet werden.

Die KWin-Entwickler vertreten, seitdem der Fenstermanager um OpenGL-Compositing erweitert wurde, die Position, dass man Compositing bei OpenGL-Spielen ausschalten soll und bieten dafür mit Alt + Shift + F12 standardmäßig ein Tastenkürzel an. In der kommenden Version 4.7 der KDE-Plasma-Workspaces gehen sie noch weiter und erlauben Anwendungen selbst, Compositing auszuschalten oder dem Nutzer dieses über Fensterregeln auf Anwendungsbasis bestimmen zu lassen.

Mit diesem Wissen dürfte es klar sein, dass zumindest die KWin-Entwickler die Ergebnisse eines Benchmarks, wie von Phoronix durchgeführt, nicht ernst nehmen können. Die Entwickler haben ganz bestimmt nicht diesen Anwendungsfall optimiert. Ja, sie sehen es nicht einmal als validen Anwendungsfall an. Was Phoronix getestet hat, liegt außerhalb dessen, was KWin überhaupt abdecken will. Um so überraschender ist, dass KWin als »Benchmarksieger« aus dem Test herausgeht. Phoronix ist sich der Einstellung der KWin-Entwickler bewusst und verweist auch im Artikel auf die Änderungen in der nächsten Version.

Systematische Fehler

Somit muss man sich fragen, wie es zu den Ergebnissen kommen konnte. Diese Frage ist schwer zu beantworten, da erneut wichtige Informationen zum Wiederholen der Benchmarks fehlen. Um die Ergebnisse zu interpretieren, was Phoronix nicht macht, muss man daher leider Vermutungen anstellen. Mit dem Wissen als KWin-Maintainer dürfte eine der Wahrheit nahe kommende Analyse möglich sein: In den Standardeinstellungen verwendet KWin eine Option, um Vollbindanwendungen nicht umzuleiten. Die Fenster werden somit fast so gezeichnet wie ohne Compositing, ein gewisser Overhead bleibt jedoch erhalten. Diese Option scheint bei allen Phoronix-Tests aktiviert zu sein. Bei Compiz muss diese Option jedoch manuell über CCSM aktiviert werden. Dies alleine erklärt schon, warum KWin »besser« abschneidet als Compiz. Jedoch wäre nun interessant zu wissen, wie sich die Zahlen ändern, wenn man die Option in Compiz ein- und in KWin ausschaltet. Phoronix liefert diese Antwort jedoch nicht.

Man kann also davon ausgehen, dass Phoronix einen systematischen Fehler begangen hat und im Endeffekt Äpfel mit Birnen vergleicht. Dass der Nicht-Composited-Modus von KWin besser abschneidet als der Composited-Modus von Compiz, ist nun wirklich nicht überraschend. Dies hätte schon alleine dadurch auffallen müssen, dass KWin sogar besser abschneidet als GNOME2 mit Metacity – einem Fenstermanager ohne OpenGL-Compositing. Dies entspricht nicht Erwartung, dass ein OpenGL-Compositor einen Leistungseinbruch für jede hochfrequent zeichnende Anwendung mitbringt.

Bleibt zuletzt das »schlechte« Abschneiden von Mutter bei diesem Benchmark zu betrachten. Nach allem, was soweit erläutert wurde, kann man davon ausgehen, dass die Zahlen auch für Mutter schlicht und ergreifend nicht interpretierbar sind. Von Messfehler bis korrektes Ergebnis ist alles denkbar. Klar dürfte sein, dass Mutter die Vollbild-Nicht-Umleitung noch nicht unterstützt (KWin in KDE 4.0 unterstützte diese auch noch nicht) und VSync aktiviert hat. Dies ist eine logische Erklärung für das insgesamt deutlich schlechtere Abschneiden von Mutter. Es ist auch darauf hinzuweisen, dass in jedem Test Mutter ein Ergebnis erzielt hat, welches einer Bildschirmfrequenz ähnelt oder sogar deutlich darüber liegt. Mutter ist in diesem Punkt also genauso gut oder schlecht wie alle anderen getesteten Fenstermanager.

Zuletzt sollte man sich fragen: Ist das überhaupt relevant? Selbst wenn Mutter die FPS der Spiele reduziert, ist das von Bedeutung? Braucht man Spiele, die mehr als die Bildschirmfrequenz an Frames zeichnen? Heutzutage kann man Grafikkarten zur Physikberechnung verwenden und somit die CPU entlasten. Eine Reduzierung der FPS kann also sogar zu einer Verbesserung der Spielerfahrung führen. Es kann also durchaus »Weniger ist Mehr« gelten. Unter dieser Annahme wäre somit KWin der Verlierer und Mutter der Sieger des Benchmarks.

Fazit

Benchmarks, wie sie regelmäßig auf Phoronix veröffentlicht werden, sind ohne genauere Betrachtung nicht aussagekräftig und zum großen Teil schlicht falsch. Sie folgen keiner wissenschaftlichen Methodik und Phoronix ist sich dessen wohl sogar bewusst, da keine Interpretation der Ergebnisse vorgestellt wird. Selbst die Zahlen zu interpretieren, kann leicht zu falschen Ergebnissen führen. So ist die Annahme, dass mehr gerenderte Frames einer besseren Leistung entsprechen, im Allgemein nicht gültig. Mit sehr geringem Aufwand lassen sich die Testbedingungen so verändern, dass komplett gegensätzliche Ergebnisse entstehen. Im Endeffekt sind die Benchmarks nur eine Aneinanderreihung nicht aussagekräftiger Zahlen.

Autoreninformation

Martin Gräßlin (Webseite) wird als KWin-Maintainer immer wieder mit fehlerhaften Benchmarks konfrontiert und muss Nutzern oft erklären, warum Benchmarks nicht hilfreich sind.

Dieser Artikel ist in freiesMagazin 07/2011 erschienen. Veröffentlichung mit freundlicher Genehmigung.

  • Das Werk darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, Abwandlungen und Bearbeitungen des Werkes müssen unter den gleichen Bedingungen weitergegeben werden. Der Name des Autors/Rechteinhabers muss in der von ihm festgelegten Weise genannt werden.

    - Weitere Informationen
Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung