QueryPerformanceCounter in C#

[dot]

Ich verstehe das anders. Für mich geht es darum auf welchem Prozessor der Thread läuft, und das ist nicht immer derselbe wenn man nichts dagegen tut.

Und wo genau liest du das da oben heraus?

[Niki]

Ich verstehe das anders. Für mich geht es darum auf welchem Prozessor der Thread läuft, und das ist nicht immer derselbe wenn man nichts dagegen tut.

Und wo genau liest du das da oben heraus?

Einfach deshalb weil ich sonst keinen Grund sehe warum die explizit "with each thread associated with a specific processor" schreiben sollten. Deshalb verstehe ich es so, dass nicht der Thread-Wechsel das Performance-Problem ist, sondern der Prozessorwechsel.

Aber es kommt schon öfter mal vor, dass ich Dinge anders verstehe als andere :D Wäre also nicht verwunderlich wenn ich falsch liege. Allerdings reden wir bei C# von Managed Threads, und nicht von OS Threads. Ich wüsste nicht mal, ob ein Managed Thread den OS Thread wechseln kann.

Aber wer auch immer nun recht hat, ich bin jedenfalls happy, dass mein Zeug da läuft. Und wenn's doch mal Probleme macht, dann ab in die Tonne. Ist ja nicht so, dass ich den ganzen Code dafür umschreiben muss :)

[dot]

Ich denk das steht da, da nur in diesem Fall die Timer auch tatsächlich parallel ausgelesen würden... ;)

[Niki]

Also, die einzige Info die ich beim Googeln finde ist: http://stackoverflow.com/questions/1723 ... -is-called

Der Poster ist aber auch nur ein Mensch. Also wer weiß schon was korrekt ist und was nicht.

Und nun wird's Zeit an meinem Editor weiter zu basteln. Ist ein bisserl mehr als nur Timing :D

[dot]

Also, die einzige Info die ich beim Googeln finde ist: http://stackoverflow.com/questions/1723 ... -is-called

Da steht doch nur wieder der gleiche Nonsense von wegen rdtsc. Einfacher Reality-Check: Wenn dem so wäre, müsste die von QueryPerformanceFrequency() zurückgegebene Frequenz ja wohl der Frequenz der CPU entsprechen. Ich habe noch nie ein System gesehen, wo das der Fall wäre; Überraschenderweise kommt da normalerweise etwas in der Gegend von 3MHz (APIC) oder 25 MHz (HPET) zurück... ;)

EDIT: Grad mal mit dem Debugger in QueryPerformanceCounter() reingestepped und was seh ich? rdtsc :shock: Liegt aber vermutlich nur daran, dass CPUs mittlerweile invariant TSC implementieren und mein Sandy Bridge Core i7 da wohl keine Ausnahme ist...

Auf jeden Fall

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

[Schrompf]

Ich kann hier nur kurz Erfahrungswerte einwerfen: RTDSC ist verlässlich auf allen Maschinen, die ich bisher gesehen habe. Mindestens 3 Millionen Takte pro Sekunde auf AMD-Hardware, Intel bietet üblicherweise Auflösungen auf Höhe der Nominal-Taktfrequenz - also 2 bis 4 Milliarden Takte pro Sekunde. Sieh zu, dass Du einen Datentyp benutzt, der mit solchen Auflösungen trotzdem noch Tage hinkommt, sonst ist all Dein Grübeln um veraltete BIOS-Bugs für den Arsch.

[Niki]

Ich benutze 64-Bit Integers, wie sie mir von der C# Stopwatch oder der WinAPI QueryPerformanceCounter gegeben werden. Für Berechnungen nehme ich 64-bit Integer Zeitdifferenzen, konvertiere die nach double und teile danach durch die Frequenz (auch nach double gecastet). Das muss gut genug sein.

[Blue Cobold]

Mit 15 korrekten Digits für Double sollte das eine Weile Laufzeit reichen, bis da ein Einschnitt in für Dich relevante Stellen erfolgt.
Angenommen Du brauchst es auf Mikrosekunden genau, dann ergäbe das etwa eine Laufzeit von mehreren Jahren, bis die Stellen zu ungebau werden.
Spannender numerisch gesehen ist eher die Frage, was Du mit den Zahlen dann anstellst. Differenzen ungünstig gewählter Zahlen führen ja bekanntlich bei Double schnell mal zu einer Zeitdifferenz von ... 0, bzw. ändert sich an der größeren Zahl bei der Differenz oder Summe nix. Da würde ich, wie Schrompf schon sagte, unbedingt ein Auge drauf haben, sonst ist die ganze Sache mit der hohen Zeit-Auflösung für die Katz.

[Krishty]

Er nimmt Integer-Differenzen, was für mich impliziert, dass er den letzten Zeitpunkt auch als Ganzzahl abspeichert und nur einzelne Frame-Zeiten als double rumreicht, nicht akkumulierte. Das dürfte völlig in Ordnung sein.

[Niki]

Ja, genau so wie Krishty sagt.

Die einzige Ausnahme die ich da mache ist, wenn ich Zeit für fixe Simulations-Zeitschritte akkumuliere.

[Schrompf]

Ja, das klingt gut. Solange alle Rechnungen mit int64 passieren und erst am Ende in double umgerechnet wird, sollte das alles ok sein. Ich hab mir damals einen int64 in eine kleine Klasse gekapselt und rechne seitdem recht entspannt damit. Nur ganz am Anfang hatte ich noch uint64 genommen, was sich aber bald als Fehler herausgestellt hat, weil man doch gelegentlich auch mal negative Zeitpunkte oder Zeitspannen bekommt.