Ich habe 4 Terme, die nur vom float t abhängen. Die sehen in etwa so aus:

float term1 = 3*t*t*t + 2*t+t - t;
float term2 = 6*t*t*t - 4*t*t*t ... usw.

Ich habe also mehrmals ein t^3, t^4 und t^2. Meine Frage: Wird der Code schneller, wenn ich die Funktion pow() benutze? Die sollte ja gut optimiert sein, aber durch die ganzen Funktionsaufrufe wird der Vorteil ja vllt wieder zerstört?
Oder wäre der Code schneller, wenn ich die t^3, t^4 einmal vorberechne und dann wiederverwende?
Also sowas: float f1 = t*t*t;
term1 = 3f1 + ...
term2 = 5f1 + ...

Was ist am schnellsten? Vorberechnung, pow() oder einfach die t*t*t lassen?

Oder wäre der Code schneller, wenn ich die t^3, t^4 einmal vorberechne und dann wiederverwende?

Genau das.
Wenn t konstant ist - sonst geht das ja wohl nicht.

Also t ist der einzige Parameter der Funktion, quasi: float foo(float t) { ... }

Einer hat vorgeschlagen, dass ich es mit einem Profiler testen soll. Leider kenne ich mich da überhaupt nicht aus. Kann mir jemand einen guten und einsteigerfreundlichen Profiler für C++ (ich benutze Visual Studio 05, falls das ne Rolle spielt) empfehlen?

Danke

Einer hat vorgeschlagen, dass ich es mit einem Profiler testen soll. Leider kenne ich mich da überhaupt nicht aus. Kann mir jemand einen guten und einsteigerfreundlichen Profiler für C++ (ich benutze Visual Studio 05, falls das ne Rolle spielt) empfehlen?

Wenn du einen AMD-Prozessor hast, ist AMD CodeAnalyst sehr zu empfehlen. Allerdings sind solche Mikrooptimierungen nicht immer ganz einfach zu profilen, ich würde mich da eher auf grössere Bottlenecks konzentrieren.

zeig mal den bisherigen code.

So sieht der Code aus:

D3DXVECTOR3 HermiteCurve::interpolate(float t) const { 
   assert(t>=0 && t<=1);

   float bf_1 = 2*t*t*t - 3*t*t + 1;  // blending function 1
   float bf_2 = -2*t*t*t + 3*t*t;
   float bf_3 = t*t*t - 2*t*t + t;
   float bf_4 = t*t*t - t*t;
   return bf_1 * p1 + bf_2 * p2 + bf_3 * r1 + bf_4 * r2;
}

Leider habe ich keinen AMD Prozessor, sondern einen Intel Core2Duo. Welchen Profiler nimmt man da am besten?

D3DXVECTOR3 HermiteCurve::interpolate(float t) const { 
   assert(t>=0 && t<=1);
   float t2=t*t;
   float t3=t*t*t;

   float bf_4 = t3 - t2; // t3 - t2
   float tmp_1 = bf_4 - t2; // t3 - 2*t2
   float bf_3 = tmp_1 + t; // t3 - 2*t2 + t;
   float tmp_2 = tmp_1 + t3 - t2; // 2*t3 - 3*t2;
   float bf_2 = -tmp_2; // -2*t*t*t + 3*t*t;
   float bf_1 = tmp_2 + 1; // 2*t*t*t - 3*t*t + 1 // blending function 1

   return bf_1 * p1 + bf_2 * p2 + bf_3 * r1 + bf_4 * r2;
}

aber keine ahnung, ob das schneller oder langsamer ist.

Leider habe ich keinen AMD Prozessor, sondern einen Intel Core2Duo. Welchen Profiler nimmt man da am besten?

Nur um Zeit zu messen, brauchst du keinen Profiler. Da reichen dir auch betriebssystemabhängige Funktionen. Leider kenne ich mich mit denen zu wenig aus, da ich bisher immer plattformunabhängige Implementierungen innerhalb von Bibliotheken (z.B. SFML) verwendet habe.

Aber wie gesagt: Mikrooptimierungen sind nicht einfach zu profilen. Die Unterschiede zwischen den Messungen sind oft recht klein und können auch von vielen anderen Faktoren abhängen, zum Beispiel wie ausgelastet der Prozessor gerade ist. Wenn du ein wenig von Assembler verstehst, könntest du dir auch das kompilierte Programm anschauen.

darf man mal fragen wie du ohne profiles drauf gekommen bist, dass es genau die interpolate funktion viel zeit in deinem programm braucht?

Seinen Ausgangspost habe ich jetzt eher als allgemeine Frage aufgefasst...

hinweis: nur auf release testen. debug gibt ganz andere ergebnisse

Wieso das? Hier könnte man wirklich ohne Probleme eine Schleife verwenden.

nochmal: 
// ...
goto nochmal;

Wieso das? Hier könnte man wirklich ohne Probleme eine Schleife verwenden.

Endlosschleife, ohne goto - sehr schön!

Endlosschleife, ohne goto - sehr schön!

Normalerweise hat die Schleife eine Abbruchbedingung.

