ZFX + Developia

Hallo und guten Morgen,

ich sitze gerade wieder hier, und will Face-Normals berechnen.
Ich dachte mir, schreibst eine Member-Funktion (calcFaceNormal(...)) der 3 Vertices übergeben wird und einen normalisierten Vektor zurückgibt, halt die Fläschennormale.
Ich bin am überlegen, ob ich diese Member-Funktion (calcFaceNormal(...)) nicht statisch machen sollte...
Ich weiß ja nicht, ob sich das irgendwie auf die Performance auswirkt.

Also: was ist performanter: statische Funktionen oder nicht-statische?

[edit]
Mmmhh..., naja: statische Funktionen sind bestimmt schneller.
Und nicht-member-statische Funktionen sind bestimmt noch schneller.
Wieso eigentlich?
[/edit]

Statische Funktionen sind vielleicht schneller, aber bestimmt nicht soviel, als dass es sich lohnen würde darüber nachzudenken, seinen Code danach auszurichten.

Das ist Compiler und plattformabhängig würde ich sagen.

Am schnellsten wäre es, wenn es eine Methode der Klasse „Face“ wäre – dann müsste die Funktion nämlich überhaupt keine Parameter (außer dem unsichtbaren this-Zeiger) mehr annehmen und auch nichts mehr zurückgeben ;)
Nein, mal im Ernst – wovon ist das denn eine Methode? Ich rieche da einen unsauberen Entwurf, und der ist immer noch Performance-Killer Nummer Eins …

Und nicht-member-statische Funktionen sind bestimmt noch schneller.

Nein. Dass eine Klassenfunktion messbar schneller ist als eine (nicht virtual deklarierte) Methode, ist schon ein seltener Zufall … und spricht für einen falsch eingestellten Optimizer. Funktionen und Klassenfunktionen sind hingegen nach der Namensauflösung vollkommen identisch.

Gruß, Ky

joggel hat geschrieben: Mmmhh..., naja: statische Funktionen sind bestimmt schneller.
Und nicht-member-statische Funktionen sind bestimmt noch schneller.
Wieso eigentlich?

Ja, wieso eigentlich? Wie kommst du da drauf?

Zwischen statischen Funktionen in Klassen und Funktionen außerhalb von Klassen gibt es keinen Unterschied. Eine normale Memberfunktion verhält sich nicht anderes als eine Funktion außerhalb von Klassen die den this-Zeiger implizit als zusätzliches Argument bekommt. Nur von virtuelle Memberfunktionen sollte man ein bisschen Performanceeinbuße erwarten weil die ja erst mal zur Laufzeit ihre Implementierung finden müssen, aber dass ist normalerweise auch nicht mehr als ein Zugriff auf einen Zeiger in einen Array und eine kleine Einschränkung für den Optimizer. Für Funktionen außerhalb von Klassen hat "static" nur den Effekt das sie nicht in anderen Übersetzungseinheiten sichtbar sind, aber das macht man in C++ heutzutage mit anonymen Namespaces. Einfluss auf die Performance dürfte das nicht haben.

Für kleine Funktionen kann ein "inline" die Performance verbessern. Allerdings kann der Compiler sich entscheiden das Inlining doch nicht zu machen (z.B. weil der generierte Code so aufgebläht wird das der Overhead eines echten Funktionsaufrufs besser erscheint), bzw. auch für Funktionen zu machen bei denen es nicht explizit gewünscht wird. Letzten Endes hängt es also vom Szenario und dem Compiler ab ob es überhaupt einen Unterschied macht.

Wenn du es genau wissen willst dann probier halt mal alle Varianten aus. Das dürfte nicht so viel länger dauern als hier im Forum zu posten und Antworten abzuwarten. Und am Ende weisst du dann auch mit Sicherheit was für deine Situation am besten geeignet ist.

Abgesehen davon empfehle ich dir dich mit der Lösung deines eigentlichen Problems zu beschäftigen und den Code so effektiv wie möglich schreiben (im Sinne von Resultat pro Arbeitszeit). Solche "kleinlichen" Optimierungen kann man immer noch nachrüsten wenn sie sich als notwendig erweisen. Da kannst du dann einen Profiler mitlaufen lassen und weißt auch an welchen Stellen sich Optimierung wirklich lohnt.

