Häufig benutzte Variablen in Schleifen innen / außen deklarieren?

Tachyon schrieb:

Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

ist aber nur blöd bei c++ objekten, die konstruktoren/destruktoren aufrufen. bei einfachen typen wie int/long/char usw. macht das nix.

Erhard Henkes

http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=Optimize#Answ

Tachyon

Werner Salomon schrieb:

Tachyon schrieb:

Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

Dies ist ein weit verbreiteter Irrtum, dass dies zu langsameren Code führen muss!

Die Variante 1 (innen) ist nicht nur besser lesbar sondern ist auch der schnellere Code. Fülle ich den String mit 1000 Zeichen und erhöhe die Anzahl der Durchläufe von 10 auf 10000, so braucht die Variante 1 (innen) nur 14msec - die Variante 2 (außen) aber 17msec.
Meiner Meinung nach liegt das daran, das in Variante 1 eben weniger (!) Kopien des Strings gemacht werden - wegen der 'Return Value Optimization'. Die ist genau dann möglich, wenn der String nach der Rückgabe aus 'getString()' erst angelegt wird.

Gruß
Werner

Hmm, sowohl mit gcc als auch mit msvc ist bei mir die Innen-Variante deutlich langsamer. Ca. Faktor 4 mit MSVC und ca. Faktor 5 bei g++.

LordJaxom

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Werner Salomon

Hallo Erhard,

in Zeile 48 fehlt noch die Ausgabe, dass hier ein 'int' zugewiesen wird, und in Zeile 105 und 115 darf es nicht

xINT x;
        x = i;

heißen sondern

xINT x = getXInt();

mit

xINT getXInt() { return xINT(); }

dann sieht der Output zwichen den Varianten etwas ausgeglichener aus.

Nämlich:

Variante 1
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor

Variante 2
0012FF5C: ctor
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151

.. und plötzlich ist viel mehr Aktion bei Variante 2 !

Gruß
Werner

Tachyon

LordJaxom schrieb:

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

Erhard Henkes

@Werner Salomon: Right Sir!
Jetzt wird es endlich praktisch.

Tachyon

Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

LordJaxom

Tachyon schrieb:

LordJaxom schrieb:

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

Entschuldige, das wusste ich natürlich nicht. Kannst Du das in Deine Signatur schreiben? Dann sieht man es gleich und muss nicht fragen...

(Muss ich noch einen Smiley anbringen, um den humoristischen Charakter dieses Statements zu entschärfen? )

Spaß beiseite: Nicht nur Neulinge, auch erfahrene Forenbesucher dürfen gerne jegliche potentiell hilfreichen Angaben machen, um ein Problem oder eine Lösung nachzuvollziehen. Mich interessiert das Thema und natürlich auch Dein Test, sonst hätte ich nicht nachgefragt. Allerdings komme ich bei meinen lokalen Tests nur auf Faktor 1,5 - 2 (MSVC++ 8.0), da wäre es schon schön die Unterschiede zu kennen.

Tachyon

LordJaxom schrieb:

Tachyon schrieb:

LordJaxom schrieb:

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

Entschuldige, das wusste ich natürlich nicht. Kannst Du das in Deine Signatur schreiben? Dann sieht man es gleich und muss nicht fragen...

(Muss ich noch einen Smiley anbringen, um den humoristischen Charakter dieses Statements zu entschärfen? )

Sorry, ich habe meinerseits den Smily unterschlagen.

Immerhin scheinst Du auch einen Unterschied feststellen zu können. Ich habe hier einen relativ lahmen Firmenrechner mit einem P4. Vielleicht erklären sich daraus irgendwelche Unterschiede.

Werner Salomon

LordJaxom schrieb:

Spaß beiseite: Nicht nur Neulinge, auch erfahrene Forenbesucher dürfen gerne jegliche potentiell hilfreichen Angaben machen, um ein Problem oder eine Lösung nachzuvollziehen. Mich interessiert das Thema und natürlich auch Dein Test, sonst hätte ich nicht nachgefragt. Allerdings komme ich bei meinen lokalen Tests nur auf Faktor 1,5 - 2 (MSVC++ 8.0), da wäre es schon schön die Unterschiede zu kennen.

Hallo LordJaxom,

mein Code sieht so aus:

// includes ..
struct S
{
    std::string getString() const
    {
        return std::string( 1024, 'x' );
    }
};

