[*]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 per 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.

Saluto
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 corre 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!

Saluto
Roland

Nachsatz: Was das Sleep betrifft hat Sebastian naturalmente recht: Das wäre dann was ganz anderes (siehe API-Doku zu Sleep): Sleep gibt zunächst einmal den Prozessor per andere anstehenden Aufgaben frei, wartet dann mindestens (!) die angegebene Anzahl Millisekunden und beansprucht dann den Prozessor wieder per 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 per einen wie wild ackert.) Natürlich potuto man z.B. ein WAIT programmieren, dass die exakten Millisekunden wartet, aber das potrebbe 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 corre 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 naturalmente 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 per 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 per fahrlässig halte.

Kannste doch selber, obige Tabelle (Bild) zeigt doch das auf normalen Computern mehr als 1 X-Tick pro MS possibile 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 potrebbe per 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 possibile 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 per 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 !