2013-01-31 10 views
8

Ich habe einen C-Code geschrieben, den ich als MATLAB-Format anrufe, nachdem ich ihn mit MEX kompiliert habe. Im Innern des C-Code, messe ich die Zeit ein Teil der Berechnung mit dem folgenden Code:MATLABs Taktdiskrepanz von Tic-Toc & C

clock_t begin, end; 
double time_elapsed; 
begin = clock(); 
/* do stuff... */ 
end = clock(); 
time_elapsed = (double) ((double) (end - begin)/(double) CLOCKS_PER_SEC); 

verstrichene Zeit die Ausführungszeit in Sekunden sein sollte.

Ich gebe dann den Wert time_elapsed zu MATLAB (es wird ordnungsgemäß exportiert; ich überprüfte). Dann MATLAB-Seite rufe ich diese C-Funktion (nachdem ich es mit MEX kompilieren) und ich messen die Ausführungszeit mit tic und toc. Was sich als vollständige Absurdität herausstellt, ist, dass die Zeit, die ich mit Tic und Toc berechne, 0,0011s (Durchschnitt bei 500 Läufen, st. Dev. 1,4e-4) beträgt, während die Zeit, die vom C-Code zurückgegeben wird, 0,037s beträgt (durchschnittlich 500 Runs, St. Dev. 0.0016).

Hier kann man zwei sehr merkwürdige Tatsachen feststellen:

  1. Die Ausführungszeit für die gesamte Funktion ist niedriger als die Ausführungszeit für einen Teil des Codes. Daher sind entweder die Messungen von MATLAB oder C stark ungenau.
  2. Die im C-Code gemessenen Ausführungszeiten sind sehr verstreut und weisen sehr hohe st. Abweichung (Variationskoeffizient 44%, verglichen mit nur 13% für Tic-Toc).

Was ist mit diesen Timern los?

+0

Was ist die Auflösung der Uhr? Woher wissen wir, ob 'begin = clock();' kurz vor oder kurz nach dem Auftreten eines Clockticks ausgeführt wird? Beeinflusst das das Ergebnis? Wahrscheinlich. –

+0

@BoPersson Also meinst du, dass 'clock()' höchstens einen Tick verpassen kann? –

+4

Ich meine, dass ein Tick groß genug sein könnte, um das Ergebnis zu beeinflussen. Wie 18 ms. –

Antwort

6

Sie vergleichen Äpfel mit Orangen.

Blick auf Matlab Dokumentation:

tic-http://www.mathworks.com/help/matlab/ref/tic.html
toc - http://www.mathworks.com/help/matlab/ref/toc.html

tic und toc können Sie in Echt verstrichene Zeit messen.

Betrachten Sie jetzt die Uhr Funktion http://linux.die.net/man/3/clock.

Insbesondere

die Uhr() Funktion gibt eine Annäherung der Prozessorzeit von dem Programm verwendet.

Der zurückgegebene Wert ist die bisher verwendete CPU-Zeit als Clock_t; zu erhalten Sie die Anzahl der Sekunden, dividiert durch CLOCKS_PER_SEC. Wenn die verwendete Prozessorzeit nicht verfügbar ist oder ihr Wert nicht dargestellt werden kann, gibt die Funktion den Wert (clock_t) -1 zurück.

Also, was können Sie für Ihre Unterschied ausmachen:

  • CPU-Zeit (gemessen durch den Takt()) und Echt verstrichene Zeit (gemessen durch tic und toc) sind nicht das gleiche. Sie erwarten also, dass die CPU-Zeit geringer ist als die verstrichene Zeit? Vielleicht.Was, wenn Sie innerhalb von 0,0011s 10 Kerne bei 100% fahren? Das würde bedeuten, dass die Takt() -Messung 10x ist, die mit Tic und Toc gemessen wurde. Möglich, unwahrscheinlich.
  • Uhr (.) Ist grob ungenau, und im Einklang mit der Dokumentation, es ist ein ca. CPU-Zeitmessung! Ich vermute, dass es an die Scheduler-Quantengröße gebunden ist, aber ich habe den Linux-Kernel-Code nicht durchgecheckt, um das zu überprüfen. Ich habe auch andere Betriebssysteme nicht überprüft, aber this dude's blog stimmt mit dieser Theorie überein.

Also was zu tun ... für Anfänger vergleichen Äpfel mit Äpfeln! Stellen Sie als nächstes sicher, dass Sie die Timer-Auflösung berücksichtigen.

Verwandte Themen