Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ausführungszeit messen

4 views
Skip to first unread message

Thomas Runge

unread,
Aug 30, 2001, 3:28:03 PM8/30/01
to
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 ?

thx
Thomas


Joerg Plate

unread,
Aug 30, 2001, 4:05:54 PM8/30/01
to

> Ich möchte unter Unix eine Zeitdifferenz berechnen
Es gibt de.comp.os.unix.programming...

> Diese soll allerdings in Millisekunden angegeben werden

Evtl. gettimeofday()

--
"I'm working on it." <http://www.psyche.kn-bremen.de/>

Helmut Schellong

unread,
Aug 30, 2001, 4:19:54 PM8/30/01
to

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

Sheldon Simms

unread,
Aug 31, 2001, 6:42:03 AM8/31/01
to
Im Artikel <3B8E9FEA...@t-online.de> schrieb "Helmut 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

Helmut Schellong

unread,
Aug 31, 2001, 6:50:06 AM8/31/01
to

Ich antworte jetzt nur, weil clock() OffTopic ist.

Michael Karcher

unread,
Sep 1, 2001, 7:55:28 AM9/1/01
to
Helmut Schellong <sche...@t-online.de> wrote:
> clock()
> CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
In meiner man-page zu clock(3) steht aber, dass clock() eine Näherung
der verbrauchten Prozessorzeit zurückliefert, und nicht die seit
Programmstart vergangenen Millisekunden oder sonstige Zeiteinheiten.
Das ganze ist als "CONFORMING TO: ANSI" gekennzeichnet...

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>

Helmut Schellong

unread,
Sep 1, 2001, 10:41:32 PM9/1/01
to
Michael Karcher wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote:
> > clock()
> > CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
> In meiner man-page zu clock(3) steht aber, dass clock() eine Näherung
> der verbrauchten Prozessorzeit zurückliefert, und nicht die seit
> Programmstart vergangenen Millisekunden oder sonstige Zeiteinheiten.
> Das ganze ist als "CONFORMING TO: ANSI" gekennzeichnet...

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.

Simon Krahnke

unread,
Sep 2, 2001, 12:29:42 AM9/2/01
to
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

unread,
Sep 2, 2001, 3:52:38 AM9/2/01
to

Das entspricht genau dem, was ich sagte.

Helmut Schellong

unread,
Sep 2, 2001, 5:01:19 AM9/2/01
to
Helmut Schellong wrote:
>
> Simon Krahnke wrote:
> >
> > 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
>
> 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!

Simon Krahnke

unread,
Sep 2, 2001, 2:13:39 PM9/2/01
to
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.

> 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

Michael Sonnthal

unread,
Sep 2, 2001, 2:44:56 PM9/2/01
to

Helmut Schellong <sche...@t-online.de> schrieb in im Newsbeitrag:
3B91F55F...@t-online.de...

> 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...

Helmut Schellong

unread,
Sep 2, 2001, 2:53:16 PM9/2/01
to

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.

Helmut Schellong

unread,
Sep 2, 2001, 6:41:45 PM9/2/01
to
kre...@flinux.tu-graz.ac.at wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote:
> >> > 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...

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.

Jens Schweikhardt

unread,
Sep 3, 2001, 7:43:44 AM9/3/01
to
Helmut Schellong <sche...@t-online.de> wrote
in <3B91F55F...@t-online.de>:
...
#> > 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.

Nein, der Widerspruch mit dem zitierten Absatz des Standards ist doch klar.

# 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)

Helmut Schellong

unread,
Sep 3, 2001, 5:00:38 AM9/3/01
to
kre...@flinux.tu-graz.ac.at wrote:
>
> Aeh, wie willst du ohne RTC (real time clock) die Zeit messen?

Mit Hilfe des bekannten Core-Taktes.

Joerg Plate

unread,
Sep 3, 2001, 8:32:01 AM9/3/01
to
> $ ./a.out 10000000
> 1006
> $ uname -sr
> FreeBSD 4.2-RELEASE

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"

Helmut Schellong

unread,
Sep 3, 2001, 9:21:28 AM9/3/01
to
Joerg Plate wrote:
>
> > $ ./a.out 10000000
> > 1006
> > $ uname -sr
> > FreeBSD 4.2-RELEASE
>
> 1> ./a.out 10000000
> 2050000
> 1> uname -sr
> Linux 2.4.9-ac5
>
> Hmmm... was ist bei FreeBSD CLOCKS_PER_SEC?

128

Helmut Schellong

unread,
Sep 3, 2001, 8:27:34 AM9/3/01
to
Jens Schweikhardt wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote
> in <3B91F55F...@t-online.de>:
> ...
> #> > 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.
>
> Nein, der Widerspruch mit dem zitierten Absatz des Standards ist doch klar.

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 ]
----------------------------------------------------------------------

Patrick Kursawe

