Performance von inline Funktionen
-
Also siehst du den einzigen Vorteil von c++ in Graphik apis wie directx, und was meinst du mit richtigem c++?
Natives c++, wenn ja wie wird das in winforms verwendet?
-
sry habe da ein e reininterpretiert
-
c++neuling2 schrieb:
Natives c++, wenn ja wie wird das in winforms verwendet?
Gar nicht. Wenn du richtiges C++ lernen willst, dann lern richtiges C++. Und Zwar richtig. WinForms gibts da nicht, aber mit UI wirst du beim Lernen die erste Zeit sowieso nichts zu tun haben.
Wenn du WinForms willst, dann nimm C#, C++/CLI ist dafür völlig ungeeignet.
-
Nur mal damit du siehst, wie so etwas aussehen könnte.
struct vector3 { float x, y, z; vector3(float x, float y, float z) : x(x), y(y), z(z) {} }; vector3 operator + (const vector3& lhs, const vector3& rhs) { return vector3(lhs.x + rhs.x, lhs.y + rhs.y, lhs.z + rhs.z); }Würde man normalerweise wohl mit Templates etc. machen, aber das spare ich mir hier. Warum du da ^ Handles nutzt, ist mir immernoch ein Rätsel. So sollte zumindest von VS sicher alles geinlined werden.
-
Der Syntax von c++ ist mir bereits aus entsprechender Literatur bekannt, trotzdem danke für den code.
Wenn c++ gänzlich ungeeignet für winforms ist warum sind winforms anwendungen in c++ erstellbar?
mir gehts auch eigentlich erstmal ums prinzip das ganze in c++ nutzbar zu machen, also versuche ich auf "richtiges c++" umzusteigen.
ob das ganze in unverwalteten Klassen zu praktizieren hilft probier ich morgen aus, trotzdem schonmal danke für den support

-
c++neuling2 schrieb:
Wenn c++ gänzlich ungeeignet für winforms ist warum sind winforms anwendungen in c++ erstellbar?
Genauso wie du freihaendig Autofahren kannst und mit den Fuessen steuern... Nur weil es geht, ist es noch lange keine gute Idee.
C++/CLI ist eine Sprache die dafuer entwickelt wurde native C++ Anwendungen leichter mit .NET verschmelzen zu koennen. Niemand schreibt ernsthaft Code in C++/CLI - das ist nur zum zusammenbinden von nativen Code mit managed Code geeignet.
mir gehts auch eigentlich erstmal ums prinzip das ganze in c++ nutzbar zu machen, also versuche ich auf "richtiges c++" umzusteigen.
Dein Ansatz ist falsch. Wenn du C++ lernen oder dir anschauen willst, dann programmiere C++.
-
Dein Ansatz ist falsch. Wenn du C++ lernen oder dir anschauen willst, dann programmiere C++.
Das verwirrt mich jetzt endgültig, was versteht ihr genau unter c++ programmieren, wenn nicht das?
-
ohne cli
-
c++neuling2 schrieb:
Das verwirrt mich jetzt endgültig, was versteht ihr genau unter c++ programmieren, wenn nicht das?
Na C++, nicht WinForms/CLI/VS Spracherweiterungen. Diese ^ Handles sind z.B. kein C++ Sprachmittel.
-
inwiefern läuft dieses c++ programmieren ohne cli ab?
beschränkt sich das dann auf konsolen oder wie?
inwiefern läuft ohne anzeigefenster die kommunikation mit dem Programm ab?nochmal sry ich hab mich wohl verrant

-
Naja, du nimmst halt eine Bibliothek, die direkt mit dem System kommuniziert ohne .NET dazwischen.
Zb Qt statt Winforms.
-
Ahh ok also es GIBT noch sowas wie controls nur eben anders, damit kann ich ja noch leben

