[*]Profan

Jörg
Sellmeyer

[...]

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

27.04.2009 ▲

RGH

... wobei mich der Thread daran erinnert, dass ich diese Funktionen für die Systemvariable &GetTickCount schon immer mal austtauschen wollte.
Und bevor ichs wieder vergesse, habe ich es jetzt gleich erledigt. In der nächsten XProfan-Version verbirgt sich hinter &GetTickCount die Api TimeGetTime.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

27.04.2009 ▲

Frank
Abbing

Ein alter Hut wurde mal wieder ausgegraben.

Roland: Geh einen Schritt weiter und schreibe auch Sleep um.

Frabbing, Beitrag=52083, Zeitpunkt=28.04.2009

Sebastian
König

Ein alter Hut wurde mal wieder ausgegraben.

Roland: Geh einen Schritt weiter und schreibe damit auch Sleep um.

Das wäre eine ganz schlechte Idee! Sleep mit Schleife, die die Zeit abfragt, wäre letztlich nur ein Busy Wait und läuft damit der Idee hinter Sleep entgegen...

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

Frabbing, Beitrag=52083, Zeitpunkt=28.04.2009

Ein alter Hut wurde mal wieder ausgegraben.

Genau, zeigt aber: Ein guter Hut zur falschen Zeit ist ähnlich relevant wie ein Schlechter zur Richtigen.

Verhält sich ein klein wenig vielleicht wie in der Heisenbergsche Unschärferelation beschrieben - aber da ist wohl eher Sebastian unser Crack .

iF, Beitrag=52085, Zeitpunkt=28.04.2009

RGH

Frabbing, Beitrag=52083, Zeitpunkt=28.04.2009

Ein alter Hut wurde mal wieder ausgegraben.

Genau, zeigt aber: Ein guter Hut zur falschen Zeit ist ähnlich relevant wie ein Schlechter zur Richtigen.

Verhält sich ein klein wenig vielleicht wie in der Heisenbergsche Unschärferelation beschrieben - aber da ist wohl eher Sebastian unser Crack .

Nun, in diesem Fall war es wohl ein alter Hut zur richtigen Zeit, denn ich hatte meine Delphi-IDE mit dem XProfan-Projekt offen und konnte den Austausch der API-Funktion erledigen, bevor ichs wieder vergesse!

Gruß
Roland

Nachsatz: Was das Sleep betrifft hat Sebastian natürlich recht: Das wäre dann was ganz anderes (siehe API-Doku zu Sleep): Sleep gibt zunächst einmal den Prozessor für andere anstehenden Aufgaben frei, wartet dann mindestens (!) die angegebene Anzahl Millisekunden und beansprucht dann den Prozessor wieder für das Programm. Selbst beim Parameter 0 wird zunächst der Prozessor freigegeben, allerdings nur um sich sofort wieder seiner Dienste zu versichern. (Mit einem Sleep 0 am rechten Platz kann man somit wirkungsvoll verhindern, dass sein Programm 100% Prozessorlast verursacht ohne es allzu heftig auszubremsen. Besonders bei größeren Rechen-Schleifen kann so etwas ein Segen sein, wenn man z.B. noch Surfen oder Spielen will, während der PC für einen wie wild ackert.) Natürlich könnte man z.B. ein WAIT programmieren, dass die exakten Millisekunden wartet, aber das dürfte dann den Prozessor nicht freigeben, um auf alle Fälle rechtzeitig weitermachen zu können, und würde eher zu solch unfreundlichen Programmen führen, die Windows ausbremsen. Und die will ja eigentlich keiner.

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Frank
Abbing

Sleep mit Schleife, die die Zeit abfragt, wäre letztlich nur ein Busy Wait und läuft damit der Idee hinter Sleep entgegen...

Ich dachte eher daran WaitForSingleObject mit einem Semaphorenobjekt in den Wartephasen (jeweils 1 ms) oder nur WaitForSingleObject mit dem entsprechenden Abbruchszeitraum zu verwenden. Kann natürlich sein, dass die API genauso ungenau arbeitet wie Sleep (habs noch nicht getestet), aber einen Versuch wäre es ja wert.
Mein Vorschlag zielte auf kleine Zeiträume von ein paar Millisekunden, niemand will das System für Sekunden oder länger lahmlegen. Die Idee, die hinter Sleep steckt, ist zwar gut, die Ausführung aber schlecht. Die heutigen Prozessoren arbeiten so schnell, dass ich eine Ungenauigkeit von 15-16 ms pro benutztem Sleep für fahrlässig halte.

Kannste doch selber, obige Tabelle (Bild) zeigt doch das auf normalen Computern mehr als 1 X-Tick pro MS möglich ist.

Also warum nicht einfach do{ case zeitAlle : break } - wäre doch MS-genau, ausser vlt. auf Uraltkrücken...

Frank
Abbing

Ja, ich hatte recht, wie das Beispiel zeigt:
Kompilieren Markieren Separieren

Declare text$,sema&
Def WaitForSingleObject(2)!kernel32,WaitForSingleObject
Def CreateSemaphore(4)!kernel32,CreateSemaphoreA
Def CloseHandle(1)!kernel32,CloseHandle
Def timeGetTime(0)!WINMM,timeGetTime
Def timeBeginPeriod(1)!WINMM,timeBeginPeriod
Def timeEndPeriod(1)!WINMM,timeEndPeriod
timeBeginPeriod(1)
text$=myxprofan
sema&=CreateSemaphore(0,1,1,Addr(text$))

WhileLoop 2000

    AddString Wert in ms: +Str$(timeGetTime())
    WaitForSingleObject(sema&,5)   5 ms

EndWhile

ListBox$(Counter,2)
timeEndPeriod(1)
CloseHandle(sema&)
End

Die Zeitmessung erfolgt (wie eingestellt) im 5 ms-Takt (kein sein, dass AddString schonmal eine ms verschluckt). Die CPU-Auslastung liegt bei Null. Das dürfte für Sleep ein genauerer Ersatz sein.

Verhält sich ein klein wenig vielleicht wie in der Heisenbergsche Unschärferelation beschrieben - aber da ist wohl eher Sebastian unser Crack .

Mag sein. Meine Lösung funktioniert dennoch.

Frank
Abbing

Kannste doch selber, obige Tabelle (Bild) zeigt doch das auf normalen Computern mehr als 1 X-Tick pro MS möglich ist.
Also warum nicht einfach do{ case zeitAlle : break } - wäre doch MS-genau, ausser vlt. auf Uraltkrücken...

Es geht ja darum, dass Sleep nicht millisekunden-genau arbeitet. Mit dem GetTick-Ersatz arbeite ich schon lange. Sogar mein Junior benutzt ihn für sein Woormy. Ich rede aber von Sleep.

Frabbing, Beitrag=52089, Zeitpunkt=28.04.2009

Mag sein. Meine Lösung funktioniert dennoch.

Nein aber das Wurmspiel !