unread,
Sep 3, 2001, 10:10:34 AM9/3/01
to
Helmut Schellong <sche...@t-online.de> schrieb:

> Erstens: Was heißt "program invocation" genau?
> Aufruf des Programms oder Aufruf von clock() durch das Programm?

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

Franz Iberl

unread,
Sep 3, 2001, 10:19:42 AM9/3/01
to
Hallo,

>> > 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

Helmut Schellong

unread,
Sep 3, 2001, 11:39:17 AM9/3/01
to

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?!

Patrick Kursawe

unread,
Sep 3, 2001, 12:15:25 PM9/3/01
to
Helmut Schellong <sche...@t-online.de> schrieb:

> 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

Jens Schweikhardt

unread,
Sep 3, 2001, 12:35:45 PM9/3/01
to
Joerg Plate <Pl...@psyche.kn-bremen.de> wrote
in <87n14cv...@psyche.kn-bremen.de>:
#
#> $ ./a.out 10000000
#> 1006
#> $ uname -sr
#> FreeBSD 4.2-RELEASE
#
# 1> ./a.out 10000000
# 2050000
# 1> uname -sr
# Linux 2.4.9-ac5
#
# Hmmm... was ist bei FreeBSD CLOCKS_PER_SEC?

128.

Joerg Plate

unread,
Sep 3, 2001, 2:30:20 PM9/3/01
to
> # Hmmm... was ist bei FreeBSD CLOCKS_PER_SEC?
"POSIX requires that CLOCKS_PER_SEC equals 1000000"

1. Warum ist das bei FreeBSD 128?
2. Warum wird 1E6 verlangt?

Helmut Schellong

unread,
Sep 3, 2001, 1:41:38 PM9/3/01
to

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.

Helmut Schellong

unread,
Sep 3, 2001, 4:00:37 PM9/3/01
to
Joerg Plate wrote:
>
> > # Hmmm... was ist bei FreeBSD CLOCKS_PER_SEC?
> "POSIX requires that CLOCKS_PER_SEC equals 1000000"
>
> 1. Warum ist das bei FreeBSD 128?
> 2. Warum wird 1E6 verlangt?

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.

Simon Krahnke

unread,
Sep 3, 2001, 10:23:41 PM9/3/01
to
Helmut Schellong <sche...@t-online.de> writes:

> 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

Jens Schweikhardt

unread,
Sep 4, 2001, 2:55:40 AM9/4/01
to
Helmut Schellong <sche...@t-online.de> wrote
in <3B937736...@t-online.de>:
...
# Erstens: Was heißt "program invocation" genau?
# Aufruf des Programms oder Aufruf von clock() durch das Programm?

Erster Aufruf von main(). Aufruf von clock() wäre Aufruf von clock().

# 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.

Jens Schweikhardt

unread,
Sep 4, 2001, 3:54:37 AM9/4/01
to
Joerg Plate <Pl...@psyche.kn-bremen.de> wrote
in <87u1ykt...@psyche.kn-bremen.de>:
#
#> # Hmmm... was ist bei FreeBSD CLOCKS_PER_SEC?
# "POSIX requires that CLOCKS_PER_SEC equals 1000000"
#
# 1. Warum ist das bei FreeBSD 128?

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?

Patrick Kursawe

unread,
Sep 4, 2001, 4:26:41 AM9/4/01
to
Jens Schweikhardt <use...@schweikhardt.net> schrieb:

> 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.

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

Helmut Schellong

unread,
Sep 4, 2001, 5:06:51 AM9/4/01
to

Es ist erlaubt, weil es nicht explizit verboten ist.
Kein Wert ist explizit verboten, also ...

Jens Schweikhardt

unread,
Sep 4, 2001, 5:40:52 AM9/4/01
to
Patrick Kursawe <Patrick...@ruhr-uni-bochum.de> wrote
in <9n2381$53h$1...@sunu789.rz.ruhr-uni-bochum.de>:
#
# Jens Schweikhardt <use...@schweikhardt.net> schrieb:

#> 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.
#
# 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?

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.

Helmut Schellong

unread,
Sep 4, 2001, 4:57:54 AM9/4/01
to
kre...@flinux.tu-graz.ac.at wrote:

>
> Helmut Schellong <sche...@t-online.de> wrote:
> >> Helmut Schellong <sche...@t-online.de> schrieb:
>
> > 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.
>
> Klar. Das geht auch aus dem Standard klar hervor. Der Standard sagt aber
> nicht, so wie du es zu interpretieren scheinst, das man clock irgendwie
> initialisieren muesste, er sagt lediglich dass der Startwert zu
> Programmbeginn irgendeiner sein kann.

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.

Helmut Schellong

