Guten Tag,
ich suche für meinen Emulator die Möglichkeit, einen hoch auflösenden Timer (nach Möglichkeit Nanosekunden oder Millisekunden) zu haben, wenn Möglich Mono / POSIX kompatibel.
Das einzige was ich bis jetzt dazu gefunden habe ist die MicroLibrary, aber die frisst sehr viele Ressourcen. Da ich einen Emulator schreibe, sind Ressourcen alles, gerade in .net. Daher ist es auch wichtig, dass
ich Timing in so kleinen Intervallen hinkriege. Bisher habe ich immer 60 mal pro Sekunde so viel Code emuliert, dass genau ein Frame ausgeführt wird, ohne weitere Geschwindigkeitsregulierung. Da ich jetzt aber Sound emulieren möchte, ist das viel zu ungenau und führt zu merkbaren Störungen im Rhythmus. Wenn jemand nen anderen Ansatz hätte um einen Emulator effizient zu timen, dass ist dies auch gerne willkommen


MfG

Richtig angewendet dürftest du damit:

pinvoke.net/default.aspx/kernel32.gettickcount

eine doch relativ hohe präzision erreichen.

Hilft System.Diagnostics.Stopwatch?

@Flerovium Der Multimedia-Timer ist, so am PC vorhanden, die genaueste Zeitbasis des PC.
msdn.microsoft.com/en-us/libra…op/dd743609(v=vs.85).aspx
codeproject.com/Articles/5501/…mer-for-the-NET-Framework

Danke, für eure Antworten. Die Stopwatch Klasse scheint halbwegs gut zu funktionieren
Allerdings guck ich mir auch nochmal die anderen an, so kann ich gucken, was das beste Result erzielt.

MfG

nur dass die Stopwatch gar kein Timer ist...

Aber prima so verwendet werden kann

wie - als Timer?

Hast du mal ein Codebeispiel?
Also mittm WinForms-Timer gehts so:Wie sieht solch mitte Stopwatch aus?

Klar nicht so. Aber wie bei ner GameLoop, void in Thread auslagern, darin ne while-Schleife die solange iteriert bis Elapsed... == Interval.

... und dabei 100% CPu-Auslastung verursachen.

Mit einem Thread? Hast du nur 1 Kern?

Ich will sehen wie du über mehrere Kerne hinaus eine Anwendung machst, bei der die Threads auf selbe Daten zugreifen->Durch solche Aktionen wird das gesamte Programm nur langsamer.

Außerdem ist hier kein extra Thread nötig, da es sich um einen einfachen Aufruf und eine Subtraktion handelt, ich denke darauf wollte @Artentus hinaus...

Dann legste halt den Thread erst kurz schlafen und machst die letzten zwei Millisekunden mit BusyWaiting. Dann haste keine 100% auf einem Kern.

aber warum sollte man das tun? Das geht ja bereits direkt in der Render/Update Loop, dafür braucht man einfach keinen Thread, weil sowieso nichts schneller passieren kann als Update, denn bis dahin ist visuell nichts passiert und somit kann auch der Ton nicht an der falschen Stelle sein.

@jvbsl Kling so als hättest du meinen Post falsch verstanden. Ich meinte nicht, dass man mehrere Kerne verwenden sollte, sonder man mit nur einem Thread keine 100% CPU-Last hin bekommt. Es sei denn du hast noch Singlecore.

Hi
nicht, wenn jeder einzelne Core als eigene CPU aufgefasst wird.

Gruß
~blaze~

nafets schrieb:

Dann legste halt den Thread erst kurz schlafen und machst die letzten zwei Millisekunden mit BusyWaiting.

So hab ich das auch gelöst, allerdings kommt man damit auch nicht unter ein paar Millisekunden, Thread.Sleep hat halt die maximale Auflösung von 1ms. Für Spiele ist das absolut ausreichend, aber hier war ja nach Nanosekunden gefragt (was btw. ohne spezielle Hardware unmachbar sein sollte, ein Tick des System-Timers beträgt ja bereits 100 Nanosekunden und das ist die minimale Zeitspanne, für die ein HighResolutionTimer angefordert werden kann).

Flerovium schrieb:

nach Möglichkeit Nanosekunden

Artentus schrieb:

hier war ja nach Nanosekunden gefragt

Natürlich kann man zum definierten Warten den CPU-Takt ermitteln und eine Reihe von Befehlen ausführen, die eine definierte Dauer haben.
Beim Z80 war das NOP mit 4 CPU-Takten sehr beliebt. Einst.

Durch die Variabilität der CPU-Geschwindigkeit sollte das nicht mehr möglich sein. Scheduling dürfte einem auch nochmal einen Strich durch die Rechnung machen.

Viele Grüße
~blaze~

~blaze~ schrieb:

die Variabilität der CPU-Geschwindigkeit sollte das nicht mehr möglich sein.

Wenn sicher gestellt ist, dass die Ziel-Taktung in einem entsprechend engen Zeitfenster stattfindet, sollte das mit einer Kalibrierung pro Fenster machbar sein.