Was ich bis jetzt gefunden habe war folgende Idee

unsigned __int64 i =0, Dif=0, iStart, iEnd;
	while(i<=5000000)
	{
		QueryPerformanceCounter((LARGE_INTEGER*)&iStart);
                   //Mache was
		QueryPerformanceCounter((LARGE_INTEGER*)&iEnd); 
		Dif += iEnd - iStart;

		i++;
	}

Aber geht es denn auch anders? Das Problem ist ja bei dieser Art, das auch alle Takte mitgezählt werden, die durch andere Prozesse verwendet werden. Ich frage nämlich, weil ich testhalber eine Multiplikation ausführe, und folgender Code soll angeblich 1200 Takte brauchen, was ich nich ganz glaube.

void m(unsigned long x,unsigned long y)
{
	__asm{
		mov eax, x
		mul y
	     }
}

Mfg Tobi

Und so wie du das machst wird es nix werden, du musst schon mehr als nur ein paar Takte zwischen den beiden zu QueryPerformanceCounter verbraten, sonst misst du bloss wie lange zu QueryPerformanceCounter selbst braucht.
QueryPerformanceCounter 2x direkt hintereinander auszuführen um rauszubekommen wie lange die "Nullzeit" ist funktioniert dabei leider nicht (ich hab's selbst schon ausprobiert, kommen Hausnummern dabei raus), also bleibt dir nix anderes übrig als einfach ein paar Millionen Loops über die entsprechende Funktion zu machen wenn du es so messen willst. Die beiden QueryPerformanceCounter Aufrufe müssen dabei dann natürlich VOR und NACH dem Loop stehen, nicht mitten drinnen.

Und du musst dann natürlich aufpassen dass die der Compiler nicht gleich den ganzen Loop wegoptimiert, bzw. nicht das was du eigentlich messen willst aus dem Loop rausoptimiert. Und beim "erzwingen" des "nicht optimierens" (wo z.B. gern "volatile" verwendet wird) musst du aufpassen dass das nicht übermässig viel Zeit beansprucht, denn das geht ja auch in die Messung mit ein.

Das einfachste ist es halt immer noch wenn man wirklich fertige Funktionen misst die reale Arbeit verrichten, also so aussehen wie man sie im fertigen Programm braucht, und natürlich die nicht sehr kurz sind. Dann kann man das "Wegoptimieren" auch einfach dadruch verhindern dass man das Ergebnis der Funktion am Ende ausgibt - also einfache alle Variablen danach ausgibt die die Funktion modifiziert (inklusive dem Returnwert).

Vtune wäre schon cool, aber auch ein Wenig zu teuer um damit solch simple Sachen anzustellen.

@Tobias1984: 180 ist immer noch viel zu viel, nen P4 oder Core 2 sollte dafür max. 15 Zyklen brauchen, soll sein 20 wenn alles schief geht (inklusive "call + ret" und dem ganzen). Und das auch nur wenn man den Wert von eax unmittelbar nach der Funktion "verbraucht", wenn man den erst später verwendet müsste es noch schneller gehen.

Hi, besten Dank Nun komme ich auf 180 Takte wenn ich außerhalb der Schleife QueryPerformanceCounter Aufrufe das mach ich 10Mio mal

Vtune wäre schon cool, aber auch ein Wenig zu teuer um damit solch simple Sachen anzustellen.

benutz AMD Code Analyst (ja funzt auch auf intel cpus). damit bekommst du weit bessere resultate als mit deinem versuch und das auch noch fuer alle funktionen und sogar auf assembler level.