Unter Windows performant programmieren
-
Die Auflösung der periodischen Timer beträgt bei den meisten Windows Systemen ca. 15ms => ca. 66Hz. Versuch es mal mit CreateWaitableTimer()+SetWaitableTimer()+WaitForSingleObject(), wobei du den Timer nach jedem durchlauf neu setzt (lPeriod=0).
-
Du musst die Auflösung von Windows reduzieren. Das machst Du mit "timeBeginPeriod(1)".
-
Linux ist etwas besser darin, den Takt für zyklische Anwendungen selbst zu erzeugen. Die normalen Windows Timer sind da eher schlecht.
Anders sieht es aus, wenn ein System auf einen extern erzeugten Takt reagieren muss. Da ist Windows gar nicht so schlecht.
Hier einmal Beispiele für eine Antriebssteuerung mit 140 Hz, der Takt wird dabei von einem Rechner mit VxWorks Betriebssystem erzeugt, der über UDP die Bewegungsdaten von einem PC erhält.
Die machen es mit Linux
http://www.youtube.com/watch?v=Md8HTiGnQu4&list=UUww9UNr-4wYK-PH3by0tuyA&index=32&feature=plcp
und das hier ist Windows
http://www.youtube.com/watch?v=5x7EymmBl34&feature=context-chaWenn man unter Windows genauere Timer braucht, kann man sowas verwenden
http://www.kithara.de/
-
Hallo Leute!!
Vielen Dank für die Antworten, allerdings bin ich grad im Moment etwas überfordert! Ich kenne nur die Linux Welt und CreateWaitableTimer() und SetWaitableTimer() sind dem Anschein nach ms Systemaufrufe.
Wenn ich bisher Threads benötige verwende ich boost: http://www.boost.org/doc/libs/1_51_0/doc/html/thread.html
Ich denke mal boost übersetzt das in Systemaufrufe des Betriebssystems?
Die ms Systemaufrufe sind ja nicht plattformunabhängig.. Kann mir jemand sagen ob boost da schlechter ist?nwp3, dich würde es nicht wundern, aber woran liegt es?
"timeBeginPeriod(1)" hört sich ja sehr interessant an. Setzt das die Auflösung von allen Operationen herunter? Z.B. von Treiberangelegenheiten genau so wie Multithreading?
Im Prinzip sieht es bei uns genau so aus nn, unser Takt wird bisher von einer USB Kamera erzeugt: http://www.vrmagic.com/imaging/sdk/
Aber demnächst von einem anderen USB Sensor, dann aber mit 120Hz statt 60Hz. Also wir waren auf das Eintreffen von Daten und starten dann die Mutlithreading-Anwendung. Bis zum Start des nächsten Takts sollte alles abgearbeitet sein.
-
Hallo,
ich denke es nicht ganz einfach, so eine Anwendung zu realisieren, wenn man sich nicht etwas mit Windows auskennt. Das ist wie beim Wechsel auf eine andere Programmiersprache. Leute, die nur eine Seite kennen, machen oft den Fehler Annahmen über die neue Welt aus ihrem Wissen über die alte zu machen. Das führt dann nicht selten zu Aussagen der Form: "X ist anders als Y, also schlecht".
Eventuell solltest du erstmal deine Nase in ein Buch wie Jeffrey Richters "Windows via C/C++" stecken, dann weißt du besser, wie Windows auf dieser Ebene tickt ...
-
Wenn man sowas braucht, greift man zu einem Echtzeitbetriebssytem oder bastelt sich das mit einem eigenen Embedded System. Zum Thema: Bei Windows gab es bisher kein Problem Kamerabilder mit 60 Hz zu verarbeiten (USB 2.0 und Ethernet). Bei 120 Hz ... mal ausprobieren.
-
fabske schrieb:
Die ms Systemaufrufe sind ja nicht plattformunabhängig.. Kann mir jemand sagen ob boost da schlechter ist?
Was genau meinst du damit? Linux Systemaufrufe sind auch nicht plattformunabhängig. Es ist ja gerade der Sinn von Bibliotheken wie boost, eine Abstraktion zu bieten, die auf verschiedenen Plattformen funktioniert und diese dann unter der Haube eben in die jeweiligen, plattformspezifischen Systemaufrufe zu übersetzen...
-
dot schrieb:
fabske schrieb:
Die ms Systemaufrufe sind ja nicht plattformunabhängig.. Kann mir jemand sagen ob boost da schlechter ist?
Was genau meinst du damit? Linux Systemaufrufe sind auch nicht plattformunabhängig.
Er meint, dass die boost-Implementation unter Linux zu guten Ergebnissen führt, unter Windows aber nicht. Und dass es wohl nicht an der Unfähigkeit von Windows liegt, sondern an der schlechten Implementation der boost-Funktionen unter Windows.
fabske schrieb:
nwp3, dich würde es nicht wundern, aber woran liegt es?
Ich weiß es nicht genau, habe es aber ausprobiert. MinGW ist halt ein Bastard vom gcc. Und Microsoft versteht ein bisschen mehr von Windows als ein paar abtrünnige Linuxer.
Wenn ihr Visual Studio nicht mögt, solltet ihr zumindest den Compiler von Visual Studio verwenden, den kann man unabhängig von Visual Studio per Eclipse, Makefile oder was auch immer einbinden.
Außerdem solltet ihr erwägen den zeitkritischen Teil mit einem #ifdef _WIN32 nativ per WinAPI zu lösen.
-
nwp3 schrieb:
...
Er meint, dass die boost-Implementation unter Linux zu guten Ergebnissen führt, unter Windows aber nicht. Und dass es wohl nicht an der Unfähigkeit von Windows liegt, sondern an der schlechten Implementation der boost-Funktionen unter Windows....
Und Microsoft versteht ein bisschen mehr von Windows als ein paar abtrünnige Linuxer.
...Auf jeden Fall sollte man nochmal zwischen std::thread aus VS2012 und der boost-Variante vergleichen ...
fabske schrieb:
Also wir waren auf das Eintreffen von Daten und starten dann die Mutlithreading-Anwendung. Bis zum Start des nächsten Takts sollte alles abgearbeitet sein.
Dieser Satz bereitet mir auch etwas Unbehagen, sollte da etwa bei jedem Eintreffen von Daten ein Thread gestartet werden ? Da würde unter Windows eher ein Threadpool oder die Wiederverwendung existierender Threads zum Einsatz kommen.
-
Man koennte auch einfach einen Thread nehmen. Nur weil neue Arbeit auf meinem Schreibtisch landet, bekome ich keinen neuen Schreibtisch. Waere auch schoen bloed, den jedesmal neu einzuraeumen.