Krishty hat geschrieben: Nein, mal im Ernst – wovon ist das denn eine Methode? Ich rieche da einen unsauberen Entwurf, und der ist immer noch Performance-Killer Nummer Eins …

Gruß, Ky

Nun ja, eigentlich ist es ein "unsauberer" Entwurf.
Ich habe eine Klasse, TheRenderObject ( is halt eine Klasse, der beim instanziieren ein paar Paremeter übergeben werden, und dann anhand dieser Parameter unterschiedlich gezeichnet (also das VBO wird generiert.... alles per OpenGL).
Sprich: ich berechne alle Vertices, alle Indices für das zeichnen der Quads und alle Flächen-Normalen.
Die Funktion calcFaceNormal(..) ist im Moment Member der TheRenderObject-Klasse!
Ja, ziemlich unsauber...
Ich habe aber keine Lust, eine Klasse zu schreiben, bspw. Dreieck, der ich die Vertices übergebe, und die mir dann die Face-Normal ausspuckt!


[Edit]

Sternmull hat geschrieben: Ja, wieso eigentlich? Wie kommst du da drauf?

War nur so ein spontanes Gefühl...
[/edit]

Vielleicht solltest du mal die Einstellungen des Optimierers überarbeiten? Mir macht nicht sorgen, dass die Funktion schneller ist als die Methode – mir macht Sorgen, dass der Compiler offenbar nicht erkannt hat, dass die Unterscheidung hinfällig ist.

Sternmull hat geschrieben:Für kleine Funktionen kann ein "inline" die Performance verbessern. Allerdings kann der Compiler sich entscheiden das Inlining doch nicht zu machen (z.B. weil der generierte Code so aufgebläht wird das der Overhead eines echten Funktionsaufrufs besser erscheint), bzw. auch für Funktionen zu machen bei denen es nicht explizit gewünscht wird. Letzten Endes hängt es also vom Szenario und dem Compiler ab ob es überhaupt einen Unterschied macht.

Der erste Satz ist falsch, die anderen beiden stimmen. Visual C++ mit vollständiger Inline Function Expansion und Link-Time Code Generation ignoriert inline völlig und produziert dabei besseren Text als es die meisten Programmierer je fertigbringen könnten. Es ist Verschwendung von Quelltext und Lebenszeit, noch irgendwas inline zu deklarieren, wenn es nicht um der Nebenwirkungen Willen (interne Sichtbarkeit) ist. (In wenigen Ausnahmefällen kann __forceinline helfen … __declspec(noinline) aber genauso. Und schon sind wir bei optimierter Anordnung der Funktionen zwecks Seitenfehlerminimierung …)

Krishty hat geschrieben:

Sternmull hat geschrieben:Für kleine Funktionen kann ein "inline" die Performance verbessern. ...

Der erste Satz ist falsch, die anderen beiden stimmen. ...

Was ist da dran falsch? Die MSDN sagt zu "inline" unter anderem

The insertion (called inline expansion or inlining) occurs only if the compiler's cost/benefit analysis show it to be profitable. Inline expansion alleviates the function-call overhead at the potential cost of larger code size.

Nach meinem Verständnis profitieren davon vor allem kleine Funktionen weil es sich für große nicht lohnen dürfte den Code mehrfach im Programm zu haben bzw. der Compiler das inlining schon von sich aus verweigert.

Dass du von einem "inline" statt von Inlining gesprochen hast, hatte ich so verstanden, dass du damit das explizite Ausschreiben des inline-Schlüsselworts vor der Funktion meinst (und das „doch“ im zweiten Satz klang auch nach „trotz ausgeschriebenem inline“) – und das ist eben vergebene Liebesmüh, weil der Compiler entscheidet (wie in der MSDN steht). Aber wenn du damit stattdessen das Vorgehen des Compilers meintest, Funktionen direkt beim Aufrufer einzusetzen – Inlining – hast du natürlich recht.

Übrigens profitieren nicht nur kleine Funktionen davon, sondern auch Funktionen, die nur genau ein Mal aufgerufen werden – das lässt VCpps Optimizer leider unter den Tisch fallen … aber damit kann man auch nochmal was rausholen (ohne Prolog, Epilog und Parameterübergabe sinkt der Registerdruck, Exception-Handler können verschmolzen werden usw usf).

Ich hab schon das "inline" Schlüsselwort gemeint. Und dazu steht in der MSDN das abhängig von der /Ob-Option entschieden wird ob nie, nur für "inline"-Funktionen, oder immer versucht wird Inlining anzuwenden. Bei voller Optimierung passiert das immer, insofern kann man das Schlüsselwort schon als überflüssig betrachten (wenn man MSVC verwendet und es einem nicht um das Linker-Verhalten geht). Aber es gibt ja noch andere Compiler und speziellere Optimierungs-Anforderungen (z.B. Größe minimieren und Inlining nur bei den "inline" deklarierten Funktionen versuchen). Von daher würde ich es nicht immer als vergebene Liebesmühe bezeichnen. Obwohl ich es normalerweise in das Reich der sinnlosen Optimierungs-Bemühungen verbannen würde. Ach egal, wahrscheinlich meinen wir eh das gleiche und ich betreibe hier nur sinnlose Haarspalterei :)

