Am Freitag, 10. September 2004 19:53 schrieb Martin Eisfeld:

Am Freitag, 10. September 2004 19:40 schrieb Friedrich W. H. Kossebau:

...

ich versuche gerade, etwas Delphi nach C unter Linux zu transportieren.

Zur Zeitmessung^WZeitschätzung wird unter Delphi auf den Zyklusticker des Pentium zugegriffen:

<code> var: Start,Now,SystemFrequency: Int64;

queryPerformanceFrequency( SystemFrequency ); queryPerformanceCounter(Start);

queryPerformanceCounter(Now); Time := (Now-Start)/ SystemFrequency)*1000; // in ms

</code>

queryPerformanceCounter() hat sein Pendant (im Falle eines Pentium) sicher in <code src="asm/msr.h"> #define rdtscll(val) \ __asm__ __volatile__("rdtsc" : "=A" (val))

</code> Aber queryPerformanceFrequency()? <code>grep "cpu MHz" /proc/cpuinfo</code> kann es ja wohl nicht sein. Kann da jemand einen Tip geben?

Wenn ich das richtig verstehe, willst du die Taktfrewuenz in MHz berechnen.

Nein, ich will möglichst genau (deswegen der CPU-Zyklus) die Dauer zwischen zwei Codestellen berechnen (das Multitasking und alle ISR zwischendurch mal ignorierend).

Folgender Code sollte es können:

include <stdio.h> #include <unistd.h>

#define rdtsc(X) asm volatile("rdtsc":"=A" (X))

int main(void) { long long start, stop, takte, speed;

            rdtsc(start);
            sleep(10);

sleep( 10 ) bedeutet leider nicht, daß er genau (auf die Millisekunde) 10 Sekunden schläft. Ich habe nicht nachgeschaut, aber sleep kommuniziert bestimmt mit dem Scheduler, und dessen Auflösung ist, uhm, war IIRC mal 10 ms, keine Ahnung, was der aktuell (Kernel 2.4/2.6) ist.

            rdtsc(stop);
            takte=stop-start;
            speed=takte/10000000;
            printf("Tasktgeschwindigkeit: %d MHz.\n",speed);

Näherungswert :)

Aber danke Friedrich

Am Samstag, 11. September 2004 18:44 schrieb Eric Schaefer:

Am Fr, den 10.09.2004 schrieb Friedrich W. H. Kossebau um 19:40:

...

queryPerformanceCounter(Start);

queryPerformanceCounter(Now);

[...]

...

Aber noch was anderes: Habe ich richtig gerechnet, daß Now-Start wohl bei normaler Nutzung auf einem Arbeitsplatzrechner niemals einen Fehler erzeugen kann? 2^63-1 / 2*10^9 (GHz) / 60 (sec) / 60 (min) / 24 (h) = 53375.99558365032 (Tage)?

Theoretisch ja.

Aber: QueryPerformanceCounter() ist Win32-API und deren Dokumentation sagt, daß es ab und zu bei SMP vorkommt, daß die Counter der vorhandenen CPUs nicht synchron laufen, obwohl sie es eigentlich sollten. Wenn Du für den Thread keine CPU-Affinität festgelegt hast, kannst Du also ein Problem bekommen.

Oha. Na gut, muß man halt bedenken.

Außerdem bin ich mir nicht zu 100% sicher, daß der Counter bei 0 losläuft.

Der Grund dafür würde mich dann aber interessieren. Immerhin hat keiner der Code-Beispiele, die ich im Netz fand, den Fall betrachtet, daß der Counter überläuft und zurücksetzt. Oder waren die alle unfähig?

Außerdem2: Die Auflösung des Counters ist nicht 1, d.h. Now-Start kann durchaus auch mal 0 sein.

? Quelle? Wieso nicht? Der muß doch nur im Takt hochzählen?

Eric p.s. Ist es eigentlich schlecht fürs Linux-Karma, wenn man solches Detailwissen offenbart?

Wie ist das jetzt gemeint?

Danke für die Hinweise

Gruß Friedrich

Am Samstag, 11. September 2004 20:39 schrieb Eric Schaefer:

Am Sa, den 11.09.2004 schrieb Friedrich W. H. Kossebau um 18:15:

...

...

Außerdem bin ich mir nicht zu 100% sicher, daß der Counter bei 0 losläuft.

Der Grund dafür würde mich dann aber interessieren. Immerhin hat keiner der Code-Beispiele, die ich im Netz fand, den Fall betrachtet, daß der Counter überläuft und zurücksetzt. Oder waren die alle unfähig?