Und ja, eine Endlosschleife ist immer noch besser als goto , da weiss man wenigstens, was passiert. Man hat einen separaten Block mit eigenem Gültigkeitsbereich und kann das Verhalten des Programms überblicken. Es gibt schon wenige berechtigte Anwendungsbereiche für goto , aber sicher nicht in Situationen, in denen eine Schleife nur Vorteile hat.

ist viel hübscher als goto und labels...

goto gehoert zur Sprache - und es bereichert sie**.**

Natürlich. Nebenbei gehören sowohl Casts von konstanten Klasseninstanzen zu Non-Const-Referenzen auf double -Arrays als auch Zeiger mit siebenfacher Indirektion ebenfalls zur Sprache. Ich hoffe, du siehst den Punkt.

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

using namespace std;

int main() {
LARGE_INTEGER start_ticks, ende_ticks, frequenz;

double tick_diff     = 0;
start_ticks.QuadPart = 0;
ende_ticks.QuadPart  = 0;

nochmal:

cin.get();

QueryPerformanceCounter(&start_ticks);
QueryPerformanceFrequency(&frequenz);

for (int i = 0; i < 80000000; ++i) {
// ... hier deinen code testen ob er lahm oder schnell ist ...
}

// ... Ende der Geschwindigkeits-Tests!

QueryPerformanceCounter(&ende_ticks);

tick_diff = ((double) ende_ticks.QuadPart - (double) start_ticks.QuadPart) / frequenz.QuadPart;
cout << tick_diff << endl;
goto nochmal;

hinweis: nur auf release testen. debug gibt ganz andere ergebnisse

Damit misst du schnell Mist.

Der "hier deinen code testen" Bereich muss nämlich so ausgelegt sein, dass der Compiler ihn nicht wegoptimieren kann (ein paar Berechnungen, deren Ergebnis dann nirgends verwendet wird, sind nämlich im Release ganz schnell einfach nichtmehr da). Und auch keine Optimierungen vornehmen, die unter realen Einsatzbedingungen nichtmehr möglich wären. Aber auch keine "nicht-wegoptimier" Hilfskonstrukte enthält, die zuviel Optimierungen verhindern, oder einfach selbst zuviel Overhead machen.

Profilen ist eben nicht so einfach wie klein Erna sich das vorstellt.

Zum "richtig" Profilen muss man das fertige Programm profilen. Oder zumindest ausreichend grosse Programmabschnitte. Und das geht oft nur vernünftig ... mit einem Profiler

Zum "richtig" Profilen muss man das fertige Programm profilen. Oder zumindest ausreichend grosse Programmabschnitte. Und das geht oft nur vernünftig ... mit einem Profiler

Und sag jetzt blos nicht alles andere wäre prem..opt..., sonst löscht dich volkard aus.

"for (;;)"

wird übernommen!

hustbaer schrieb:

Damit misst du schnell Mist.

Der "hier deinen code testen" Bereich muss nämlich so ausgelegt sein, dass der Compiler ihn nicht wegoptimieren kann (ein paar Berechnungen, deren Ergebnis dann nirgends verwendet wird, sind nämlich im Release ganz schnell einfach nichtmehr da). Und auch keine Optimierungen vornehmen, die unter realen Einsatzbedingungen nichtmehr möglich wären. Aber auch keine "nicht-wegoptimier" Hilfskonstrukte enthält, die zuviel Optimierungen verhindern, oder einfach selbst zuviel Overhead machen.

Profilen ist eben nicht so einfach wie klein Erna sich das vorstellt.

Zum "richtig" Profilen muss man das fertige Programm profilen. Oder zumindest ausreichend grosse Programmabschnitte. Und das geht oft nur vernünftig ... mit einem Profiler

naja das mag stimmen. Ich weiss nur nicht wie Compiler das wirklich "optimiert"

wenn ich die 3 hier teste

void strcpy1( char s1[], char s2[])
{
	int i;
	for( i = 0; s2[i] != '\0'; ++i)
		s1[i] = s2[i];
	s1[i] = '\0';
}

void strcpy2( char *s1, char *s2)
{
	for( ; *s2 != '\0'; ++s1, ++s2)
		*s1 = *s2;
	*s1 = '\0';
}

void strcpy3( char *s1, char *s2)
{
	while( (*s1++ = *s2++) != '\0' );
}

und dann noch ein normales strcpy testen. Ergebnis: strcpy1 geht bei mir am schnellsten. Warum optimiert der Compiler nicht so dass die anderen mindestens genauso schnell sind wie strcpy1 ? Vlt mag das auch von CPU abhängen. Man kann auch da gleich ganze Programmabschnitte in "hier deinen code testen" einfügen oder? Oder verschiedene Funktionen zusammenstellen, die ein Programm braucht, dann immer wieder in einer bestimmten Abfolge testen lassen. Die Abfolge wird durch die externe Datei bestimmt (heisst auf Deutsch ääh z.b. 3D-Weltdaten laden und die Funktionen für Vektoren, Perspektive usw berechnen werden in Geschwindigkeitstest gemessen.) - praktisch wie ein Benchmark, somit kann man sicherstellen, dass da nix optimiert wird, wenn unterschiedliche Weltdaten geladen werden. Aber gut ich gebe zu, ich habe so ein Profiler noch nie ausprobiert.