Ich möchte unter Unix eine Zeitdifferenz berechnen. Diese soll allerdings in
Millisekunden angegeben werden. Eine Fkt., die die aktuelle Systemzeit in
Millisekunden ausgibt, habe ich aber nicht gefunden.
In der Ansi C time.h bekomme ich nur Sekunden zurück.
Gibt es da irgensdwelche Möglichkeiten?
Unter Windows gibt es die Fkt. GetTickCount(), die die Zeit in ms angibt
seit dem Starten des Prozesses. So etwas ähnliches suche ich.
Kann mir jemand sagen wie eine solche Fkt. unter UNIX heist ?
thx
Thomas
> Diese soll allerdings in Millisekunden angegeben werden
Evtl. gettimeofday()
--
"I'm working on it." <http://www.psyche.kn-bremen.de/>
clock()
CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
http://www.schellong.de http://www.schellong.com
http://home.t-online.de/home/schellong sche...@t-online.de
> Thomas Runge wrote:
>>
>> Hallo
>>
>> Ich möchte unter Unix eine Zeitdifferenz berechnen. Diese soll
>> allerdings in Millisekunden angegeben werden. Eine Fkt., die die
>> aktuelle Systemzeit in Millisekunden ausgibt, habe ich aber nicht
>> gefunden. In der Ansi C time.h bekomme ich nur Sekunden zurück. Gibt
>> es da irgensdwelche Möglichkeiten?
>>
>> Unter Windows gibt es die Fkt. GetTickCount(), die die Zeit in ms
>> angibt seit dem Starten des Prozesses. So etwas ähnliches suche ich.
>> Kann mir jemand sagen wie eine solche Fkt. unter UNIX heist ?
>
> clock()
> CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
Ja die Frage ist off-topic aber warum baust du Bugs für ihn auf?
clock() gibt doch "eine Näherung der vom Programm benuzten Prozessorzeit
zurück", was schon gar nichts mit der Uhrzeit zu tun hat, und was sogar
auch lediglich (clock_t)(-1) sein könnte.
--
Sheldon Simms / she...@semanticedge.com
Ich antworte jetzt nur, weil clock() OffTopic ist.
Michael Karcher
--
> [Microsoft wirbt:] "Ein offenes Betriebssystem kann schon mal mutieren."
Mutieren tun vor allem MS-proprietäre Dateiformate.
-- Frank Fürst in <8sv525$llg3f$1...@fu-berlin.de>
Was meinst Du, was die damit meinen?
Wenn clock() die Anzahl in Mikrosekunden liefert, ist die Auflösung
trotzdem meist nur 10 ms, das springt also in Schritten von 10000 us.
clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
von clock() vergangen ist.
Bei Messungen sollte das System ruhig sein, da sys+user-time addiert
werden.
> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> von clock() vergangen ist.
ISO-9899-1990 in 7.12.2.1:
| The clock function returns the implementation's best approximation
| to the processor time used by the program since the beginning of an
| implementation-defined era related only to the program invocation.
mfg, simon .... tja
Das entspricht genau dem, was ich sagte.
Nachtrag:
Die Beschreibungen sind meist ungenau und/oder mißverständlich.
Ich verwende clock() aber seit etwa 10 Jahren und weiß genau, wie sie
arbeitet.
clock() braucht einen ERSTEN START-AUFRUF!,
um den Mechanismus in Gang zu setzen.
Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
schon beliebig viel CPU-Zeit gebraucht hat.
Der Wert 0 ist bei diesem Start-Aufruf aber nicht garantiert, sodaß man
stets mit fortlaufenden Differenzen arbeiten sollte.
Wer die Prozeßzeit oft ausgeben will, sollte clock() am Anfang von
main()
aufrufen und den Zeitwert von dort später stets abziehen.
Zeit zwischen zwei Punkten:
Alle Aufrufe von clock() so: cT= clock()-cT; gestalten, wobei
cT vor erster Benutzung auf 0 gesetzt sein soll.
Oder mit cTa und cTb arbeiten.
Die man-Page hat stets Vorrang, da der Standard
"implementations-spezifisch"
nennt.
Ja, clock() <time.h> ist ANSI-C!
>>> Helmut Schellong <sche...@t-online.de> writes:
>>>
>>>> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
>>>> von clock() vergangen ist.
>>>
>>> ISO-9899-1990 in 7.12.2.1:
>>>
>>>| The clock function returns the implementation's best approximation
>>>| to the processor time used by the program since the beginning of an
>>>| implementation-defined era related only to the program invocation.
>> Das entspricht genau dem, was ich sagte.
Das tut es nicht.
> Die Beschreibungen sind meist ungenau und/oder mißverständlich.
Du meinst wohl deine Beschreibungen.
> clock() braucht einen ERSTEN START-AUFRUF!, um den Mechanismus in
> Gang zu setzen.
Um welchen Mechanismus in Gang zu setzen?
> Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
> schon beliebig viel CPU-Zeit gebraucht hat.
Da oben steht "related only to the program invocation", nichts von
irgendeinem vorherigen Aufruf von clock().
> Zeit zwischen zwei Punkten:
Errechnet man trivialerweise durch Differenzbildung, so what?
mfg, simon .... bah
> Ja, clock() <time.h> ist ANSI-C!
Nachdem wir wieder ontop sind sollten wir uns mal der Ursprungspost
zuwenden.
Es wurde schon oft (auch von mir) gefragt, wie man die Zeit in
_Millisekunden_ erhält. Bisher konnte(?) keiner eine Funktion nennen
die schneller als 55ms einen neuen Wert liefert.
Also bitte, wer auf die Frage eine befriedigende Antwort weiss...
Eine Auflösung von 1 ms *gibt es nicht* per ANSI.
Eine solche Auflösung gibt es sehr wahrscheinlich
überhaupt gar nicht per C-Lib.
Da muß man schon zu Assembler greifen, um den vom Core-Takt getriebenen
64-Bit-Counter des iPentium auszulesen, sofern die entsprechende
Instruktion
vom Kernel für User überhaupt erlaubt ist auszuführen.
Aber das ist OFFTOPIC.
Ursprungspost:
-------------------------------------------------------------------------
> Ich möchte unter Unix eine Zeitdifferenz berechnen. Diese soll allerdings in
> Millisekunden angegeben werden. Eine Fkt., die die aktuelle Systemzeit in
> Millisekunden ausgibt, habe ich aber nicht gefunden.
> In der Ansi C time.h bekomme ich nur Sekunden zurück.
> Gibt es da irgensdwelche Möglichkeiten?
>
> Unter Windows gibt es die Fkt. GetTickCount(), die die Zeit in ms angibt
> seit dem Starten des Prozesses. So etwas ähnliches suche ich.
> Kann mir jemand sagen wie eine solche Fkt. unter UNIX heist ?
clock()
CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
-------------------------------------------------------------------------
> > Eine Auflösung von 1 ms *gibt es nicht* per ANSI.
>
> Richtig. Insbesondere ist deine Antwort "clock()" auf die obige Frage
> einfach falsch gewesen, aber das haben ja schon andere geklaert.
Nein, meine Antwort auf das obenstehende Ursprungsposting war
total richtig.
clock() das ANSI-Pendant zur WinAPI-GetTickCount().
Beide liefern unter Windows die Zeit in Millisekunden.
clock() nach einem Startaufruf, GetTickCount() die Zeit seit
Windows-Start (also nicht wie oben angegeben).
Von einer Auflösung ist keine Rede.
Unter Unix liefert clock() die Zeit sogar oft in Mikrosekunden,
meistens mit einer Auflösung 10 ms oder besser.
Ein Interrupt alle 10 ms ist meist das genaueste, was man
bekommen kann, zumindest wenn CPU-Zeit eines Prozesses
gemessen wird. (sleep(n) suspendiert clock()!)
> > Eine solche Auflösung gibt es sehr wahrscheinlich
> > überhaupt gar nicht per C-Lib.
>
> Was meinst du mit "C-Lib"? Das es mit der Standardbibliothek nicht geht
> ist klar, da der Standard dafuer keine Funktion vorschreibt.
>
> Aber natuerlich gibts auf sehr vielen Systemen systemspezifische Funktionen
> mit denen man die Zeit in ms auslesen kann.
Aber ja, natürlich, jedoch nicht mit einer ebensolchen Auflösung.
> > Da muß man schon zu Assembler greifen, um den vom Core-Takt getriebenen
> > 64-Bit-Counter des iPentium auszulesen, sofern die entsprechende
> > Instruktion
> > vom Kernel für User überhaupt erlaubt ist auszuführen.
> > Aber das ist OFFTOPIC.
>
> Yep. Off-topic ists. Aber gearde bei den ueblicherweise auf Pentium
> eingesetzten Systemen braucht man nicht mit Assembler rumfurwerken,
> da gibts schon fertige C-Funktionen. Nur sind die halt nicht Standard.
> Auf vielen Systemen gibts auch gar keine RTC, da hilft dann auch kein
> Assembler. ;-)
Das hat mit RTC doch nix zu tun.
Die Instruktion rdtsc hat nur mit dem Prozessor zu tun.
Ich mußte übrigens den Kernel neu kompilieren mit Freischaltung
dieser Instruktion, damit HW-Programme diese Instruktion überhaupt
benutzen können. Die hat nämlich ein Enable-Bit in einem CR-Register.
# Nachtrag:
# Die Beschreibungen sind meist ungenau und/oder mißverständlich.
s/Die/Deine/
# Ich verwende clock() aber seit etwa 10 Jahren und weiß genau, wie sie
# arbeitet.
Anscheinend nicht. Oder Du begehst schon wieder einen riesengroßen
logischen Bock und schließt von Einzelereignissen auf die Allgemeinheit.
# clock() braucht einen ERSTEN START-AUFRUF!,
# um den Mechanismus in Gang zu setzen.
Kapitel und Vers im Standard bitte. WER SCHREIT HAT UNRECHT.
# Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
# schon beliebig viel CPU-Zeit gebraucht hat.
Ach ja?
$ cat tst.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main (int c, char **v)
{
long i, j = 1;
for (i = 0; i < strtol (v[1], NULL, 10); ++i) {
j *= 13; j %= 42; ++j;
}
printf ("%lu\n", (unsigned long)clock());
return 0;
}
$ ./a.out 10000
1
$ ./a.out 100000
8
$ ./a.out 1000000
93
$ ./a.out 10000000
1006
$ uname -sr
FreeBSD 4.2-RELEASE
Würde mich wundern, wenn es bei NetBSD, OpenBSD und BSDi anders wäre.
Der Standard erlaubt zwar 0 für den ersten Wert (was Solaris und HP-UX
auch nutzen), aber daraus "in der Regel" zu machen ist weit aus dem
Fenster gelehnt. Plumps.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Mit Hilfe des bekannten Core-Taktes.
1> ./a.out 10000000
2050000
1> uname -sr
Linux 2.4.9-ac5
Hmmm... was ist bei FreeBSD CLOCKS_PER_SEC?
> Der Standard erlaubt zwar 0 für den ersten Wert
"The C standard allows for arbitrary values at the start of the program"
aus "man 3 clock"
128
Erstens: Was heißt "program invocation" genau?
Aufruf des Programms oder Aufruf von clock() durch das Programm?
Zweitens: Warum steht folgendes im Standard:
--------------------------------------------------------------
250In order to measure the time spent in a program, the
clock function should be called at the start of the
program and its return value subtracted from the value
returned by subsequent calls.
--------------------------------------------------------------
wenn clock() -angeblich- die Zeit seit Programmstart liefert?
Drittens: Warum steht in fast allen Manuals
"... since the first call ..."?
Viertens: Warum sehe ich in allen Beispielen (sofern vorhanden)
stets mindestens zwei Aufrufe von clock()?
> # Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
> # schon beliebig viel CPU-Zeit gebraucht hat.
>
> Ach ja?
> [...]
> Würde mich wundern, wenn es bei NetBSD, OpenBSD und BSDi anders wäre.
> Der Standard erlaubt zwar 0 für den ersten Wert (was Solaris und HP-UX
> auch nutzen), aber daraus "in der Regel" zu machen ist weit aus dem
> Fenster gelehnt. Plumps.
Nix "Plumps.".
Warum unterschlägst Du, daß ich ausdrücklich geschrieben habe,
daß der Startwert 0 *nicht garantiert* ist?:
----------------------------------------------------------------------
> Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
> schon beliebig viel CPU-Zeit gebraucht hat.
> Der Wert 0 ist bei diesem Start-Aufruf aber nicht garantiert, sodaß man
> stets mit fortlaufenden Differenzen arbeiten sollte.
> [ Entsprechende Beispiele ]
----------------------------------------------------------------------
Hab kein Diplom in Standardinesisch, aber im zweiten Fall wäre es wohl
eher "function call" oder so.
> Zweitens: Warum steht folgendes im Standard:
> --------------------------------------------------------------
> 250In order to measure the time spent in a program, the
> clock function should be called at the start of the
> program and its return value subtracted from the value
> returned by subsequent calls.
> --------------------------------------------------------------
> wenn clock() -angeblich- die Zeit seit Programmstart liefert?
Es war die Rede von "era related only to the program invocation".
Ich sehe da einen Unterschied zur Zeit seit Programmstart, wie auch
immer Du diese definieren magst.
> Drittens: Warum steht in fast allen Manuals
> "... since the first call ..."?
> Viertens: Warum sehe ich in allen Beispielen (sofern vorhanden)
> stets mindestens zwei Aufrufe von clock()?
Weil den Leuten klar ist, daß "an era related only to the program
invocation" etwas anderes ist als der Start von main() und man deshalb
relativ messen muß.
Tschüs, Patrick
>> > Zeit zwischen zwei Punkten:
>
> Errechnet man trivialerweise durch Differenzbildung, so what?
nachdem dabei "arbitray values" der Ausgangspunkt sind, muß man immer mit
Überlauf rechnen. Wie formuliert Ihr das dann üblicherweise am
elegantesten?
Servus
Franz
Erstens: Der Standard-Text ist durchaus nicht glasklar.
Zweitens: Was ist für den *Standard* der 'Programmstart'?:
Enter in der Kommandozeile?
exec() in einem anderen Programm?
Beginn von main()?
Drittens: Wie lange braucht der Startcode (vor main) im Vergleich zur
Auflösung der clock()-Werte?!
"Erstens"(für Dich) ist wegen "Zweitens" und "Drittens". Eben weil der
Standard zu den beiden Punkten nichts sagt, wird eben festgelegt, daß
der Rückgabewert von clock() vom Programmstart abhängt, aber nicht, wie
groß er sein muß und ab wann genau gemessen wird. Könntest Du vielleicht
genauer sagen, was an dem Zitat aus dem Standard, das Simon gepostet
hat, unklar formuliert ist?
Tschüs, Patrick
1. Warum ist das bei FreeBSD 128?
2. Warum wird 1E6 verlangt?
Natürlich, ganz genau:
Der Standard-Text ist nämlich schlicht falsch, wenn er so
interpretiert wird, wie ihr das tut.
Es geht aus den letzten Postings GANZ KLAR hervor, daß der
erste clock()-Wert stets 0 sein darf und es in der Praxis
auch oft ist.
Wie soll diese 0 denn dann vom Programmstart anhängen?
Es ist ja hier stets der erste Wert 0, egal wie lange der
Programmstart zurückliegt.
Ganz einfach, weil es Plattformen gibt, wo erheblich genauer und
öfter die Zeitwerte sind bzw. geholt werden.
Da passt dann die Einheit [us] immer noch.
> Der Standard-Text ist nämlich schlicht falsch, wenn er so
> interpretiert wird, wie ihr das tut.
> Es ist ja hier stets der erste Wert 0, egal wie lange der
> Programmstart zurückliegt.
Ach ja. Wenn deine Implementation nicht das tut, was der Standard
sagt, sagt der Standard das falsche. Wie ist das Leben denn sonst
so in Schellongia?
mfg, simon
# Zweitens: Warum steht folgendes im Standard:
# --------------------------------------------------------------
# 250In order to measure the time spent in a program, the
# clock function should be called at the start of the
# program and its return value subtracted from the value
# returned by subsequent calls.
# --------------------------------------------------------------
Um die Portabilität zu sichern.
# wenn clock() -angeblich- die Zeit seit Programmstart liefert?
Ich habe nie behauptet, daß clock() *immer* die Zeit seit Programmstart
liefert. Ich habe behauptet und nachgewiesen, daß clock() auch beim
ersten Aufruf die Zeit seit Programmstart liefern *kann*, um Deine falsche
Behauptung, daß Du -angeblich- wüßtest, wie clock() funktionert (nämlich
in der Regel beim ersten Aufruf den Mechanismus in Gang zu setzen), nur
eine von mehrere Möglichkeiten ist, und schon gar nicht "die Regel".
# Drittens: Warum steht in fast allen Manuals
# "... since the first call ..."?
Wieviele sind denn "alle" bei Dir? Steht bei mir nicht mal in den
meisten (nur 3 von 10) von mir untersuchten Manuals...
FreeBSD: nein
NetBSD: nein
OpenBSD: nein
Darwin: nein
Linux: nein
Solaris: ja
HP-UX: ja
BSD Net2: nein
BSD Reno: nein
Ultrix: ja
Ich darf Dir jetzt mal exemplarisch vorführen, wie dieses Ergebnis
technisch korrekt quantitativ wiedergegeben werden sollte, also paß
gut auf:
"In 70% der 10 von mir untersuchten Manuals fand ich, daß clock()
die Zeit seit Programmstart zurückgibt. Bei den anderen 30%
gab clock() die Zeit seit dem ersten Aufruf (der 0 entspricht)
zurück. Die untersuchten Systeme entnehme man obiger Liste."
Das nennen ich harte, belegte Fakten. Es fiele mir schwer, diese Aussage
zu kritiseren :-)
# Viertens: Warum sehe ich in allen Beispielen (sofern vorhanden)
# stets mindestens zwei Aufrufe von clock()?
Weil sie portabel bleiben wollen und *keine* Annahmen über den Wert
des ersten clock() Resultats machen wollen.
#> # Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
#> # schon beliebig viel CPU-Zeit gebraucht hat.
#>
#> Ach ja?
#> [...]
#> Würde mich wundern, wenn es bei NetBSD, OpenBSD und BSDi anders wäre.
#> Der Standard erlaubt zwar 0 für den ersten Wert (was Solaris und HP-UX
#> auch nutzen), aber daraus "in der Regel" zu machen ist weit aus dem
#> Fenster gelehnt. Plumps.
#
# Nix "Plumps.".
Sehr wohl plumps.
# Warum unterschlägst Du, daß ich ausdrücklich geschrieben habe,
# daß der Startwert 0 *nicht garantiert* ist?:
Kannst Du lesen? Weil ich kritisiere, daß Du daraus "in aller Regel"
gemacht hast. Sei einfach vorsichtiger mit Verallgemeinerungen und
ich bin zufrieden. Aber ich werde weiterhin jede Schellongluftnummer
bzw unzulässige Schellongqualifizierung kritisieren, die aus
unzulässiger Verallgemeinerung resultiert.
Weil die RTC auf irq8 auch mit 128Hz läuft -> Keine Multiplikation
nötig -> paar Instruktionen gespart.
# 2. Warum wird 1E6 verlangt?
Das tun wohl nur SUSv2 und POSIX, wenn Konformanz zur optionalen XSI
Extension beansprucht wird. Im POSIX 200x Draft7 ist "CLOCKS_PER_SEC
equals 1000000" sonst nicht verlangt.
ObC: was folgt für den unterliegenden Typ von clock_t, wenn CLOCKS_PER_SEC
eine Million ist?
Wo steht eigentlich, daß 0 als erster Wert erlaubt ist? Finde das
irgendwie nicht. Oder steht das zwischen den Zeilen und ich interpretiere
das nur anders als HP und Sun?
Tschüs, Patrick
Es ist erlaubt, weil es nicht explizit verboten ist.
Kein Wert ist explizit verboten, also ...
Das sagt die Formulierung mit der "implementation-defined era related
only to the program invocation". Der erste Aufruf von clock() nach
Programmstart wäre eine solche era, da sie diese Bedingung erfüllt.
Ebenso erlaubt wären 100ms nach main(), 42min vor main(), siebter Aufruf
von rand(), etc. Allerdings muß die Implementation das so dokumentieren.
Es geht hier darum, daß unablässig behauptet wird, der Standard
sage aus, clock() würde immer und unbedingt die Zeit seit
Programmstart liefern.
Der Standard erlaubt, daß clock() initialisiert werden muß,
und genau so ist es auch oft in der Praxis.
Und deshalb sollte man auch stets entsprechend programmieren.
Das 0-Thema gibt es nur, weil es beweist, daß clock() eben
oft nicht die Zeit seit Programmstart liefert.
"programs invocation"?
> # Zweitens: Warum steht folgendes im Standard:
> # --------------------------------------------------------------
> # 250In order to measure the time spent in a program, the
> # clock function should be called at the start of the
> # program and its return value subtracted from the value
> # returned by subsequent calls.
> # --------------------------------------------------------------
>
> Um die Portabilität zu sichern.
Ja klar, eben weil der erste clock()-Wert beliebig sein darf
und eben nicht die Zeit seit Programmstart liefern muß.
> # wenn clock() -angeblich- die Zeit seit Programmstart liefert?
>
> Ich habe nie behauptet, daß clock() *immer* die Zeit seit Programmstart
> liefert.
Du nicht, aber beinahe alle anderen.
> Ich habe behauptet und nachgewiesen, daß clock() auch beim
> ersten Aufruf die Zeit seit Programmstart liefern *kann*, um Deine falsche
> Behauptung, daß Du -angeblich- wüßtest, wie clock() funktionert (nämlich
> in der Regel beim ersten Aufruf den Mechanismus in Gang zu setzen), nur
> eine von mehrere Möglichkeiten ist, und schon gar nicht "die Regel".
Man sollte aber so programmieren, als ob der Mechanismus stets durch
einen Startaufruf in Gang gesetzt werden müßte, weil genau das
tatsächlich oft der Fall ist.
Deshalb habe ich das auch geschrieben.
> # Viertens: Warum sehe ich in allen Beispielen (sofern vorhanden)
> # stets mindestens zwei Aufrufe von clock()?
>
> Weil sie portabel bleiben wollen und *keine* Annahmen über den Wert
> des ersten clock() Resultats machen wollen.
Eben. ...
> # Nix "Plumps.".
>
> Sehr wohl plumps.
Von mir aus "plumps", aber nicht "Plumps."
Moment. Das wäre doch "related to the 7th call of rand()", und das ist nicht
mehr "only to the program invocation". Ich hätte das "only" eben noch
strenger interpretiert und angenommen, daß damit auch eine Abhängigkeit
von anderen clock() Aufrufen ausgeschlossen ist, aber das sehen offensichtlich
einige Leute anders :-)
Tschüs, Patrick
Siehe <9n2eki$cll$1...@sunu789.rz.ruhr-uni-bochum.de> - man sieht mal wieder,
es gibt praktisch nichts, was man nicht auch noch anders interpretieren
kann...
Tschüs, Patrick
Ich kann mich nicht erinnern, daß das jemand behauptet hat, geschweige
denn "unablässig". Bitte belege dies ggfs mit einem Zitat.
#> Ich habe behauptet und nachgewiesen, daß clock() auch beim
#> ersten Aufruf die Zeit seit Programmstart liefern *kann*, um Deine falsche
#> Behauptung, daß Du -angeblich- wüßtest, wie clock() funktionert (nämlich
#> in der Regel beim ersten Aufruf den Mechanismus in Gang zu setzen), nur
#> eine von mehrere Möglichkeiten ist, und schon gar nicht "die Regel".
#
# Man sollte aber so programmieren, als ob der Mechanismus stets durch
# einen Startaufruf in Gang gesetzt werden müßte, weil genau das
# tatsächlich oft der Fall ist.
# Deshalb habe ich das auch geschrieben.
Dann schreib doch *genau das hin*! Ich gebe Dir ja recht, daß man wegen
der Portabilität Differenzen von clock() Aufrufen benutzen sollte. Da
gibt es gar keine Diskussion. Aber der Grund ist eben nicht, daß clock()
beim ersten Aufruf "in der Regel" 0 liefert oder ein "Mechanismus in
Gang gesetzt wird", sondern einen beliebigen Wert liefern *kann*.
Es ist der Unterschied zwischen Wissen über Implementationsdetails
und Wissen über Garantien des Standards. Wer sich lediglich auf
Letzteres verläßt, programmiert besser.
Doch, da der 7th call to rand() auch implizit "after the initial call to
main()" enthält und "related to" eine transitive Relation ist :-)
Zumindest lese ich den Abschnitt so. Aber wenn Du magst, frag mal in
news:comp.std.c nach.
Das wäre unlogisch... "related only to" ist es doch in dem Moment nicht
mehr, wo es zu irgendwas anderem "related" ist. Hm... dann werd ich da
mal fragen, der Haken ist bloß, daß ich dann da auch lesen sollte, oder?
Tschüs, Patrick
Ich sagte bereits, daß der Standard-Text und einige Manuals
aus meiner Sicht viel zu ungenau und mißverständlich beschreiben,
was jedoch u.a. mit "bäh" kommentiert wurde.
Erst die 250Fußnote macht die Sache klar.
Ich sagte bereits, daß der Standard-Text und einige Manuals
aus meiner Sicht viel zu ungenau und mißverständlich beschreiben,
was jedoch u.a. mit "bäh" kommentiert wurde.
Erst die 250Fußnote macht die Sache klar.
--
Ich bin der erste und einzige, der ausführlich beschrieben hat,
wie man clock() portabel und ansi-konform einsetzt.
Ich hatte sogar ganz zu Anfang schon den BSD-Wert '128' genannt.
Weiterer Tip: CLK_TCK gibt die Auflösung an.
---------------------------------------------------------------------
> Unter Windows gibt es die Fkt. GetTickCount(), die die Zeit in ms angibt
> seit dem Starten des Prozesses. So etwas ähnliches suche ich.
> Kann mir jemand sagen wie eine solche Fkt. unter UNIX heist ?
clock()
CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
---------------------------------------------------------------------
> > clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> > von clock() vergangen ist.
>
> ISO-9899-1990 in 7.12.2.1:
>
> | The clock function returns the implementation's best approximation
> | to the processor time used by the program since the beginning of an
> | implementation-defined era related only to the program invocation.
>
> mfg, simon .... tja
---------------------------------------------------------------------
clock() braucht einen ERSTEN START-AUFRUF!,
um den Mechanismus in Gang zu setzen.
Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
schon beliebig viel CPU-Zeit gebraucht hat.
Der Wert 0 ist bei diesem Start-Aufruf aber nicht garantiert, sodaß man
stets mit fortlaufenden Differenzen arbeiten sollte.
Wer die Prozeßzeit oft ausgeben will, sollte clock() am Anfang von
main()
aufrufen und den Zeitwert von dort später stets abziehen.
Zeit zwischen zwei Punkten:
Alle Aufrufe von clock() so: cT= clock()-cT; gestalten, wobei
cT vor erster Benutzung auf 0 gesetzt sein soll.
Oder mit cTa und cTb arbeiten.
Die man-Page hat stets Vorrang, da der Standard
"implementations-spezifisch"
nennt.
Ja, clock() <time.h> ist ANSI-C!
---------------------------------------------------------------------
Schlag bessere Formulierungen vor, vielleicht kannst Du Dich ja damit
durchsetzen. Nur mäkeln ist Bandbreitenverschwendung - genau wie mäkeln
über mäkeln :-)
Tschüs, Patrick
-----------------------------------------------------------------
Helmut Schellong <sche...@t-online.de> writes:
> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> von clock() vergangen ist.
ISO-9899-1990 in 7.12.2.1:
| The clock function returns the implementation's best approximation
| to the processor time used by the program since the beginning of an
| implementation-defined era related only to the program invocation.
mfg, simon .... tja
-----------------------------------------------------------------
Helmut Schellong <sche...@t-online.de> writes:
>>> Helmut Schellong <sche...@t-online.de> writes:
>>>
>>>> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
>>>> von clock() vergangen ist.
>>>
>>> ISO-9899-1990 in 7.12.2.1:
>>>
>>>| The clock function returns the implementation's best approximation
>>>| to the processor time used by the program since the beginning of an
>>>| implementation-defined era related only to the program invocation.
>> Das entspricht genau dem, was ich sagte.
Das tut es nicht.
> Dabei liefert sie in aller Regel 0, auch wenn der Prozeß *bis dahin*
> schon beliebig viel CPU-Zeit gebraucht hat.
Da oben steht "related only to the program invocation", nichts von
irgendeinem vorherigen Aufruf von clock().
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
mfg, simon .... bah
-----------------------------------------------------------------
"Erstens"(für Dich) ist wegen "Zweitens" und "Drittens". Eben weil der
Standard zu den beiden Punkten nichts sagt, wird eben festgelegt, daß
der Rückgabewert von clock() vom Programmstart abhängt, aber nicht, wie
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
groß er sein muß und ab wann genau gemessen wird. Könntest Du vielleicht
^^^^^^^^^^^^^^^^^^^^^^^^^^^
genauer sagen, was an dem Zitat aus dem Standard, das Simon gepostet
hat, unklar formuliert ist?
Tschüs, Patrick
-----------------------------------------------------------------
> Der Standard-Text ist nämlich schlicht falsch, wenn er so
> interpretiert wird, wie ihr das tut.
> Es ist ja hier stets der erste Wert 0, egal wie lange der
> Programmstart zurückliegt.
Ach ja. Wenn deine Implementation nicht das tut, was der Standard
sagt, sagt der Standard das falsche. Wie ist das Leben denn sonst
so in Schellongia?
mfg, simon
-----------------------------------------------------------------
Wo steht eigentlich, daß 0 als erster Wert erlaubt ist? Finde das
irgendwie nicht. Oder steht das zwischen den Zeilen und ich
interpretiere
das nur anders als HP und Sun?
Tschüs, Patrick
-----------------------------------------------------------------
Siehe anderes Posting.
> #> Ich habe behauptet und nachgewiesen, daß clock() auch beim
> #> ersten Aufruf die Zeit seit Programmstart liefern *kann*, um Deine falsche
> #> Behauptung, daß Du -angeblich- wüßtest, wie clock() funktionert (nämlich
> #> in der Regel beim ersten Aufruf den Mechanismus in Gang zu setzen), nur
> #> eine von mehrere Möglichkeiten ist, und schon gar nicht "die Regel".
> #
> # Man sollte aber so programmieren, als ob der Mechanismus stets durch
> # einen Startaufruf in Gang gesetzt werden müßte, weil genau das
> # tatsächlich oft der Fall ist.
> # Deshalb habe ich das auch geschrieben.
>
> Dann schreib doch *genau das hin*! Ich gebe Dir ja recht, daß man wegen
> der Portabilität Differenzen von clock() Aufrufen benutzen sollte. Da
> gibt es gar keine Diskussion. Aber der Grund ist eben nicht, daß clock()
> beim ersten Aufruf "in der Regel" 0 liefert oder ein "Mechanismus in
> Gang gesetzt wird", sondern einen beliebigen Wert liefern *kann*.
> Es ist der Unterschied zwischen Wissen über Implementationsdetails
> und Wissen über Garantien des Standards. Wer sich lediglich auf
> Letzteres verläßt, programmiert besser.
Mein erklärendes Posting, wo ich genau solche portablen Beispiele
brachte, wurde ja zerrissen und angezweifelt. Und zwar nicht wegen
"in der Regel" oder so, sondern grundlegend.
Siehe anderes Posting.