Ich hab das ganz kurz versucht umzuschreiben. Gibt mir trotzdem keine äquivalente Ausführzeit.
cpp der Anwendung(Konsolen)
// vektortest.cpp: Hauptprojektdatei. #include "stdafx.h" #include <Windows.h> #include <stdio.h> #include "vektortest.h"; using namespace System; Vektor::Vektor(double x1,double y1,double z1) { Vektor::x = x1; Vektor::y = y1; Vektor::z = z1; } inline void Vektor::operator +=(Vektor vekt) { Vektor::x += vekt.x; Vektor::y += vekt.y; Vektor::z += vekt.z; } int main(array<System::String ^> ^args) { Console::WriteLine(L"Hello World"); Vektor test = *new Vektor(10,10,10); SYSTEMTIME st; GetSystemTime(&st); Vektor tester = *new Vektor(1,1,1); for(int i = 0; i < 10000000;i++) { test += tester; } SYSTEMTIME st2; GetSystemTime(&st2); double verstrichen = (st2.wMilliseconds - st.wMilliseconds); for(int i = 0; i < 10000000;i++) { test.x += tester.x; test.y += tester.y; test.z += tester.z; } GetSystemTime(&st); double verstrichen2 = (st.wMilliseconds - st2.wMilliseconds); return 0; }umgeschriebene vereinfachte Vektor Klassen definition(.h):
#ifndef header #define header public class Vektor { public: double x; double y; double z; Vektor(double x1,double y1,double z1); void operator+=(Vektor vekt); private: }; #endif
-
Ich glaube, die Diskussion über Performance macht an der Stelle keinen Sinn mehr. Du verstehst noch nicht, was du tust, verbeißt dich aber in völlig unwichtige Details.
-
Es ist mir egal ob ich mit 15 Jahren schon soviel Berufserfahrung habe wie du und das einzige was ich erreichen will ist das ich mir diese drei Zeilen Code durch einen überladenen Operator sparen kann und das zum gleichen Zeitaufwand.
Und damit ist denke ich bei verwendung des inline präfixes in diesem fall zu rechnen insofern inline vor der compilation lediglich Codeersetzung betreibt.
Also abschließend, was nicht ist kann ja noch werden und ich fände es nett wenn du dich lieber auf meine performance probleme konzentrieren würdest als auf meine unausgebildeten Programmierkentnisse.
Nichts für ungut.
-
c++neuling2 schrieb:
Wenn c++ gänzlich ungeeignet für winforms ist warum sind winforms anwendungen in c++ erstellbar?
Da liegt wohl ein Missverständnis vor. Du kannst mit C++ keine Windows Forms Anwendungen machen. Das geht nur mit C++/CLI und das ist eine völlig andere Sprache.
Und auch wenn C++/CLI Windows Forms Anwendungen erstellen kann, so ist es trotzdem nicht für die Erstellung von Windows Forms Anwendungen gedacht...c++neuling2 schrieb:
mir gehts auch eigentlich erstmal ums prinzip das ganze in c++ nutzbar zu machen, also versuche ich auf "richtiges c++" umzusteigen.
Wenn du richtiges C++ verwenden willst, dann tu das. C++/CLI ist wie gesagt was anderes.
-
c++neuling2 schrieb:
Also abschließend, was nicht ist kann ja noch werden und ich fände es nett wenn du dich lieber auf meine performance probleme konzentrieren würdest als auf meine unausgebildeten Programmierkentnisse.
Du hast doch schon mehrere Antworten auf die Performancefrage bekommen. Eindeutig kann ich das zumindest nicht beantworten. Die Vermutung mit der Cache Lokalität von Ethon ist plausibel. Eine andere Vermutung wäre der instruction cache. Oder der L1 Cache. Vielleicht kann auch der Prozessor den einen Block besser optimieren als den anderen. Vielleicht kann auch der Compiler den Code besser optimieren, wenn er nicht inline ist. Überlass sowas dem Compiler. Er analysiert selber, ob es sich lohnt, die Funktion zu inlinen und meist wird er das besser schätzen, als der Programmierer.
-
c++neuling2 schrieb:
[...] insofern inline vor der compilation lediglich Codeersetzung betreibt.
Wo auch immer du das her hast: Das ist völliger Schwachsinn.
inline tut viele Dinge (in richtigem C++). Die Tatsache dass es ein leiser Hinweis an den Compiler ist, dass er vielleicht mal drüber nachdenken könnte, die entsprechende Funktion zu inlinen ist nur eins davon...
Abgesehen davon ist das kein C++ und du bist hier nicht native sondern in der CLI Welt unterwegs in der sowieso völlig andere Spielregeln gelten.
Anyway: Ich vermute mal du hast dem Compiler in irgendeiner Weise einen sehr guten Grund gegeben, hier nicht zu inlinen. Ist das überhaupt ein Release Build? Sind die entsprechenden Optimierungen überhaupt aktiviert?
c++neuling2 schrieb:
Also abschließend, was nicht ist kann ja noch werden und ich fände es nett wenn du dich lieber auf meine performance probleme konzentrieren würdest als auf meine unausgebildeten Programmierkentnisse.
Deine unausgebildeten Programmierkenntnisse sind aber genau das eigentliche Problem. Das mangelnde Verständnis der Kräfte mit denen du hier spielst, führt nämlich zu unrealistischen Erwartungen deinerseits, die zwangsweise von der Wirklichkeit enttäuscht werden...
Wenn du C++ lernen willst, dann tu das. Aber dann tu es ordentlich. Und das bedeutet für den Anfang nunmal Konsolenanwendungen.
Wenn du Windows Forms Anwendungen schreiben willst dann vergiss C++/CLI und nimm C#.
-
dot, das hast du schön gesagt

-
@c++neuling2
An deinem "Beispiel" ist so viel falsch/im Argen, das passt auf keine Kuhhaut mehr.-
Du gibst die berechneten Zeiten nirgends aus. D.h. du hast das Ding vermutlich im Debugger laufen lassen. Das tut man beim Benchmarken nicht. Weiters hast du vermutlich einen Debug-Build laufen lassen. Das tut man schon gar nicht.
-
Du verwendest GetSystemTime() zum messen einer Dauer. Das ist Quatsch. GetSystemTime() ist keine "steady clock" und (u.A.) daher nicht als Stoppuhr zu gebrauchen. Verwende timeGetTime() oder QueryPerformanceCounter().
-
Du berechnest das Ergebnis falsch. wMilliseconds ist schon überhaupt gar nicht steady, das springt jede Sekunde auf 0 zurück. Also völliger Quark.
-
Wenn man diese Dinge "bereinigt" optimiert MSVC die Schleife komplett weg, die Laufzeit für beide Schleifen ist dann genau gleich, nämlich genau Null.
-
-
dachte mir auch direkt, dass das garantiert im debug modus war. C++ Compiler sind schon ein wenig besser. Über C++/CLI trifft das natürlich keine Aussage.