int main()
{
    S Foo;
    sam::Watch uhr;
    std::cout.setstate( std::ios_base::failbit );
    {
        sam::Watch::Stopper stopper(  uhr );
        // std::string str;
        for (int i=0; i<10000; ++i)
        {
            std::string str = Foo.getString();
            std::cout << str << std::endl;
        }
    }
    std::cout.clear();
    std::cout << "benötigte Zeit. " << uhr << std::endl;
    return 0;
}

damit erreiche ich das Verhältnis 17msec für Variante 1 und 20msec für Variante 2 (MS-VC8). Die zuerst genannten Werte (14msec zu 17msec) erreiche ich mit einem leeren std::ostream.

Die Zeitmessung geschieht mit dem 'QueryPerformanceCounter' aus der WinAPI (Code nicht gepostet).

Ich denke, es hängt viel davon ab, wie die Funktion aussieht, die den String liefert.

Gruß
Werner

Shade Of Mine

Tachyon schrieb:

Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

Was hat das mit der Executable zu tun?
Die innenvariante ist die schnellere wenn man sie nicht explizit aushebelt wie es erhard getan hat.

Tachyon

Werner Salomon schrieb:

Ich denke, es hängt viel davon ab, wie die Funktion aussieht, die den String liefert.

Das denke ich auch. Ich habe jetzt auch eine Version gebastelt, wo beide Varianten identische Ergebnisse liefern.
Wenn man direkt aus einem std::string kopiert sieht es wieder ganz anders aus.

Tachyon

Shade Of Mine schrieb:

Tachyon schrieb:

Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

Was hat das mit der Executable zu tun?
Die innenvariante ist die schnellere wenn man sie nicht explizit aushebelt wie es erhard getan hat.

Das hat damit zu tun, wie und ob vor einer Variante schon Speicher allokiert wurde, oder nicht.

Erhard Henkes

Wenn es wirklich auf diesen Geschwindigkeitsunterschied ankommt, sollte man im jeweils echten Fall beide Varianten bezüglich Zeitverbrauch testen. Dann kann man entsprechend den Prioritäten entscheiden.

Shade Of Mine

Tachyon schrieb:

Das hat damit zu tun, wie und ob vor einer Variante schon Speicher allokiert wurde, oder nicht.

Äh... nein.

Die innen Variante ist nur abhängig von der RVO. Wenn RVO funktioniert ist die innenvariante schneller oder gleichschnell. Wenn RVO nicht funktioniert ist sie langsamer.

RVO heisst, dass man exakt N ctor und N dtor aufrufe hat (in der schleife) unabhängig von den externen faktoren.

wenn keine RVO funktioniert, hat man N ctor aufrufe, N copyctor aufrufe und 2*N dtor aufrufe.

während es bei der aussen variante 1 ctor, N op=, N ctor, N+1 dtor aufrufe sind.

und das hat nichts mit der funktion zu tun die die daten liefert - sofern sie ein passendes objekt liefert und wir keine konvertierungen haben. denn dann wird es komplex.

cubeman

Oha, meine Frage war gar nicht so blöd

Das mit der Schleife mit dem string war nur ein vereinfachtes Beispiel. Genau genommen habe ich eine 2D Vektor Klasse, wo ich bei einem Vektor eine Komponente verändern will.

Ich habs mal getestet, alle vier Varianten bringen keine nennenswerten Unterschiede bei mir:

#include <iostream>
#include <windows.h>

using namespace std;

class Vector2D
{
public:
	Vector2D(int x_ = 0, int y_ = 0) : x(x_), y(y_) {}
	int getX() { return x; }
	int getY() { return y; }
	void setX(int newx) { x = newx; }
	void setY(int newy) { y = newy; }
	int x, y;	// zum Testen public
};

Vector2D& getSomeVector()
{
	static Vector2D s_foo(1,2);
	return s_foo;
};