unread,
Sep 4, 2001, 4:59:51 AM9/4/01
to
Jens Schweikhardt wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote
> in <3B937736...@t-online.de>:
> ...
> # Erstens: Was heißt "program invocation" genau?
> # Aufruf des Programms oder Aufruf von clock() durch das Programm?
>
> Erster Aufruf von main(). Aufruf von clock() wäre Aufruf von clock().

"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."

Patrick Kursawe

unread,
Sep 4, 2001, 7:41:06 AM9/4/01
to
Jens Schweikhardt <use...@schweikhardt.net> schrieb:

> 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.

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

Patrick Kursawe

unread,
Sep 4, 2001, 7:42:46 AM9/4/01
to
Helmut Schellong <sche...@t-online.de> schrieb:

> Patrick Kursawe wrote:
>>
>> Jens Schweikhardt <use...@schweikhardt.net> schrieb:
>> > 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.
>>
>> 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?
>
> Es ist erlaubt, weil es nicht explizit verboten ist.
> Kein Wert ist explizit verboten, also ...

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

Jens Schweikhardt

unread,
Sep 4, 2001, 8:18:20 AM9/4/01
to
Helmut Schellong <sche...@t-online.de> wrote
in <3B949792...@t-online.de>:
...
# Es geht hier darum, daß unablässig behauptet wird, der Standard
# sage aus, clock() würde immer und unbedingt die Zeit seit
# Programmstart liefern.

Ich kann mich nicht erinnern, daß das jemand behauptet hat, geschweige
denn "unablässig". Bitte belege dies ggfs mit einem Zitat.

Jens Schweikhardt

unread,
Sep 4, 2001, 8:28:45 AM9/4/01
to
Helmut Schellong <sche...@t-online.de> wrote
in <3B949807...@t-online.de>:
#
# Jens Schweikhardt wrote:
...
#> Ich habe nie behauptet, daß clock() *immer* die Zeit seit Programmstart
#> liefert.
#
# Du nicht, aber beinahe alle anderen.

"Beinahe alle anderen"? Das muß ich übersehen haben. Wer denn?

#> 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.

Jens Schweikhardt

unread,
Sep 4, 2001, 8:32:33 AM9/4/01
to
Patrick Kursawe <Patrick...@ruhr-uni-bochum.de> wrote
in <9n2eki$cll$1...@sunu789.rz.ruhr-uni-bochum.de>:

#
# Jens Schweikhardt <use...@schweikhardt.net> schrieb:
#> 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.
#
# Moment. Das wäre doch "related to the 7th call of rand()", und das ist nicht
# mehr "only to the program invocation".

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.

Patrick Kursawe

unread,
Sep 4, 2001, 9:01:08 AM9/4/01
to
Jens Schweikhardt <use...@schweikhardt.net> schrieb:

> 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

Helmut Schellong

unread,
Sep 4, 2001, 7:59:11 AM9/4/01
to

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.

Helmut Schellong

unread,
Sep 4, 2001, 7:59:23 AM9/4/01
to

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.

--

Helmut Schellong

unread,
Sep 4, 2001, 7:57:54 AM9/4/01
to
kre...@flinux.tu-graz.ac.at wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> Das 0-Thema hast ja nur du gebracht, da du wieder mal von einer
> Implementation auf andere geschlossen hast. Da man clock() aber
> ohnehin nur relativ verwenden kann, bleibt sich das aber gleich.
> Ob man sagt "Zeit seit Programmstart, mit Startzeitpunkt xxx", oder
> "Zeit seit Zeitpunkt xxx" macht ja keinen Unterschied, wenn man sich
> mal die "as if"-Regel vor Augen haelt.


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

Patrick Kursawe

unread,
Sep 4, 2001, 9:52:51 AM9/4/01
to
Helmut Schellong <sche...@t-online.de> schrieb:

> 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.

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

unread,
Sep 4, 2001, 9:41:23 AM9/4/01
to
Jens Schweikhardt wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote
> in <3B949792...@t-online.de>:
> ...
> # Es geht hier darum, daß unablässig behauptet wird, der Standard
> # sage aus, clock() würde immer und unbedingt die Zeit seit
> # Programmstart liefern.
>
> Ich kann mich nicht erinnern, daß das jemand behauptet hat, geschweige
> denn "unablässig". Bitte belege dies ggfs mit einem Zitat.

-----------------------------------------------------------------
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
-----------------------------------------------------------------

Helmut Schellong

unread,
Sep 4, 2001, 9:18:46 AM9/4/01
to
Jens Schweikhardt wrote:
>
> Helmut Schellong <sche...@t-online.de> wrote
> in <3B949807...@t-online.de>:
> #
> # Jens Schweikhardt wrote:
> ...
> #> Ich habe nie behauptet, daß clock() *immer* die Zeit seit Programmstart
> #> liefert.
> #
> # Du nicht, aber beinahe alle anderen.
>
> "Beinahe alle anderen"? Das muß ich übersehen haben. Wer denn?

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.

</