const-Variablen aus Datei laden?

spl*t

nman schrieb:

Irgendwie verstehst Du nicht worum es geht, oder?
Du kannst noch soviele const-Objekte erstellen; solange die Dinger nicht compiletime-konstant sind, wird da einfach nichts so früh direkt berechnet.

Und was Deine letzte Idee bringen soll weiß der Kuckuck.

Doch doch, ich schrieb doch deutlich, dass ich weiß, dass es nichts bringen kann, von der Performance.
Die "Idee" war einfach die Umsetzung von SirLants Vorschlag. Ich wollte das Objekt const machen, und fragen, wie genau das geht, da es ja ein Singleton ist.
Und sei es nurnoch wegen const correctness.

Das Thema hat sich jetzt sowieso erledigt, denn ich habe meinen Speed, sobald ich _entweder_ Breite und Höhe auf den selben Wert setze (sehr merkwürdig, sagte ich auch bereits) _oder_ der Funktion als Parameter Breite und Höhe per Settings::instance().WIDTH bzw .HEIGHT übergebe, anstatt in der Funktion selbst darauf per Settings::instance().WIDTH bzw .HEIGHT zuzugreifen
Dabei meine ich Geschwindigkeitsunterschiede von ca. 100-fach für das gesamte Programm.
Erstaunlich, nicht? Bei Interesse kann ich die Funktion auch posten.

nman

spl@t schrieb:

Erstaunlich, nicht? Bei Interesse kann ich die Funktion auch posten.

Ja, bitte, würd ich mir gerne am Vormittag anschaun wenn ich Zeit habe; mittlerweile bin ich nicht mehr allzu aufnahmefähig...

spl*t

vector3 getPixelColor(const vector3& cam_pos, const vector3& cam_dir, const vector3& up_vector, const vector2& pixel, vector2& screensize) {
	const float INV_FAC = 1.0f / ( 2.0f * tan(Settings::instance().FOV * 3.14159265358/180.0f * 0.5f));
	vector3 screenpoint(cam_pos);
	screenpoint = screenpoint + cam_dir;
	vector3 horizontal_offset	= CrossProduct(cam_dir, up_vector);
	vector3 vertical_offset		= -up_vector;
	screenpoint = screenpoint + horizontal_offset	* (pixel.x - screensize.x * 0.5f) / (screensize.x * INV_FAC);
	screenpoint = screenpoint + vertical_offset		* (pixel.y - screensize.y * 0.5f) / (screensize.y * INV_FAC * (screensize.y/screensize.x));
	Ray ray(cam_pos, screenpoint, 0);
	if (Settings::instance().ANTIALIASING)
	{
		float x_offset = 0.5f / (screensize.x * INV_FAC);
		float y_offset = 0.5f / (screensize.y * INV_FAC * (screensize.y/screensize.x));
		horizontal_offset = horizontal_offset * x_offset;
		vertical_offset = vertical_offset * y_offset;
		Ray ray1(cam_pos, screenpoint + horizontal_offset, 0);
		Ray ray2(cam_pos, screenpoint - horizontal_offset, 0);
		Ray ray3(cam_pos, screenpoint + vertical_offset, 0);
		Ray ray4(cam_pos, screenpoint - vertical_offset, 0);
		Ray ray5(cam_pos, screenpoint + horizontal_offset + vertical_offset, 0);
		Ray ray6(cam_pos, screenpoint - horizontal_offset + vertical_offset, 0);
		Ray ray7(cam_pos, screenpoint + horizontal_offset - vertical_offset, 0);
		Ray ray8(cam_pos, screenpoint - horizontal_offset - vertical_offset, 0);
		return trace(ray, Settings::instance().DEPTH, Settings::instance().RADIOSITY) * 0.25f + 
			   (trace(ray1, Settings::instance().DEPTH, Settings::instance().RADIOSITY) + trace(ray2, Settings::instance().DEPTH, Settings::instance().RADIOSITY) + trace(ray3, Settings::instance().DEPTH, Settings::instance().RADIOSITY) + trace(ray4, Settings::instance().DEPTH, Settings::instance().RADIOSITY)) * 0.125 +
				(trace(ray5, Settings::instance().DEPTH, Settings::instance().RADIOSITY) + trace(ray6, Settings::instance().DEPTH, Settings::instance().RADIOSITY) + trace(ray7, Settings::instance().DEPTH, Settings::instance().RADIOSITY) + trace(ray8, Settings::instance().DEPTH, Settings::instance().RADIOSITY)) * 0.0625;
	}
	return trace(ray, Settings::instance().DEPTH, Settings::instance().RADIOSITY);
}

und Aufruf per:

vector3 color = getPixelColor(cam.pos_, cam.direct_, vector3(0.0f, 1.0f, 0.0f), vector2(x, y), vector2(Settings::instance().WIDTH, Settings::instance().HEIGHT));