int main()
{
	const long LOOPCOUNT = 1000000;
	cout.setstate( ios_base::failbit );

	// Variante 1 (innen)
	DWORD startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		Vector2D myVec = getSomeVector();
		myVec.setX (3);
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 1 (innen) brauchte:   " << (GetTickCount ()-startticks) << "ms" << endl;
	cout.setstate( ios_base::failbit );

	// Variante 2 (aussen)
	Vector2D myVec;
	startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		myVec = getSomeVector();
		myVec.setX (3);
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 2 (aussen) brauchte:  " << (GetTickCount ()-startticks) << "ms" << endl;
	cout.setstate( ios_base::failbit );

	// Variante 3 (set/get)
	startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		myVec.setY (getSomeVector().getY());
		myVec.setX (3);
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 3 (set/get) brauchte: " << (GetTickCount ()-startticks) << "ms" << endl;
	cout.setstate( ios_base::failbit );

	// Variante 4 (member)
	startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		myVec.y = getSomeVector().y;
		myVec.x = 3;
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 4 (member) brauchte:  " << (GetTickCount ()-startticks) << "ms" << endl;
	return 0;
}

So wie es ausschaut bleibe ich bei der Innenvariante. Ist klar, verschmutzt keinen Scope und ist schnell genug

__Stefan__

Man achte auf die Kapazität der Strings. Sie weist darauf hin dass in Beispiel 1 immer dynamisch Speicher angefordert / freigegeben wird. Damit erübrigt sich wohl die Frage, was schneller ist (Ich hab's nicht nachgemessen ;)).

using namespace std;

	for(int i = 0; i < 100; ++i)
	{
		string s;

		cout << s.capacity() << '\n';

		s += string(50, 'a');
	}

using namespace std;

	string s;

	for(int i = 0; i < 100; ++i)
	{
		s.clear();

		cout << s.capacity() << '\n';

		s += string(50, 'a');
	}

Erhard Henkes

Genau genommen habe ich eine 2D Vektor Klasse, wo ich bei einem Vektor eine Komponente verändern will.

Na, dann lag ich mit meiner Testklasse xINT doch gar nicht so schlecht.

verschmutzt keinen Scope

Wenn sonst alles sauber bleibt.

Ich habe mal das Beispiel oben laufen lassen.

Variante 1 (innen) brauchte: 203ms
Variante 2 (aussen) brauchte: 219ms
Variante 3 (set/get) brauchte: 250ms
Variante 4 (member) brauchte: 203ms

Compiler/IDE: Code::Blocks 8.02 (Standard, ohne Optimierung)

Variante 1 (innen) brauchte: 203ms
Variante 2 (aussen) brauchte: 218ms
Variante 3 (set/get) brauchte: 188ms
Variante 4 (member) brauchte: 219ms

Compiler/IDE: Code::Blocks 8.02 (mit Optimierung -O3)

Variante 1 (innen) brauchte: 187ms
Variante 2 (aussen) brauchte: 203ms
Variante 3 (set/get) brauchte: 219ms
Variante 4 (member) brauchte: 203ms

Compiler/IDE: Code::Blocks 8.02 (mit Optimierung -O3 und Intel Pentium Pro)

Variante 1 (innen) brauchte: 63ms
Variante 2 (aussen) brauchte: 62ms
Variante 3 (set/get) brauchte: 62ms
Variante 4 (member) brauchte: 63ms

Compiler/IDE: MS VC++ 6.0

__Stefan__

Erhard Henkes schrieb:

Genau genommen habe ich eine 2D Vektor Klasse, wo ich bei einem Vektor eine Komponente verändern will.

Na, dann lag ich mit meiner Testklasse xINT doch gar nicht so schlecht.

verschmutzt keinen Scope

Wenn sonst alles sauber bleibt.

Ich habe mal das Beispiel oben laufen lassen.

Variante 1 (innen) brauchte: 203ms
Variante 2 (aussen) brauchte: 219ms
Variante 3 (set/get) brauchte: 250ms
Variante 4 (member) brauchte: 203ms

Compiler/IDE: Code::Blocks 8.02

Variante 1 (innen) brauchte: 63ms
Variante 2 (aussen) brauchte: 62ms
Variante 3 (set/get) brauchte: 62ms
Variante 4 (member) brauchte: 63ms

Compiler/IDE: MS VC++ 6.0

#include <iostream>
#include <ctime>

int main()
{

	using namespace std;

	time_t t = clock();

	for(int i = 0; i < 1000000; ++i)
	{
		string s;

		s += string(50, 'a');
	}

	cout << clock() - t << '\n';

	t = clock();

	string s;

	for(int i = 0; i < 1000000; ++i)
	{
		s.clear();

		s += string(50, 'a');
	}

	cout << clock() - t << '\n';

    return 0;
}

Visual C++ 2008 Compiler

Optimiert mit /Ox

968ms
672ms