Ist das eine Trickfrage? ;-) Wo ist definiert, daß der Counter beim Rechnerstart bei 0 losläuft?

Reine Vermutung von mir. Ich wüßte es auch gern genau.

...

...

Außerdem2: Die Auflösung des Counters ist nicht 1, d.h. Now-Start kann durchaus auch mal 0 sein.

? Quelle? Wieso nicht? Der muß doch nur im Takt hochzählen?

Theoretisch schon, aber QueryPerformanceCounter() liefert nur Werte mit einer Granularität > 1. Quelle: Empirisch ermittelt.

Wie genau ermittelt? Zwei 1-Zyklische Maschinenbefehle direkt hintereinander, die den Wert in jeweils ein anderes Register kopieren, und dann die Differenz gebildet? QueryPerformanceCounter() ist vielleicht so implementiert, daß es mehrere CPU-Zyklen braucht...

...

...

p.s. Ist es eigentlich schlecht fürs Linux-Karma, wenn man solches Detailwissen offenbart?

Wie ist das jetzt gemeint?

Sinkt mein Linux-Karma, wenn ich solch intimes Win32-API-Wissen offenbare?

Naja, steigt in meinen Augen eher, denn Du kannst vergleichen und hast trotzdem Deine Meinung ;)

Gruß Friedrich

Am Sonntag, 12. September 2004 14:04 schrieb Eric Schaefer:

On Sun, 2004-09-12 at 10:45, Friedrich W. H. Kossebau wrote:

...

...

Theoretisch schon, aber QueryPerformanceCounter() liefert nur Werte mit einer Granularität > 1. Quelle: Empirisch ermittelt.

Wie genau ermittelt? Zwei 1-Zyklische Maschinenbefehle direkt hintereinander, die den Wert in jeweils ein anderes Register kopieren, und dann die Differenz gebildet? QueryPerformanceCounter() ist vielleicht so implementiert, daß es mehrere CPU-Zyklen braucht...

Nein, das meinte ich nicht.

DWORD x,y; QueryPerformanceCounter(&x); DoSomething(); QueryPerformanceCounter(&y);

y-x kann dabei durchaus 0 sein. Es ist aber schon lange her, daß ich das getestet habe. D.h. es kann mittlerweile so sein, daß y-x immer >0 ist. In diesem Fall widerrufe ich und behaupte das Gegenteil ;-)

Mh, vielleicht war ja QueryPerformanceCounter() bogus implementiert, sprich, der Wert des Hochzählregisters nicht als mutual markiert und der Compiler hat die zweite Abfrage wegoptimiert ;) Hat jemand den Sourcecode? :P

...

Naja, steigt in meinen Augen eher, denn Du kannst vergleichen und hast trotzdem Deine Meinung ;)

Das war auch nicht so ganz ernst gemeint. Generell finde ich die API nicht so furchtbar schlecht, wie sie immer gemacht wird. Es ist auch eigentlich alles irgendwie dokumentiert, aber es ist häufig nicht ganz einfach die richtige Doku zu finden. Aber da geht es Linux ja auch nicht anders.

Um mal wieder OnT zu werden: Manchmal ist es ein echtes Problem zu einem Thema die Doku zu finden, da man einfach nicht weiß, daß gewisse Schnittstellen überhaupt vorhanden sind. Es müßte für Linux eine Dokumentation geben die nicht irgendwelche APIs dokumentiert (davon gibt es nun wirklich reichlich), sondern statt dessen Konzepte. So in der Art wie: "Wie messe ich möglichst genau, wieviel Zeit zwischen A und B vergangen ist?", "Was muß ich tun, damit mein Programm als Daemon laufen kann?". Vielfach findet man sowas in guten Büchern (APITUE), aber eben auch nicht immer alle Themen. Oft bekommt man auch nur ein Interface hingeklatscht, ohne weitere Erklärung, warum man das so und nicht anders machen muß und was evtl. der Unterschied zu anderen verbreiteten Interfaces ist (siehe man). Als Quickreferenz ist das je auch wirklich toll, aber daneben fehlt eben die Dokumentation des Konzeptes.

Dafür gibt es doch die HowTos, auch wenn ich zugebe, daß die nicht alles abdecken, viel zu oft veraltet oder lückenhaft sind. Vielleicht schafft es das Linux-Documentation-Project (http://www.tldp.org) ja, das irgendwann zu verändern.

Gruß Friedrich