Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Hallo,
Ich habe einen FPS-Vergleich zwischen Linux und Windows gemacht. Das Ergebnis:
Linux Ubuntu, Kernel 8.04.1: Max.FPS: rd. 2760
Windows XP SP2: Max. FPS: rd. 1150
CPU: Intel Core2Duo E4600
Grafikkarte: Nvidia Geforce 6600GT
Gezeichnet unter Verwendung von OpenGL
Beides wurde auf derselben Harware mit einem gleichartigen FPC-Programm gerendert (der Sourcecode war größtenteils gleich, nur die nötigen Betriebssystem-Routinen waren natürlich unterschiedlich).
In Windows wurden für die Messung der FPS sowohl GetTickCount als auch alternativ TimeGetTime verwendet, beide brachten das gleiche Ergebnis (kompiliert mit Delphi).
Mit Lazarus wurde die Messung auf beiden Betriebssystemen mit mit der FPC-Funktion "GetLocalTime" ausgeführt. In Windows brachte das wieder das gleiche Ergebnis wie GetTickCount und TimeGetTime.
Habt ihr eine Ahnung, warum das so unterschiedlich ist?
Traude
TimeGetTime und GetTickCount sind im Bereich von Millisekunden nicht sonderlich genau.
QueryPerformanceCounter/QueryPerformanceFrequency sind für Zeitmessungen besser geeignet. Falls die Messdauer nur eine Sekunde beträgt, kann das eine Rolle spielen.
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Habe es jetzt mit QueryPerformanceCounter/Frequency probiert. Die Frequenz war 2.400.110.000 (es ist ein 2,4Ghz Rechner) und die Differenz der Counter war 2.788.740. Frequenz durch Counterdifferenz gibt ca. 860 FPS. Allerdings schwanken die Werte relativ stark und die Anzeige am Bildschirm schrieb irgendwas von 1.100 und noch ein paar, es war schlecht zu lesen weil es sich dauernd geändert hat. Aber im Prinzip hat das eigentlich die Berechnung mit der Systemzeit bestätigt. Es bleibt die Tatsache, dass der FPS-Wert in Windows nur halb so groß ist wie in Linux, und zwar auf derselben Hardware.
Also ich bin ja kein Microsoftfreund, aber das kann ich nicht glauben. Ich muss irgendwo einen Fehler bei der Berechnung gemacht haben.
Das stimmt doch aber so:
2.788.740 Ticks für X Milli-Sekunden
2.400.110.000 Ticks für 1000 Milli-Sekunden
===> X = 2.788.740 / 2.400.110.000 * 1000 = 1,161922 Milli-Sekunden für einen Rendervorgang
===> in einer Sekunde werden daher 1000 / 1,161922 ~ 861 Rendervorgänge durchlaufen.
Könnte es vielleicht irgendwas mit dem DuoCore zu tun haben?
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Microsoft hat sich bei mir in der Vergangenheit mit diversen Strategiensicherlich sicherlich nicht beliebt gemacht hat. Allerdings weiß ich nicht ob man so etwas 100% sicher Testen kann. Denn es spielen eine unendliche Vielzahl an Faktoren dabei eine Rolle.
Es könnte sein, dass der Treiber unter Linux einfacher aufgebaut ist.
Es könnte sein, dass Linux eine besseres Threadmanagement hat als Windows und somit bei einem Prozessor.- bzw Taskwechsel weniger Zeit flöten geht.
Es könnte sein, dass der Linuxtreiber besser zu solch einem Threadmanagement passt.
Denn was du nicht vergessen darfst. Die Grafikkarte ist die Selbe, die CPU ist die Selbe und Code wird auf beiden Systemen in etwa gleich ausgeführt. Zu mal kommt es auch noch sehr sehr stark darauf an was du testest. Evtl ist das Feature in einem der beiden Treiber besser optimiert als in dem Anderen. Bzw denke ich, wenn du nur ein großes VBO rendern würdest, dann wird die Zeit nahezu identisch sein. Denn es existiert nicht so viel Overhead durch Funktionsaufrufe. Eventuell kann der Treiber unter Linux auch einfach das Bild schneller zeichnen als unter Windows. Also ob da wirklich OpenGL schneller ist oder nur "randfaktoren" da eine Rolle spielen kann man meiner Meinung da kaum wirklich abschätzen.
genau - probiers doch mal mit was richtig komplexem - wenn de nen md2 loader drin hast, kannste dir ja mal fünfzehn player modelle reinladen und schaun, wer dann schneller ist - am besten so nah ranzoomen, das der ganze bildschirm ausgefüllt ist - ansonsten find ich allein die aktion schon lustig mfg grey
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
@grey: Ich bin gerade dabei, eine Pascal-Betriebssystem-Schnittstelle zu schreiben für Leute, die OpenGL mit Pascal sowohl in Windows als auch in Linux verwenden wollen. Und jetzt mache ich grade die Uhr-Funktion und teste, was im jeweiligen Betriebssystemen dafür am besten geeignet ist.
Daher zeichne ich gar nichts Kompliziertes. Ich zeichne ein simples Quad, und zwar im Immediate Mode. Grade wollte ich sagen, dass ich keine Textur dabei habe, aber das stimmt nicht: Ich habe eine Texture Font (Freetype), weil ich die FPS ja mit irgendwas anzeigen muss. Aber das ist wirklich alles. Ein Quad und eine Textur, sonst nichts.
Lossy Ex schrieb:
Zitat:
Es könnte sein, dass der Treiber unter Linux einfacher aufgebaut ist.
Es könnte sein, dass Linux eine besseres Threadmanagement hat als Windows und somit bei einem Prozessor.- bzw Taskwechsel weniger Zeit flöten geht.
Es könnte sein, dass der Linuxtreiber besser zu solch einem Threadmanagement passt.
Ja, das könnte alles sein. Und außerdem ist ja noch die Tatsache, dass der Bildschirm ja nur eine begrenzte Refreshrate hat. Fällt mir grad ein, weil ich in Windows das VSync ausschalten musste, in Linux aber nicht.
Auffällig war, dass in Windows die Framerate sprunghaft ansteigt, wenn man ein Fenster drüberzieht (durch das Clipping, nehme ich an), in Linux bleibt die Framerate dabei aber gleich. Spricht auch dafür, dass hier im Hintergrund eine "einfachere" Routine werkelt.
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Das Rätsel hat sich aufgeklärt und die Welt ist wieder in Ordnung:
In meinem Linux ist nach dem Start das Antialiasing/Anisotropic Filtering ausgeschaltet, in Windows ist es eingeschaltet. Wenn ich das Antialiasing in Linux einschalte, ist praktisch kein Unterschied mehr zwischen den FPS der beiden Betriebssysteme.
Traude
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Bei mir liegt der unterschied auch nicht weit auseinander.
Wenn ich ein einfaches Quad habe, dann hat meine linux app ca 1800FPS und meine Windows ca 1700FPS.
Linux hat ne dünnere verarbeitung von Events und Ressourcen, daher fällt es bei sehr geringer CPU-Last es mehr auf aber bei mehr CPU-Last merkt man das in der FPS fast garnicht mehr.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.