ist ca. 100 mal schneller als wenn statt screensize.x Settings::instance().WIDTH und statt screensize.y Settings::instance().HEIGHT geschrieben wird und die Funktion 1nen Parameter weniger hat.
Bin übrigens auch nicht mehr so richtig bei der Sache
Oh, immerhin, ich seh grad, eine Division kann ich mir schenken indem ich INV_FAC zu FAC mache. Aber das ist jetzt irrelevant

otze

Jesus Christus! Da blickt ja kein Mensch mehr durch.

SirLant

nman schrieb:

dann wird der Präprozessor alle Vorkommnisse von foo stur durch 2 ersetzen und der Compiler garantiert danach kein gemeinsames Objekt für die einzelnen Integerliterale anlegen.

Wenn der Compiler garantiert diese _nicht_ zu einem zusammenzufassen, dann ist das was ich gesagt habe blödsinn.

nman

SirLant schrieb:

Wenn der Compiler garantiert diese _nicht_ zu einem zusammenzufassen, dann ist das was ich gesagt habe blödsinn.

Kennst Du einen Compiler der für Integer-Literale mit gleichem Wert ein gemeinsames konstantes Objekt anlegt?
Ich ehrlich gesagt nicht und ich glaub auch wirklich nicht dass das klug wäre; uU mal warten was die Profis dazu sagen.

spl*t

otze schrieb:

Jesus Christus! Da blickt ja kein Mensch mehr durch.

Aber wenn du dir den großen Block in der Mitte mit den langen Zeilen wegdenkst, ist es nun wirklich nich mehr viel. Und den kannst du dir ruhig wegdenken, weil dieser komische Performanceunterschied auch dann auftritt, wenn ich ANTIALIASING = false setze.
Dann ist es ja bloß noch ein bisschen Mathematik, aber auch nicht so schwer (das hat sich ein 10.-Klässler ausgedacht, der die letzte Mathearbeit verhauen hat...)

doppelmuffe

spl@t schrieb:

[...]der Funktion als Parameter Breite und Höhe per Settings::instance().WIDTH bzw .HEIGHT übergebe, anstatt in der Funktion selbst darauf per Settings::instance().WIDTH bzw .HEIGHT zuzugreifen
Dabei meine ich Geschwindigkeitsunterschiede von ca. 100-fach für das gesamte Programm.
Erstaunlich, nicht? Bei Interesse kann ich die Funktion auch posten.

Verstehe ich da was nicht? also, für mich ist das nicht erstaunlich, sondern schlüssig.
es sieht so aus, als würde bei der langsamen version Settings::instance() immer wieder aufgerufen. die liefert dann nen struct oder ne klasse zurück. und das mehrmals. und beim schnellen wird die funktion nur ein mal aufgerufen und die ergebnisse zwischengespeichert.
( oder hast du einen vergessen? )

ZuK

doppelmuffe schrieb:

es sieht so aus, als würde bei der langsamen version Settings::instance() immer wieder aufgerufen. die liefert dann nen struct oder ne klasse zurück. und das mehrmals. und beim schnellen wird die funktion nur ein mal aufgerufen und die ergebnisse zwischengespeichert.

oder auch gar nicht weil die werte schon zur compiletime bekannt sind.
K.

spl*t

ZuK schrieb:

doppelmuffe schrieb:

es sieht so aus, als würde bei der langsamen version Settings::instance() immer wieder aufgerufen. die liefert dann nen struct oder ne klasse zurück. und das mehrmals. und beim schnellen wird die funktion nur ein mal aufgerufen und die ergebnisse zwischengespeichert.

oder auch gar nicht weil die werte schon zur compiletime bekannt sind.
K.

Doppelmuffe hat schon recht, die Werte sind ja noch nicht bekannt, und wenn ich eins aus diesem Thread gelernt habe, dann, dass die Werte noch nicht bekannt sind

Aber:
1. : Die Funktion ist inline, und selbst der dümmste Compiler sollte sie inline machen, denn es ist nur ein return eines statischen Objektes.
2. : Die Funktion wird im Zusammenhang mit WIDTH und HEIGHT bei der langsameren Version 10 mal aufgerufen und bei der schnellen 2 mal. Rechtfertigt das einen 100fachen Geschwindigkeitsunterschied?
3. : Die Funktion wird sowieso noch knapp 20 mal aufgerufen. Ein Geschwindigkeitsunterschied der schnellen Version mit diesen Aufrufen zu früher, wo alles compiletimebekannte Konstanten waren, ist aber nicht / kaum zu spüren.
4. : Sind WIDTH und HEIGHT identisch, ist wie gesagt der Speed auch in der langsamen Version wieder da.

Also, doch nicht getroffen