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

[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

[princess]

fricky 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.

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

int, long, char,... sind auch objekte in c++, wo auch ein c'tor und d'tor aufgerufen werden muss
z.B. int i(5); ist ein c'tor aufruf wie ausm lehrbuch mit einer einparametrigen übergabe.
... alles ist ein objekt und ne menge ein stream.

[Erhard Henkes]

... alles ist ein objekt

nö!

[camper]

cubeman schrieb:

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

So wie es ausschaut, ist das grober Unfug. Ich hab mal die couts durch

cout << (GetTickCount ()-startticks) << '\t';

(und beim letzten dann endl) ersetzt, und das ganze in eine Schleife for(;;) gepackt. Ergebnis bei mir Visual C++ 9.0 Express optimiert

391     312     313     297
390     313     312     329
343     313     344     328
328     312     313     359
313     312     328     328
313     312     344     328
312     313     328     328
313     375     312     313
312     328     313     359
313     359     297     312
344     328     313     312
328     313     297     328
359     297     313     328
328     328     313     375
312     313     312     359
313     312     375     313
297     312     438     328
297     375     297     312
344     391     296     313
359     313     297     328
422     312     313     297
468     328     329     359
312     313     328     344
312     313     328     328
344     312     360     312
313     328     359     313
312     328     313     312
313     344     312     313
312     344     328     312
313     359     297     328
344     297     312     313
359     313     312     391
312     329     312     344
312     344     344     328
312     313     359     313
312     313     344     328
312     328     328     391
328     344     312     329
312     375     297     328
344     312     375     328
360     312     313     375
312     297     328     328

usw. hier kann man viel erkennen, unter anderem das Timerintervall von Windows =16ms - aber eine Geschwindigkeitsmessung ist das nicht, schon gar nicht von dem, was du messen wolltest. Ich würde mal vermuten, dass hier viel Zeit mit den Streams verbracht wird.

[cubeman]

camper schrieb:

cubeman schrieb:

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

So wie es ausschaut, ist das grober Unfug. Ich hab mal die couts durch

So wie es ausschaut ist es aber so! Okay, die streams könnten das Ergebnis verfälschen, da hast du natürlich recht.

#include <iostream>
#include <ctime>

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 unsigned long LOOPCOUNT = 1000000000;

	// Variante 1 (innen)
	clock_t startticks = clock ();
	for (unsigned long l = 0; l < LOOPCOUNT; ++l)
	{
		Vector2D myVec = getSomeVector();
		myVec.setX (3);
	}
	cout << "Variante 1 (innen) brauchte:   " << ((clock ()-startticks)/ (double) CLOCKS_PER_SEC) << "s" << endl;

	// Variante 2 (aussen)
	Vector2D myVec;
	startticks = clock ();
	for (unsigned long l = 0; l < LOOPCOUNT; ++l)
	{
		myVec = getSomeVector();
		myVec.setX (3);
	}
	cout << "Variante 2 (aussen) brauchte:  " << ((clock ()-startticks)/ (double) CLOCKS_PER_SEC) << "s" << endl;

	// Variante 3 (set/get)
	startticks = clock ();
	for (unsigned long l = 0; l < LOOPCOUNT; ++l)
	{
		myVec.setY (getSomeVector().getY());
		myVec.setX (3);
	}
	cout << "Variante 3 (set/get) brauchte: " << ((clock ()-startticks)/ (double) CLOCKS_PER_SEC) << "s" << endl;

	// Variante 4 (member)
	startticks = clock ();
	for (unsigned long l = 0; l < LOOPCOUNT; ++l)
	{
		myVec.y = getSomeVector().y;
		myVec.x = 3;
	}
	cout << "Variante 4 (member) brauchte:  " << ((clock ()-startticks)/ (double) CLOCKS_PER_SEC) << "s" << endl;
	return 0;
}

Besser?

So, das hab ich mal auf meinem P233 MMX laufen lassen:

#g++ --pedantic loopvar.cpp -O3 -o loopvar
#./loopvar
Variante 1 (innen) brauchte:   18.58s
Variante 2 (aussen) brauchte:  23.21s
Variante 3 (set/get) brauchte: 23.35s
Variante 4 (member) brauchte:  23.22s

Auch unter VS2005 ist Variante 1 bei mir zumindest gleich schnell!

[fricky]

princess schrieb:

fricky 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.

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

int, long, char,... sind auch objekte in c++, wo auch ein c'tor und d'tor aufgerufen werden muss

aber nur theoretisch. in wirklichkeit passiert da fast nix.

[camper]

cubeman schrieb:

So wie es ausschaut ist es aber so! Okay, die streams könnten das Ergebnis verfälschen, da hast du natürlich recht.

was denn nun? entweder ist dein Meßverfahren brauchbar oder es ist unbrauchbar. Ich behaupte Letzteres. Mit unbrauchbaren Meßverfahren kann man nichts beweisen.
Vom theoretischen Standpunkt aus gibt es zwischen den einzelnen Varianten keinen prinzipiellen Unterschied, der unterschiedliche Laufzeiten bedingt. Das wiederum liegt am atypischen Fall der Refernzrückgabe in getSomeVector und der Tatsache, das der Funktionsaufruf wahrscheinlich ohnehin inline-substituiert wird, was as-if-Optimierungen erleichtert.

Aber es wäre ja auch langweilig, Code zu testen, der einigermaßen normal geschrieben wurde...

Ich widerspreche damit nicht der Schlussfolgerung selbst - aber es kann doch nicht so schwer sein, den Test so zu gestalten, dass er diese Argumentation tatsächlich stützt...

[cubeman]

Natürlich ist das Beispiel nicht ideal, da es nur zusammengeschustert ist für diesen Test...

Kann ich aber daraus ableiten, dass das Deklarieren von Variablen im Schleifenkörper keine dramatischen Performanceeinbußen bringt? Ich denke ja.

camper schrieb:

Aber es wäre ja auch langweilig, Code zu testen, der einigermaßen normal geschrieben wurde...

Ich widerspreche damit nicht der Schlussfolgerung selbst - aber es kann doch nicht so schwer sein, den Test so zu gestalten, dass er diese Argumentation tatsächlich stützt...

Vielleicht hast DU ja ein aussagekräftiges Beispiel (ohne dass ich das negativ meine!).

[Shade Of Mine]

cubeman schrieb:

Kann ich aber daraus ableiten, dass das Deklarieren von Variablen im Schleifenkörper keine dramatischen Performanceeinbußen bringt? Ich denke ja.

Du könntest meinen Post lesen, der erklärt sehr schön wie es aussieht, weil dass was ihr hier an code gepostet habt ist zwar lustig, geht aber komplett am thema vorbei.

Das einzige worum es hier gehen sollte ist RVO bzw. NRVO. Denn die entscheidet welche variante schneller ist. Dazu muss man aber (N)RVO erstmal verstanden haben...

[cubeman]

Zunächst mal danke für das viele Feedback!
Ok, hab mir das hier durchgelesen.

Kann man also zusammenfassend sagen dass es

• es auf die Funktion ankommt, die ein Objekt liefert, und
• es zusätzlich Optimierungssache des Compilers ist?

Am besten ist es wohl, im konkreten Fall einfach zu messen...