Ja, denke ich auch. inline ist insofern ein Reinfall, als dass es mittlerweile eine ganz andere Bedeutung hat, als „setz die Funktion beim Aufrufer ein“. Das ist problematisch sowohl für die Programmierer, die es dafür benutzen wollen, als auch für die, die es dafür eben nicht benutzen wollen (wie mich) und nicht zuletzt für die Compiler-Hersteller, die sich entscheiden müssen, wessen Maul zu stopfen ist. Darum sollte man, wenn man sich wirklich solchen Optimierungen hingibt, unbedingt ein Compiler-abhängiges Schlüsselwort benutzen.

joggel hat geschrieben:ich sitze gerade wieder hier, und will Face-Normals berechnen.
Ich dachte mir, schreibst eine Member-Funktion (calcFaceNormal(...)) der 3 Vertices übergeben wird und einen normalisierten Vektor zurückgibt, halt die Fläschennormale.
Ich bin am überlegen, ob ich diese Member-Funktion (calcFaceNormal(...)) nicht statisch machen sollte...
Ich weiß ja nicht, ob sich das irgendwie auf die Performance auswirkt.

Also: was ist performanter: statische Funktionen oder nicht-statische?

Mal unabhängig von deiner Frage nach Performance. Die Entscheidung ob Member-Funktion oder statische Funktion sollte nicht auf Grundlage von Performance-Gründen erfolgen, sondern daran gemessen werden, ob der Einsatz design-technisch sinnvoll ist. Eine statische Funktion macht eigentlich so gut wie nie Sinn; dann doch eher eine globale Funktion in einem schönen Namespace. Wenn das (ohne Aufweichung von Member-Zugriffsrechten) geht, dann mach es so. Wenn nicht, nimm eine Member-Funktion. In diesem Fall würde ich zu einer globalen Funktion raten, da du ja eigentlich nur ein paar Berechnungen durchführen musst und du über die Schnittstelle der Vertices sicherlich auch die internen Daten auslesen kannst und beim Anlegen eines neuen Vektors sicher auch die internen Daten angeben kannst. Wozu also überhaupt in eine Klasse packen? :)

BeRsErKeR hat geschrieben:In diesem Fall würde ich zu einer globalen Funktion raten, da du ja eigentlich nur ein paar Berechnungen durchführen musst und du über die Schnittstelle der Vertices sicherlich auch die internen Daten auslesen kannst und beim Anlegen eines neuen Vektors sicher auch die internen Daten angeben kannst...

Ja, ich habe die Funktion halt als Member der RenderObject-Klasse gemacht!
Ach und auserdem: eigentlich kann man solche Sachen wie Performance bei meiner Geschichte vergessen, da die Berechnung der FaceNormals sowieso nur einmal durchgeführt wird, und zwar ziemlich am Anfang, da wor noch anderer Mist geladen/verarbeitet wird!
Also nicht Zeitkritisch!

Könntest Dein Design jetzt ja ein bischen optimieren, falls Du darauf Bock hast. :)