FPS nicht lineare Funktion, schonmal dran gedacht?

[Stephan Theisgen]

Hallo!

Häufig liest man doch Fragen wie: Meine FPS (frames per second) liegen bei 1000, kaum mache ich dies und das, fallen sie schon auf 500... So kann ich ja nie eine performante Engine programmieren!
Aus diesem Grund möchte ich Euch gerne den Text auf folgender Internetseite (über die ich zufällig gestolpert bin) ans Herz legen: http://www.mvps.org/directx/articles/fp ... e_time.htm (Auch der Rest der Seite ist für den ein oder anderen vielleicht einen Blick wert.)

Kurz gesagt sind FPS recht schlecht für die Performance-Messung, da die Funktion nicht linear ist. Auch wenn das wahrscheinlich fast alle (inkl. mir) wissen, so zeigen doch Fragen obiger Art und auch die Antworten darauf, dass es in der Praxis oder der "Hitze des Gefechts" wenig beachtet wird.

Ein Beispiel:
Was würdet Ihr als größeren Performance-Einbruch ansehen? Wir ändern etwas an der Render-Funktion und die FPS gehen von 1000 auf 500 zurück und im zweiten Fall gingen die FPS von sagen wir 62,5 auf 58,8 zurück. Wenn jetzt jemand gedacht hat, dass im ersten Fall der größere Einbruch war, dann ist das falsch. In beiden Fällen braucht die Änderung genau 1 ms mehr Rechenzeit pro Frame:

1. Fall: Das Rendern eines Frames dauert vorher 1 ms macht 1 s / 1 ms = 1000 ms / 1 ms = 1 / 1000 s pro Frame oder 1000 FPS. Die Änderung führt dazu, dass das Rendern 1 ms mehr braucht, nun dauert das Rendern eines Frames 2 ms macht 1 s / 2 ms = 1000 ms / 2 ms = 1 / 500 s pro Frame oder 500 FPS.

2. Fall: Das Rendern eines Frames dauert vorher 16 ms macht 1 s / 16 ms = 1000 ms / 16 ms = 1 / 62.5 s pro Frame oder 62.5 FPS. Die Änderung führt wieder dazu, dass das Rendern 1 ms mehr braucht, nun dauert das Rendern eines Frames 17 ms macht 1000 s / 17 ms = 1000 ms / 17 ms = 1 / 58.8 s pro Frame oder 58.8 FPS.

Wie man sieht braucht die Änderung in beiden Fällen nur 1 ms länger, trotzdem bricht die Framerate im ersten Fall um "dramatische" 500 FPS von 1000 FPS auf 500 FPS ein, in zweiten Falle aber eben nur "läppische" 3.7 FPS von 62.5 FPS auf 58.8 FPS.

Fazit: Also bevor Ihr Euch über dramatische Einbrüche der FPS Gedanken macht, schaut Euch lieber die Renderzeit eines Frames an und vergleicht diese, und vor allem macht Euch nicht zu früh zu viele Gedanken. Eine neue Technik, die am Anfang dramatisch FPS zu kosten scheint, kann am Ende ganz unproblematisch sein.

Also ich hoffe, ich habe diese allgemeine bekannte Tatsache wieder ins Gedächtnis gerufen und damit einige Leute vor "Panikattacken" oder Kopfschmerzen bewahrt.

Viele Grüße
Stephan Theisgen

[Zudomon]

Ein Wert pro Frame ist sowieso zu wenig, um damit wirklich was anzufangen. Klar, dadurch hat man eine Aussage, ob die ganze Anwendung noch "in Echtzeit" läuft.
Wenn es aber ums Profilen geht, muss man bestimmte Abschnitte über mehrere Frames hinweg testen. Das sollte man sowieso in ms/µs messen, weil wie du schon sagst, FPS nicht linear sind und man dadurch nichts wirklich einschätzen kann.

[Krishty]

Und auch über mehrere Frames hinweg muss man dann mit dem höchsten (langsamsten) Wert rechnen, weil FPS kaum etwas über die gefühlte Geschwindigkeit aussagen und kurze Einbrüche viel schwerer ins Gewicht fallen als viele schnelle Frames (siehe Mikroruckler-Problematik). Das 3DCenter hatte darüber mal einen lesenswerten Artikel … leider finde ich ihn nicht mehr. Jedenfalls kann es darum auch manchmal nützlich sein, Rechenzeit absichtlich zu opfern, nur um die Ausgabegeschwindigkeit des Programms einigermaßen konstant zu halten.

Gruß, Ky

[Lord Delvin]

Hab ganz gute Erfahrung mit Analyse über die letzten 100 Frames gemacht und dann berechnung von min,max,avg und stabilität, was gegen 1 geht, wenn alle deine Werte gleich sind. Das ganze hab ich dann für framerate und die eigentlich interessanten Werte (bei mir Rays/s) bei dir wohl sowas wie Dreiecke/s oder Models/s, wenn du automatisches LoD hast.

Gruß

[dv]

fps zu verwenden ist an sich nicht schlecht, wenn man weiss, was man tut. fps-Plots können manchmal aussagekräftiger sein als ms-Plots, wenn es um fps-Einbrüche geht. fps sind auch verständlicher für die meisten als ms.
Es ist aber eine SEHR schlechte Idee, fps-Subtraktionen zu machen. Vorher 60 fps, jetzt 50 fps, 10 fps Verlust? Diese Rechnung ist falsch und nichtssagend. 1/60 - 1/50 != 1/10. "10 fps" beschreibt keine Distanz. Wenn man also mit Deltas arbeiten will, muss man ms verwenden - und auch nicht zuerst ms subtrahieren, und das Resultat in fps "zurückrechnen", das ist ebenfalls falsch. Leider kapieren das auch viele Testseiten und -magazine nicht. Wenn ihr Papers schreibt, und solche Rechnungen anstellt, solltet ihr euch auf Kritik beim Peer Review gefasst machen.