Coder Forum

Taschenrechner sollte kein Problem werden.
Aber eine Stopuhr die µs exakt erfassen kann auf einem PC, das wird nicht ganz so einfach.

Ich würde erst mal den Taschenrechner "bauen" und mich dann dann erst mit der Stopuhr beschäftigen.
Für die Stopuhr, da sollte man wissen wie die Hardware und das Betriebssystem ticken.

Aber fang an mit dem Quelltext, damit der Taschenrechner schon mal läuft.

MfG bcc-fan

Wieso sollte man wissen wie das System tickt?
Erste Eingabe => Start, letzte Eingabe => Stop & Ausgabe

Auf alten Rechnern geht es nicht 0,000001s auszuwerten.

Welche Funktion der MFC oder von C oder von C++ leistet das?
Ausserdem kann der Prozessor mit anderen Jobs beschäftigt sein, wenn ihr dem das nicht verbietet.
Okay, heute gibt es CPUs mit mehreren Kernen. Aber selbst die wollen richtig mit Code versorgt werden.

MfG bcc-fan

Zeit messen von Funktionsstart bis Ende und dann in variable speichern, danach ausgeben lassen.
Der Taschenrechner ist easy, wenn er simpel ist.

MfG
Check

Jetzt aber Butter bei die Fische:
Die das Rezept für die Stopuhr haben, können sicher die Funktion hier veröffentlichen

Der Beitragsersteller schrieb Microsekunden

Ich streite ja nicht ab, das das näherungsweise mit einer Sekunden- oder Centisekunden- Auflösung einfach geht

MgG bcc-fan

Wieso so schwer? Ein Beispiel:
Ein Funktionsaufruf dauerte 5,856 Millisekunden. Das mit Tausend mal genommen und er hat seine Mikrosekunden. Wenn er es "geschickt" macht, kann er bis auf 4 Nachkommastellen kommen.

MfG
Check

Ist das nicht mehr gültig: 1/1000 * 1000 =

Also eine ms*1000 =

Gehen wir von deinem Beispiel aus ein Funktionsaufruf 5,856ms -> ein halber Funktionsaufruf = 2.928ms
Wie viel Bits bei einem 1/2 Aufruf auch immer was machen.

Ausserdem wie bekommt die CPU ihre Daten? Auch die Laufzeiten vom Bediener zur CPU sollten bei einer Auflösung von einer µs eine Rolle spielen.

Schon mal im Taskmanager nachgesehen mit wie viel Jobs sich euer PC "gleichzeitig" beschäftigt? Nicht das der glaubt nach der Aufgabenstellung er kann noch locker etwas Anderes zwischendurch erledigen und muss seine Stacks neu sortieren.

Also bisher seh ich noch nix was eine Auflösung von kleiner als 1/100 s als praktikabel erscheinen lässt.

MfG bcc-fan

Man könnte sich einen Algorithmus im Bezug auf einen Online Server bauen.
Aber eine andere Idee fällt mir jetzt auch nicht ein.

MfG
Check

Viel viele Bilder/s stemmt eure Grafikkarte und Monitor?
Oder wie viel ms benötigt euer LCD-Monitor theoretisch für ein Bild?

Es gibt im PC auch noch andere Laufzeiten.

Solange ihr es also nicht Schaft das Gehirn ohne messbare Umwege im die CPU einzukoppeln liegen wir in Bereichen, die grösser als 10 ms liegen.

MfG bcc-fan

Was hat das denn damit zu tun? Es geht doch nur darum die Zeit für die Berechnung zu messen.

Solche Zeitmessungen auf ms genau sind überhaupt kein Problem. Selbst Contextswitches spielen da nicht wirklich ne Rolle, aktuelle Prozessoren brauchen für nen Kontextswitch niedrige einstellige µs Zeiten.

Ich mein ich hab schon mit 16-Bit Microcontrollern bei 8MHz Signale auf ms genau (und richtig!) gemessen. Klar die haben nicht den Overhead von "fetten" Betriebssystemen, dafür sind heutige Prozessoren aber auch mehrere tausendfach schneller.

Von ms war hier dummerweise nicht die Rede und da du MFC-Programme auch auf keinem Realtime-OS zum fliegen kriegst ist das ganze schon ein Problem. Mit GetTickCount() bekämst du zwar die Zeit in ms heraus aber genauer löst dir Windows das ohne weiteres nicht auf. Und da du kein Realtime-OS hast, kannst du nicht exakt sagen wann er die Aufgabe berechnet hat und wann er die Zeit stoppt. Da können quasi beliebig viele Dinge zwischen passieren. Und wenn du, so wie der OP es wollte, die Zeit in microsekunden misst sind auch taskswitches mit wenigen microsekunden ein Problem, denn das Ergebnis wird falsch und mann kann es auch ganz lassen in der Auflösung etwas anzugeben. Alternative: Man berechnet das Ergebnis 1000 mal und misst die Zeit und teilt das Ergebnis durch 1000...

P.S. Ich würde fast wetten dass du das bei den Microcontrollern mit Interrupts gemacht hast Das dumme ist, die Dinger sind für Echtzeit ausgelegt, moderne OS nicht. Auch auf einem Pentium II ist das abtasten von 16MHz kein Problem, wenn man ein Echtzeit-OS hat (ich habs mit einem "Geme" und QNX als OS mal gemacht - aber eben mit einer ISR)

Microcontroller haben teilweise speziell für solche Aufgaben zusätzliche Timer auf der Platine oder im Chip. Und du kannst da nahe an der Hardware alles auswerten.

Es soll auch einige spezielle Mainboards geben, mit zusätzlichen Timern für ähnliche Aufgaben. Die Dinger sind allerdings selten und auch da sollte ein Echtzeitbetriebssystem zum Einsatz kommen. QNX gab es mal vor ein paar Jahren als Demo auf der CD einer Computerzeitschrift. Keine Ahnung ob QNX aktuell noch als Demo verfügbar ist.

MfG bcc-fan

Ich hab nicht gesagt dass es Sinn macht zu versuchen das auf µs genau zu messen, ich hab nur gesagt, dass die Aussage, dass die Aussage, dass genauer als 10ms aufzulösen keinen Sinn macht/nicht funktioniert einfach falsch ist.

Und auch Windows unterbricht dein Programm nicht für beliebige Hintergrundtasks, wenn du die Priorität dementsprechend einstellst. Klar, die Laufzeit auf so einem System ist immer nicht deterministisch, aber dann muss man den Test halt öfter ausführen. Dann ist man zwar schon fast wieder bei 1000 mal ausführen, Ergebnis durch 1000 teilen, was eigentlich immer das Mittel der Wahl für sowas ist. Aber da hat man das Problem ja genauso, man hofft nur, dass es durch die Durchschnittsbildung vernachlässigbar wird.



Aber ich glaub diese Diskussion geht langsam ziemlich extrem am Thema vorbei

So genau, naja, nur auf speziellen Plattformen.

Das mit Visual Studio, nimm GCC oder Microsoft Visual Studio C++ 2010 Express.

MfG
Check

"Normal" oder immer noch in Mikrosekunden?

MfG
Check