Ausführungszeit messen
Thomas Runge
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
> Ich möchte unter Unix eine Zeitdifferenz berechnen
> Diese soll allerdings in Millisekunden angegeben werden
Evtl. gettimeofday()
--
"I'm working on it." <http://www.psyche.kn-bremen.de/>
Helmut Schellong
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
<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
Ich antworte jetzt nur, weil clock() OffTopic ist.
Michael Karcher
> clock()
> CLOCKS_PER_SEC (1000000 | 1000.0 | 128 | ...)
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
>
> 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
> 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
Das entspricht genau dem, was ich sagte.
Helmut Schellong
>
> 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
>>> 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
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
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
> >>
> >> 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
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
>
> Aeh, wie willst du ohne RTC (real time clock) die Zeit messen?
Mit Hilfe des bekannten Core-Taktes.
Joerg Plate
> 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
>
> > $ ./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
>
> 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
> 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
>> > 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
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
> 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
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
1. Warum ist das bei FreeBSD 128?
2. Warum wird 1E6 verlangt?
Helmut Schellong
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
>
> > # 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
> 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
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
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
> 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
Es ist erlaubt, weil es nicht explizit verboten ist.
Kein Wert ist explizit verboten, also ...
Jens Schweikhardt
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.
#
# 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
>
> Helmut Schellong <sche...@t-online.de> wrote:
> >> Helmut Schellong <sche...@t-online.de> schrieb:
>
> > erste clock()-Wert stets 0 sein darf und es in der Praxis
> > auch oft ist.
>
> 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
>
> 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
> 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
> 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
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
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
in <9n2eki$cll$1...@sunu789.rz.ruhr-uni-bochum.de>:#> 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
> 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
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
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
> 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
> 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
>
> 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
>
> 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.
Patrick Kursawe
Helmut Schellong <sche...@t-online.de> schrieb:
> Es geht hier darum, daß unablässig behauptet wird, der Standard
> Jens Schweikhardt wrote:
>> Ich kann mich nicht erinnern, daß das jemand behauptet hat, geschweige
>> denn "unablässig". Bitte belege dies ggfs mit einem Zitat.
[kräftig gekürzt]
[Zitat aus meinem Posting, Hervorhebungen von Helmut:]
> 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?
Mußt Du immer so große Postings machen um zu beweisen, daß Du den
Unterschied zwischen "an era related only to the program invocation"
und "Zeit seit Programmstart" immer noch nicht kapiert hast?
Seufzend,
Patrick
Patrick Kursawe
> 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.
Hier gibts mittlerweile ziemlich viele Postings. Hast Du mal die
Message-ID zu dem hier gemeinten "erklärenden Posting"?
Tschüs, Patrick
Simon Krahnke
> 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 :-)
Ich sehe das aber nicht anders. Null darf clock() IMHO nur liefern,
wenn dieser Aufruf von clock() das Erste ist, was das Programm tut.
Also in:
| #include <time.h>
| clock_t c;
| int main (void)
| {
| c = clock ();
| ...
Außer Acht gelassen habe ich die Möglichkeit, das der "Startwert"
negativ sein könnte, und der erste Aufruf von clock() zufälligerweise
nach genau -Startwert Ticks kommt.
BTW: Ich hatte aus C89 zitiert. Darf ich aus fehlenden Kommentaren
dazu schließen, das ist C99 das gleiche steht?
mfg, simon .... zulu
Jens Schweikhardt
in <3B94DA03...@t-online.de>:
#
# 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.
[snip Zitate]
Ich kann in keinem der genannten Zitate die Behauptung finden, daß clock()
"immer und unbedingt die Zeit seit Programmstart" liefert. Kannst Du
bitte genau diese Stelle zitieren?
Jens Schweikhardt
in <3B94D4B6...@t-online.de>:
#
# Jens Schweikhardt wrote:
#> #
#> # 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.
Nein, da hast Du nur eine Nebelkerze gezündet, weil in keinem der
Artikel jemand behauptet hat, daß clock() *immer* die Zeit seit
Programmstart liefert. Also nochmal: wer hat mit welchen Worten das
behauptet?
...
# 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.
Ich kann zumindest für mich sprechen, daß meine Kritik aus der Aussage
"in der Regel" für clock() = 0 beim ersten Aufruf kommt und nicht
grundlegend war (was immer das heißen soll).
Patrick Kursawe
> Ich sehe das aber nicht anders. Null darf clock() IMHO nur liefern,
> wenn dieser Aufruf von clock() das Erste ist, was das Programm tut.
Ich würde sagen, je nach Auflösung des Zählers darf clock() ziemlich
lange auch 0 zurückgeben, und vorher darf es gerne was tun. Aber wenn es
einmal zwei Tage, dann eine Woche und dann drei Sekunden läuft bevor
es zum ersten mal clock() aufruft und jedesmal 0 herauskommt, dann ist
die Implementierung nicht standardkonform. Aber darüber fangen die
Leute in comp.std.c auch gerade an sich zu streiten :-)
Eine Bemerkung möchte ich aber loswerden: Wie hat es diese Formulierung
eigentlich in den Standard geschafft, wenn die einzige sinnvolle Verwendung
eh in der Differenze der Rückgabewerte zweier clock()-Aufrufe besteht?
Praktisch gesehen ist es doch vollkommen egal, was der erste Aufruf
zurückgibt.
Tschüs, Patrick
Patrick Kursawe
> Aber wenn Du magst, frag mal in news:comp.std.c nach.
Thread läuft gerade. Die sind sich fast so einig wie wir hier :-)
Tschüs, Patrick
Franz Iberl
> Ich sehe das aber nicht anders. Null darf clock() IMHO nur liefern,
> wenn dieser Aufruf von clock() das Erste ist, was das Programm tut.
es war doch schon klar, daß nur die Differenz zwischen zwei Aufrufen
auswertbar ist; wieso kann dann der Wert /eines einzelnen Aufrufs/
überhaupt eine Rolle spielen - der darf doch gar nicht interessieren,
denke ich.
Servus
Franz
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote
> in <3B94DA03...@t-online.de>:
> #
> # 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.
>
> [snip Zitate]
>
> Ich kann in keinem der genannten Zitate die Behauptung finden, daß clock()
> "immer und unbedingt die Zeit seit Programmstart" liefert. Kannst Du
> bitte genau diese Stelle zitieren?
Ich hatte *nicht* wörtlich zitiert: ".........."
Juergen Ilse
Franz Iberl <ib...@izm-m.fhg.de> wrote:
> Simon Krahnke wrote:
>> Ich sehe das aber nicht anders. Null darf clock() IMHO nur liefern,
>> wenn dieser Aufruf von clock() das Erste ist, was das Programm tut.
Das geht (trotz aller Moeglichkeiten das kontrovers zu sehen) so auf
keinen Fall aus dem Standard hervor. Stell dir vor, dass clock die
Zeitdauer seit Programm-Start mit einem Offset von -3600 Sekunden
angibt: wenn nun das Programm gerade *genau eine Stunde* nach Start
das erste mal clock() aufruft, wuerde es u.U. eine 0 bekommen, aber
der Aufruf von clock() waere weit davon entfernt das erste zu sein,
was das Programm tat ...
> es war doch schon klar, daß nur die Differenz zwischen zwei Aufrufen
> auswertbar ist; wieso kann dann der Wert /eines einzelnen Aufrufs/
> überhaupt eine Rolle spielen - der darf doch gar nicht interessieren,
> denke ich.
So sollte es sein, nur besagt die (hier wohl zu ungenaue) Formulierung
im Standard etwas anderes ...
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Die Frage ist, ob Du lieber an 3.-Welt-Software für das |Juergen Ilse
vorletzte Jahrzehnt verreckst oder lernst, mit Technik |Internet POP Hannover
umzugehen. Wenn Personal Firewalls die Lösung sind, |Vahrenwalder Str. 205
will ich das verdammte Problem zurück. (RSS in dcsf) |30165 Hannover
Frank Klemm
>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?
>
2^32/10^6 = 4294.96... = ca. 71 min.
Es wird kaum ein 16 bit-Datentyp sein und auch 32 bit können etwas knapp
werden.
Allerdings legt der Standard keine Mindestzeit fest, die clock_t erfassen
könne muß => Bug.
--
Frank Klemm
Jens Schweikhardt
in <3B95EBE6...@t-online.de>:#> in <3B94DA03...@t-online.de>:
#> ##> #> 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
#>
#> [snip Zitate]
#>
#> Ich kann in keinem der genannten Zitate die Behauptung finden, daß clock()
#> "immer und unbedingt die Zeit seit Programmstart" liefert. Kannst Du
#> bitte genau diese Stelle zitieren?
#
# Ich hatte *nicht* wörtlich zitiert: ".........."
Wundert mich nicht, da Du überhaupt nichts Relevantes zitiert hast. Es
hat nämlich auch nicht eine einzige Person behauptet, der Standard sage
aus, clock() würde immer und unbedingt die Zeit seit Programmstart
liefern.
Jens Schweikhardt
in <slrn9pcau...@c.zeiss.de>:
...
#>ObC: was folgt für den unterliegenden Typ von clock_t, wenn CLOCKS_PER_SEC
#> eine Million ist?
#>
# 2^32/10^6 = 4294.96... = ca. 71 min.
#
# Es wird kaum ein 16 bit-Datentyp sein und auch 32 bit können etwas knapp
# werden.
# Allerdings legt der Standard keine Mindestzeit fest, die clock_t erfassen
# könne muß => Bug.
Oder feature; it's in the eye of the beholder. Der Standard legt nicht
einmal fest, daß clock() etwas anderes als (clock_t)-1 liefern muß.
Jens Schweikhardt
in <9n4kag$154$1...@sunu789.rz.ruhr-uni-bochum.de>:
...
# Eine Bemerkung möchte ich aber loswerden: Wie hat es diese Formulierung
# eigentlich in den Standard geschafft, wenn die einzige sinnvolle Verwendung
# eh in der Differenze der Rückgabewerte zweier clock()-Aufrufe besteht?
Ich vermute existing code. Wenn Dir (wie bei den BSD Systemen) garantiert
ist, daß auch der erste clock() Aufruf schon einen sinnvollen Wert liefert,
dann lag es nahe, dies zu nutzen. Hätte der Standard darauf bestanden, daß
nur Differenzen sinnvoll sind, wären viele Programme plötzlich nicht mehr
konform (quiet change). Sowas ist im Standardisierungsprozeß eine große Hürde.
Patrick Kursawe
> Oder feature; it's in the eye of the beholder. Der Standard legt nicht
> einmal fest, daß clock() etwas anderes als (clock_t)-1 liefern muß.
Zumindest laut C9x-Draft wird da aber dringend empfohlen:
| If the processor time used is not available or its value cannot be
| represented, the function returns the value (clock_t)-1.250
Tschüs, Patrick (comp.std.c wird langsam interessant)
Patrick Kursawe
> Patrick Kursawe <Patrick...@ruhr-uni-bochum.de> wrote
> ...
> # Eine Bemerkung möchte ich aber loswerden: Wie hat es diese Formulierung
> # eigentlich in den Standard geschafft, wenn die einzige sinnvolle Verwendung
> # eh in der Differenze der Rückgabewerte zweier clock()-Aufrufe besteht?
>
> Ich vermute existing code. Wenn Dir (wie bei den BSD Systemen) garantiert
> ist, daß auch der erste clock() Aufruf schon einen sinnvollen Wert liefert,
> dann lag es nahe, dies zu nutzen. Hätte der Standard darauf bestanden, daß
> nur Differenzen sinnvoll sind, wären viele Programme plötzlich nicht mehr
> konform (quiet change). Sowas ist im Standardisierungsprozeß eine große Hürde.
Den Gedankengang kann ich nicht nachvollziehen. Wieso sollte jemand
darauf bestehen, daß nur Differenzen sinnvoll sind? Man hätte doch sagen
können, daß Differenzen sinnvoll sein sollen und der Rest implementation
defined ist. Wo soll da was kaputtgehen?
Grübelnd,
Patrick
Simon Krahnke
>> Simon Krahnke wrote:
>>
>>> Ich sehe das aber nicht anders. Null darf clock() IMHO nur liefern,
>>> wenn dieser Aufruf von clock() das Erste ist, was das Programm tut.
>
> Das geht (trotz aller Moeglichkeiten das kontrovers zu sehen) so auf
> keinen Fall aus dem Standard hervor. Stell dir vor, dass clock die
> Zeitdauer seit Programm-Start mit einem Offset von -3600 Sekunden [...]
Ich schrieb im von dir indirekt zitierten Posting (nicht angekommen?):
| Außer Acht gelassen habe ich die Möglichkeit, das der "Startwert"
| negativ sein könnte, und der erste Aufruf von clock() zufälligerweise
| nach genau -Startwert Ticks kommt.
Patrick hat dann noch angemerkt, das die Dauer eines Ticks ja auch
mehr als nur eine Instruktion umfassen kann. Das verallgemeinert meine
Aussage natürlich von "das Erste was das Programm tut" zu "eines der
Dinge ist, die innerhalb des ersten Ticks passieren."
mfg, simon .... up
Helmut Schellong
Doch. Die entsprechenden Postings hatte ich inhaltlich gepostet.
Es wurde sogar heftig in Zweifel gezogen (mit Häme), als ich den
Standard-Text
als unklar ... bezeichnete - zu Anfang - jetzt im Gegenteil.
Bernd Luevelsmeyer
>
> Jens Schweikhardt <use...@schweikhardt.net> schrieb:
> > Oder feature; it's in the eye of the beholder. Der Standard legt nicht
> > einmal fest, daß clock() etwas anderes als (clock_t)-1 liefern muß.
>
> Zumindest laut C9x-Draft wird da aber dringend empfohlen:
>
> | If the processor time used is not available or its value cannot be
> | represented, the function returns the value (clock_t)-1.250
Das ist ``(clock_t)-1´´, dann ein Punkt fuer das Satzende, dann die
Fussnote 250; nicht die Fliesskommazahl -1.250 gecastet auf clock_t.
Nur falls sich jemand wundert ;-)
Florian Weimer
> Jens Schweikhardt <use...@schweikhardt.net> schrieb:
> > Oder feature; it's in the eye of the beholder. Der Standard legt nicht
>> einmal fest, daß clock() etwas anderes als (clock_t)-1 liefern muß.
>
> Zumindest laut C9x-Draft wird da aber dringend empfohlen:
>
> | If the processor time used is not available or its value cannot be
> | represented, the function returns the value (clock_t)-1.250
Die '250' verweist auf eine Fußnote. Zumindest steht dort eine in der
Norm.
Patrick Kursawe
> Das ist ``(clock_t)-1´´, dann ein Punkt fuer das Satzende, dann die
> Fussnote 250; nicht die Fliesskommazahl -1.250 gecastet auf clock_t.
> Nur falls sich jemand wundert ;-)
Ooops :-)
Sich unauffällig verziehend,
Patrick
Helmut Schellong
Schau mal:
-----------------------------------------------------------------
> 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.
-----------------------------------------------------------------
Patrick Kursawe
> Schau mal:
> -----------------------------------------------------------------
>> 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.
> -----------------------------------------------------------------
Was ändert das jetzt daran, daß im Gegensatz zu Deiner Unterstellung
immer noch niemand behauptet hat, es müßte die Zeit seit Programmstart
zurückgegeben werden?
Gelangweilt,
Patrick
Jens Schweikhardt
in <3B965860...@t-online.de>:
#> # Ich hatte *nicht* wörtlich zitiert: ".........."
#> Wundert mich nicht, da Du überhaupt nichts Relevantes zitiert hast. Es
#> hat nämlich auch nicht eine einzige Person behauptet, der Standard sage
#> aus, clock() würde immer und unbedingt die Zeit seit Programmstart
#> liefern.
#
# Doch. Die entsprechenden Postings hatte ich inhaltlich gepostet.
Nein. Ein Zitat aus einen Kochrezept hat genauso viel Belegkraft für
Deine Behauptung, irgendjemand hätte gemeint, der Standard sage aus,
clock() würde immer und unbedingt die Zeit seit Programmstart liefern.
Regards,
Jens Schweikhardt
in <9n5jic$p28$2...@sunu789.rz.ruhr-uni-bochum.de>:
#
# Jens Schweikhardt <use...@schweikhardt.net> schrieb:
#> Patrick Kursawe <Patrick...@ruhr-uni-bochum.de> wrote
#> ...
#> # Eine Bemerkung möchte ich aber loswerden: Wie hat es diese Formulierung
#> # eigentlich in den Standard geschafft, wenn die einzige sinnvolle Verwendung
#> # eh in der Differenze der Rückgabewerte zweier clock()-Aufrufe besteht?
#>
#> Ich vermute existing code. Wenn Dir (wie bei den BSD Systemen) garantiert
#> ist, daß auch der erste clock() Aufruf schon einen sinnvollen Wert liefert,
#> dann lag es nahe, dies zu nutzen. Hätte der Standard darauf bestanden, daß
#> nur Differenzen sinnvoll sind, wären viele Programme plötzlich nicht mehr
#> konform (quiet change). Sowas ist im Standardisierungsprozeß eine große Hürde.
#
# Den Gedankengang kann ich nicht nachvollziehen. Wieso sollte jemand
# darauf bestehen, daß nur Differenzen sinnvoll sind?
Dann habe ich Deine Frage nicht verstanden. Welche Formulierung aus
dem Standard meinst Du:
- Den normativen Text?
- Die nicht normative Fußnote?
Frank Klemm
>Frank Klemm <p...@c.zeiss.de> wrote
> in <slrn9pcau...@c.zeiss.de>:
>...
>#>ObC: was folgt für den unterliegenden Typ von clock_t, wenn CLOCKS_PER_SEC
>#> eine Million ist?
>#>
># 2^32/10^6 = 4294.96... = ca. 71 min.
>#
># Es wird kaum ein 16 bit-Datentyp sein und auch 32 bit können etwas knapp
># werden.
># Allerdings legt der Standard keine Mindestzeit fest, die clock_t erfassen
># könne muß => Bug.
>
>Oder feature; it's in the eye of the beholder. Der Standard legt nicht
>einmal fest, daß clock() etwas anderes als (clock_t)-1 liefern muß.
>
implementierbar. Wobei ich eher auf zweiteres hoffe, sonst ist der
Compiler+Libs etwas ...
Das ist erst mal gut, weil nicht die alte ANSI-Leier: Es könnte Systeme
geben, auf denen das nicht implementierbar ist, deswegen lassen wir es weg.
Nett wäre eventuell noch ein Macro, was anzeigt, daß die Funktion
funktionslos ist. Vorschlag wäre CLOCKS_PER_SEC:=0, was ja auch
der Realität entspricht (Zähler wird je Sekunde um 0 weitergezählt).
Ansonsten sollte im Standard folgendes festgeschrieben sein:
- Minimalauflösung
- Maximalauflösung
- minimal garantierte Zeitspanne
- Überlaufverhalten
Sonst ist das keine API, sondern Wackelpudding.
--
Frank Klemm
Franz Iberl
(ist ganz schön länglich geworden ;-) )
> Doch. Die entsprechenden Postings hatte ich inhaltlich gepostet.
> Es wurde sogar heftig in Zweifel gezogen (mit Häme), als ich den
> Standard-Text
> als unklar ... bezeichnete - zu Anfang - jetzt im Gegenteil.
Nee.
Was nach meiner Beobachtung allen klar war, ist daß ein einzelner
clock()-Aufruf sinnlos ist, weil ausschließlich die Differenz
zweier Aufrufe eine sinnvolle Zeit gibt. Das kam auch schon mehrfach, ohne
daß es Dich zu interessieren schien.
Ob man den ersten Aufruf auch noch als "Initialisierung" bezeichet ist doch
nur Ablenkung. Deine Spekulationen über den "ersten" clock()-Rückgabewert
haben mich deshalb sehr verwundert - wozu sollten die gut sein?
Servus
Franz
Patrick Kursawe
> Vielleicht fällt es jetzt auf:
[fast 6000 Zeilen mit immer wieder dem Inhalt eines vorherigen
Postings]
Sag mal, Helmut, hast Du den Schuß nicht mehr gehört?
Hast Du leicht masochistische Neigungen oder wieso wiederholst Du hier
dutzendweise den Text, wo Simon Deine Behauptung
"clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
von clock() vergangen ist" (<3B919C5C...@t-online.de>) widerlegt?
Falls Du damit belegen wolltest, Simon habe behauptet, es müßte die Zeit
seit Programmstart zurückgegeben werden, dann hast Du nur
überdeutlich gezeigt, daß Du nicht nur nicht posten sondern auch
nicht lesen kannst.
Nochmal extra für Dich, lies es langsam und sprich es laut nach:
"since the beginning of an implementation-defined era related only to the
program invocation" ist NICHT "since the program invocation".
Tschüs, und nächstes mal schalte vielleicht erst das Gehirn und
dann den Computer ein!
Patrick
Patrick Kursawe
> Dann habe ich Deine Frage nicht verstanden. Welche Formulierung aus
> dem Standard meinst Du:
>
> - Den normativen Text?
Genau diesen. Mittlerweile habe ich mich dazu durchgerungen, daß man
"an era related only to the program invocation" wohl so auffassen kann,
daß damit "relativ zu, aber nicht notwendigerweise beginnend mit"
gemeint ist - daß also z.B. Implementierungen, die
(kleiner Seitenhieb) "die Zeit seit einem vorherigen Aufruf von clock()"
zurückgeben, nicht in Ordnung sind, sondern daß sich alle Rückgabewerte
auf einen Fixpunkt beziehen, der durchaus auch der allererste clock() Aufruf
sein darf, wenn man es nicht zu haarspalterisch auslegt.
Hört sich das halbwegs vernünftig an?
Grübelnd,
Patrick
Franz Iberl
> gemeint ist - daß also z.B. Implementierungen, die
> (kleiner Seitenhieb) "die Zeit seit einem vorherigen Aufruf von clock()"
> zurückgeben, nicht in Ordnung sind, sondern daß sich alle Rückgabewerte
> auf einen Fixpunkt beziehen, der durchaus auch der allererste clock() Aufruf
> sein darf, wenn man es nicht zu haarspalterisch auslegt.
"seit einem vorherigen Aufruf" und "seit dem allerersten Aufruf" muß doch logisch
äquivalent sein:
Wenn ich 2, 3, viele clock()-Aufrufe unterbringe, und jeweils die Differenz
korrekt auswerte, ist folglich auch der letzte gegnüber dem ersten Aufruf
wohldefiniert, ob man den ersten dann "Fixpunkt" nennt oder nicht, spielt doch keine
Rolle mehr?
Servus
Franz
Patrick Kursawe
> Wenn ich 2, 3, viele clock()-Aufrufe unterbringe, und jeweils die Differenz
> korrekt auswerte, ist folglich auch der letzte gegnüber dem ersten Aufruf
> wohldefiniert, ob man den ersten dann "Fixpunkt" nennt oder nicht, spielt doch keine
> Rolle mehr?
Es geht eben darum, wie eine korrekte Auswertung der Differenz auszusehen
hat - ob nur 2-1 3-2 4-3 ok ist oder auch 4-2.
Naja, erstmal essen gehen,
Patrick
Franz Iberl
> Es geht eben darum, wie eine korrekte Auswertung der Differenz auszusehen
> hat - ob nur 2-1 3-2 4-3 ok ist oder auch 4-2.
Ich rätsele (Gedankenexperiment?): wie soll bei 4-2 was anderes rauskommen
können als bei (3-2) + (4-3) ?
> Naja, erstmal essen gehen,
wünsche wohl gespeist zu haben
Franz
Jens Schweikhardt
in <slrn9pe1u...@c.zeiss.de>:
...
# Ansonsten sollte im Standard folgendes festgeschrieben sein:
# - Minimalauflösung
Ist 0.
# - Maximalauflösung
Warum nach oben begrenzen?
# - minimal garantierte Zeitspanne
Ist 0.
# - Überlaufverhalten
Ist nichtmal bei int festgelegt, warum dann für clock_t?
# Sonst ist das keine API, sondern Wackelpudding.
Nö. Es ist einfach nicht Aufgabe von ISO C. Es gibt weitergehende
Standards wie POSIX, die hier mehr festlegen. Lies diese, benutze
diese.
Helmut Leitner
Patrick Kursawe wrote:
> Sag mal, Helmut, hast Du den Schuß nicht mehr gehört?
> Hast Du leicht masochistische Neigungen oder wieso wiederholst Du hier
> dutzendweise den Text, wo Simon Deine Behauptung
> "clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> von clock() vergangen ist" (<3B919C5C...@t-online.de>) widerlegt?
>
>
> Tschüs, und nächstes mal schalte vielleicht erst das Gehirn und
> dann den Computer ein!
Kommunikation kann nur effizient funktionieren, wenn beide Teile ein
bisschen tolerant sind und nicht auf Kleinigkeiten herumreiten.
Im nachhinein, wenn der
<http://www.wikiservice.at/dse/wiki.cgi?MegaThread>
vorbei bzw. abgebrochen ist, noch mit dem Baseball-Schläger
drüberfahren zu wollen, ist nicht unbedingt stilvoll.
Aggressionen sind immer OT.
Liebe Grüße,
--
Helmut Leitner lei...@hls.via.at
Graz, Austria www.hls-software.com
Patrick Kursawe
> Ich rätsele (Gedankenexperiment?): wie soll bei 4-2 was anderes rauskommen
> können als bei (3-2) + (4-3) ?
Szenario A: erster Aufruf ist Fixpunkt, für Helmut mal = 0.
Aufruf Wert Absolute Zeit seit Programmstart
1 0 100
2 123 223
3 345 445
4 567 667
Szenario B: die Zeit seit einem vorherigen Aufruf von clock() wird zurück-
gegeben
Aufruf Wert Absolute Zeit seit Programmstart
1 0 100
2 123 223
3 222 445
4 222 667
Beides würde den gleichen zeitlichen Ablauf wiedergeben, aber die
im Standard empfohlene Differenzbildung würde bei Szenario B für
4-3 den Wert 0 ergeben und wäre sowieso offensichtlicher Unfug.
allein hieran wird deutlich, daß eine clock()-Implementierung, die
die Zeit seit einem vorherigen Clock-Aufruf zurückgibt, nicht dem Standard
entspricht.
Alle Klarheiten beseitigt?
> wünsche wohl gespeist zu haben
Naja, für Mensa gar nicht mal so übel.
Tschüs, Patrick
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> schrieb:
> > Vielleicht fällt es jetzt auf:
>
> [fast 6000 Zeilen mit immer wieder dem Inhalt eines vorherigen
> Postings]
>
> Sag mal, Helmut, hast Du den Schuß nicht mehr gehört?
> Hast Du leicht masochistische Neigungen oder wieso wiederholst Du hier
> dutzendweise den Text, wo Simon Deine Behauptung
> "clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> von clock() vergangen ist" (<3B919C5C...@t-online.de>) widerlegt?
>
> Falls Du damit belegen wolltest, Simon habe behauptet, es müßte die Zeit
> seit Programmstart zurückgegeben werden, dann hast Du nur
> überdeutlich gezeigt, daß Du nicht nur nicht posten sondern auch
> nicht lesen kannst.
Und wie deutest Du das?:
---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
> Nochmal extra für Dich, lies es langsam und sprich es laut nach:
> "since the beginning of an implementation-defined era related only to the
> program invocation" ist NICHT "since the program invocation".
>
> Tschüs, und nächstes mal schalte vielleicht erst das Gehirn und
> dann den Computer ein!
Vielleicht fällt es jetzt auf:
-----------------------------------------------------------------
> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> von clock() vergangen ist.
| 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
-----------------------------------------------------------------
Hier wird ein Satz von mir angegriffen, der aussagt, daß man nicht
mit einem einzelnen Aufruf arbeiten sollte. (isoliert betrachtet)
Fortsetzung:
-----------------------------------------------------------------
> 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
-----------------------------------------------------------------
Und hier wurde die Sache *glasklar*.
Deshalb hatte ich später noch die Fußnote250 gepostet, in der steht,
daß man eben doch einen vorherigen Aufruf verwenden soll.
-----------------------------------------------------------------
> 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
-----------------------------------------------------------------
Und hier wurde die Sache *doppelt glasklar*.
Es ist eindeutig, daß beispielsweise Simon zu dieser Zeit im Thread
der Meinung war, aufgrund des Standard-Textes, daß ein einzelner
erster Aufruf die korrekte Programmzeit seit Programmstart
liefern muß.
Wenn jemand dies anders deutet, soll er das sagen und wie ich
erklären.
Helmut Schellong
>
> Hallo Helmut,
>
> (ist ganz schön länglich geworden ;-) )
>
> > Doch. Die entsprechenden Postings hatte ich inhaltlich gepostet.
> > Es wurde sogar heftig in Zweifel gezogen (mit Häme), als ich den
> > Standard-Text
> > als unklar ... bezeichnete - zu Anfang - jetzt im Gegenteil.
>
> Nee.
>
> Was nach meiner Beobachtung allen klar war, ist daß ein einzelner
> clock()-Aufruf sinnlos ist, weil ausschließlich die Differenz
> zweier Aufrufe eine sinnvolle Zeit gibt. Das kam auch schon mehrfach, ohne
> daß es Dich zu interessieren schien.
Wie bitte?!
Ich war der *erste*, der das gesagt hatte und deshalb
nachfolgend Widerstand erntete.
*Ich* war derjenige, der zuerst gesagt hatte, daß man bei clock()
nur mit Differenzen zwischen zwei Aufrufen arbeiten soll!
Und wie deutest Du das?:
---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
> Ob man den ersten Aufruf auch noch als "Initialisierung" bezeichet ist doch
> nur Ablenkung. Deine Spekulationen über den "ersten" clock()-Rückgabewert
> haben mich deshalb sehr verwundert - wozu sollten die gut sein?
Der Standard erlaubt eine solche "Initialisierung" und es gibt
sie auch in der Praxis.
Und dann lies mal comp.lang.std.c :
Dort habe ich ebenfalls die Fußnote gepostet, um
Klarheit hineinzubringen.
------------------------------------------------------
James Kuyper <kuy...@wizard.net> wrote:
>Helmut Schellong wrote:
>>
>> Larry Jones wrote:
>> >
>> > Nick Maclaren (nm...@cus.cam.ac.uk) wrote:
>> > >
>> > > I agree. It is a damn shoddy implementation, but conforming.
>> >
>> > Why do you say it's "damn shoddy"? The general principle is that the
>> > absolute value returned by clock() is meaningless, only differences
>> > between values are meaningful. Given that, what's wrong with returning
>> > 0 on the first call? (Or do you take exception to the general
>> > principle?)
>>
>> --------------------------------------------------------------
>> 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.
>> --------------------------------------------------------------
>
>That would still work.
No one is disputing that. I think the point is that the footnote
explicitly acknowledges that the value from the first call is pretty
meaningless, so if you want total CPU time you should call it as quickly as
possible to establish a baseline, rather than expect an initial call later
to return a meaningful value.
And if the first call is allowed to be meaningless, it might as well be 0.
--
Barry Margolin, bar...@genuity.net
------------------------------------------------------
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote
> in <3B965860...@t-online.de>:
> #> # Ich hatte *nicht* wörtlich zitiert: ".........."
> #>
> #> Wundert mich nicht, da Du überhaupt nichts Relevantes zitiert hast. Es
> #> hat nämlich auch nicht eine einzige Person behauptet, der Standard sage
> #> aus, clock() würde immer und unbedingt die Zeit seit Programmstart
> #> liefern.
> #
> # Doch. Die entsprechenden Postings hatte ich inhaltlich gepostet.
>
> Nein. Ein Zitat aus einen Kochrezept hat genauso viel Belegkraft für
> Deine Behauptung, irgendjemand hätte gemeint, der Standard sage aus,
> clock() würde immer und unbedingt die Zeit seit Programmstart liefern.
Vielleicht fällt es jetzt auf:
-----------------------------------------------------------------
> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
> von clock() vergangen ist.
| 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
-----------------------------------------------------------------
Hier wird ein Satz von mir angegriffen, der aussagt, daß man nicht
mit einem einzelnen Aufruf arbeiten sollte. (isoliert betrachtet)
Fortsetzung:
-----------------------------------------------------------------
> 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
-----------------------------------------------------------------
Und hier wurde die Sache *glasklar*.
Deshalb hatte ich später noch die Fußnote250 gepostet, in der steht,
daß man eben doch einen vorherigen Aufruf verwenden soll.
-----------------------------------------------------------------
> 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
-----------------------------------------------------------------
Und hier wurde die Sache *doppelt glasklar*.
Es ist eindeutig, daß beispielsweise Simon zu dieser Zeit im Thread
der Meinung war, aufgrund des Standard-Textes, daß ein einzelner
erster Aufruf die korrekte Programmzeit seit Programmstart
liefern muß.
Wenn jemand dies anders deutet, soll er das sagen und wie ich
erklären.
--
Patrick Kursawe
> Kommunikation kann nur effizient funktionieren, wenn beide Teile ein
> bisschen tolerant sind und nicht auf Kleinigkeiten herumreiten.
Ich halte mich für ein bißchen tolerant. Manchmal wohl ein bißchen zu wenig.
> Im nachhinein, wenn der
>
> <http://www.wikiservice.at/dse/wiki.cgi?MegaThread>
>
> vorbei bzw. abgebrochen ist, noch mit dem Baseball-Schläger
> drüberfahren zu wollen, ist nicht unbedingt stilvoll.
Das nicht, aber gelegentlich tuts in dem Moment gut :-)
> Aggressionen sind immer OT.
Naja, zumindest in de.comp.lang.c.
Mit http://www.wikiservice.at/dse/wiki.cgi?CeeFunction_clock einverstanden?
Tschüs, Patrick
Patrick Kursawe
> Und wie deutest Du das?:
> ---------------------------------------------------------------------
>> 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
> ---------------------------------------------------------------------
Genau so, wie es da steht. Wenn ich sage, daß mein Geburtstag relativ
zu Christi Geburt (bitte jetzt keine historische Diskussion über das Jahr 1)
datiert ist, dann heißt das nicht, daß ich über 2000 Jahre alt bin.
Genausowenig bekommt man vom timer unbedingt die Zeit seit Programmstart
zurück, wenn es nur relativ zum selbigen sein muß.
>> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
>> von clock() vergangen ist.
>
>| 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
> -----------------------------------------------------------------
> Hier wird ein Satz von mir angegriffen, der aussagt, daß man nicht
> mit einem einzelnen Aufruf arbeiten sollte. (isoliert betrachtet)
Moment. Das wolltest Du mit diesem Satz aussagen? Wieso hast Du das
dann nicht einfach getan? Es gibt hier (hoffentlich) niemanden, der
ernsthaft den ersten Rückgabewert von clock() zu was anderem als
zur Differenzbildung mit einem späteren benutzen will und dabei glaubt,
auf der sicheren Seite zu sein.
> Da oben steht "related only to the program invocation", nichts von
> irgendeinem vorherigen Aufruf von clock().
> mfg, simon .... bah
> -----------------------------------------------------------------
> Und hier wurde die Sache *glasklar*.
> Deshalb hatte ich später noch die Fußnote250 gepostet, in der steht,
> daß man eben doch einen vorherigen Aufruf verwenden soll.
... was (IMHO) niemand bezweifelt hatte. Du hast da gegen Windmühlen
gekämpft.
> -----------------------------------------------------------------
>> 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
> -----------------------------------------------------------------
> Und hier wurde die Sache *doppelt glasklar*.
Hier nochmal meine Meinung dazu: Wenn clock() beim ersten Aufruf
immer 0 zurückgibt, dann ist das auf eine in meinen Augen total
irrelevante Art nicht standardkonform, da für jede sinnvolle Verwendung
von clock() nur die Differenzen zwischen Aufrufen relevant sind.
> Es ist eindeutig, daß beispielsweise Simon zu dieser Zeit im Thread
> der Meinung war, aufgrund des Standard-Textes, daß ein einzelner
> erster Aufruf die korrekte Programmzeit seit Programmstart
> liefern muß.
> Wenn jemand dies anders deutet, soll er das sagen und wie ich
> erklären.
Ich sage das hiermit und ich sage auch, daß ich Deine Erklärung nicht
nachvollziehen kann, weil Du kein Zitat geliefert hast, das Deine These
in meinen Augen bestätigt. Also stelle ich fest, daß wir diesen Teil des
Threads unterschiedlich interpretieren.
Ebenso stelle ich fest, daß das schnurzpiepegal ist, da wir uns über
die korrekte Verwendung von clock() hoffentlich einig sind und plädiere
hiermit auf EOD wegen unüberbrückbarer irrelevanter Meinungsverschiedenheit.
Einverstanden?
Patrick
Frank Klemm
>Frank Klemm <p...@c.zeiss.de> wrote
> in <slrn9pe1u...@c.zeiss.de>:
>...
># Ansonsten sollte im Standard folgendes festgeschrieben sein:
># - Minimalauflösung
>
>Ist 0.
>
># - Maximalauflösung
>
>Warum nach oben begrenzen?
>
># - minimal garantierte Zeitspanne
>
>Ist 0.
>
Was ist das für ein architektonischer Dummfug?
Wenn in der Baustatik so gearbeitet würde, dann gäbe es jährlich zigtausende
Tote.
># - Überlaufverhalten
>
>Ist nichtmal bei int festgelegt, warum dann für clock_t?
>
># Sonst ist das keine API, sondern Wackelpudding.
>
>Nö. Es ist einfach nicht Aufgabe von ISO C. Es gibt weitergehende
>Standards wie POSIX, die hier mehr festlegen. Lies diese, benutze
>diese.
>
Was will ich mit so einem Murks anfangen? Wie will ich Programme evaluieren?
Dagegen ist Treibsatz ja was hochstabiles!
--
Frank Klemm
Franz Iberl
>
> Franz Iberl <ib...@izm-m.fhg.de> schrieb:
> > Ich rätsele (Gedankenexperiment?): wie soll bei 4-2 was anderes rauskommen
> > können als bei (3-2) + (4-3) ?
>
> Szenario A: erster Aufruf ist Fixpunkt, für Helmut mal = 0.
> Szenario B: die Zeit seit einem vorherigen Aufruf von clock() wird zurück-
> gegeben
ach so: da hab ich sprachlich nicht aufgepaßt, und die Variante schlicht
nicht erkannt.
> 4-3 den Wert 0 ergeben und wäre sowieso offensichtlicher Unfug.
> allein hieran wird deutlich, daß eine clock()-Implementierung, die
> die Zeit seit einem vorherigen Clock-Aufruf zurückgibt, nicht dem Standard
> entspricht.
hab ich die ganze Zeit nie anders gelesen, sorry.
Servus
Franz
Franz Iberl
...
> > Was nach meiner Beobachtung allen klar war, ist daß ein einzelner
> > clock()-Aufruf sinnlos ist, weil ausschließlich die Differenz
> > zweier Aufrufe eine sinnvolle Zeit gibt. Das kam auch schon mehrfach, ohne
> > daß es Dich zu interessieren schien.
>
> Wie bitte?!
> Ich war der *erste*, der das gesagt hatte und deshalb
> nachfolgend Widerstand erntete.
> *Ich* war derjenige, der zuerst gesagt hatte, daß man bei clock()
> nur mit Differenzen zwischen zwei Aufrufen arbeiten soll!
Ich hab Deine Kritik an "den Anderen" völlig anders verstanden - daß
der Streit um einen "bestimmten" Startwert ging. Bei Dir war das
dann die "Differenz zu 0", also ein in meinen Augen eher uninteressanter
Spezialfall - daher die "unterschiedliche Wahrnehmung".
Aber ich habe zugegebenermaßen mir nicht vorstellen können, daß irgendjemand
sich für einen einzelnen Wert interessiert, den clock() zurückgibt, und hab
das diesbezüglich etwas gefiltert gelesen, dazu sorry - im Standard gibt es
offensichtlich Formulierungen, die dazu eine - trotzdem sinnlose - Diskussion
eröffnen lassen.
Aber Deine Interpretation, daß irgendjemand einen /bestimmten/ Wert eines
einzelnen clock()-Aufrufes postuliert, die stimmte (auch beim Nachlesen) sicher
nicht, keinem Deiner Zitate konnte ich es entnehmen, drum mischte ich mich ein.
Aber inzwischen ist denk ich ziemlich viel klar geworden ;-)
Servus
Franz
Helmut Schellong
>
> Helmut Schellong wrote:
>
> ...
> > > Was nach meiner Beobachtung allen klar war, ist daß ein einzelner
> > > clock()-Aufruf sinnlos ist, weil ausschließlich die Differenz
> > > zweier Aufrufe eine sinnvolle Zeit gibt. Das kam auch schon mehrfach, ohne
> > > daß es Dich zu interessieren schien.
> >
> > Wie bitte?!
> > Ich war der *erste*, der das gesagt hatte und deshalb
> > nachfolgend Widerstand erntete.
> > *Ich* war derjenige, der zuerst gesagt hatte, daß man bei clock()
> > nur mit Differenzen zwischen zwei Aufrufen arbeiten soll!
>
>
> Aber Deine Interpretation, daß irgendjemand einen /bestimmten/ Wert eines
> einzelnen clock()-Aufrufes postuliert, die stimmte (auch beim Nachlesen) sicher
> nicht, keinem Deiner Zitate konnte ich es entnehmen, drum mischte ich mich ein.
>
> Aber inzwischen ist denk ich ziemlich viel klar geworden ;-)
Man muß den *gesamten* Thread chronologisch kennen, um Mißverständnisse
zu vermeiden. Ich war derjenige, der die erste (korrekte) Antwort im
Thread gab.
Simon Krahnke
>> -----------------------------------------------------------------
>>> 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
>> -----------------------------------------------------------------
>> Und hier wurde die Sache *doppelt glasklar*.
Das ich hier ja zitiert werde ...
> Hier nochmal meine Meinung dazu: Wenn clock() beim ersten Aufruf
> immer 0 zurückgibt, dann ist das auf eine in meinen Augen total
> irrelevante Art nicht standardkonform, da für jede sinnvolle Verwendung
> von clock() nur die Differenzen zwischen Aufrufen relevant sind.
Das ist auch so ziemlich genau meine Auffassung zu diesem Thema. IMHO
ist immer "0 beim ersten Aufruf" nicht standardkonform. Warum das so
definiert wurde, entzieht sich aber meiner Kenntnis.
clock() liefert Zeitpunkte. Um Zeitspannen zu erhalten, muss man eine
Differenz aus zwei Zeitpunkten bilden. Die Zeitpunkt-Skala in der
clock() arbeitet, definiert der Standard über eine Zeitspanne, was
vielleicht für etwas Verwirrung sorgte, da man mit diesem Wert als
Zeitspanne interpretiert nicht portabel (wohl aber unportabel!)
arbeiten kann.
mfg, simon .... ich hoffe, die diskussion erledigt
sich jetzt langsam.
Helmut Leitner
Patrick Kursawe wrote:
> ...
> Mit <http://www.wikiservice.at/dse/wiki.cgi?CeeFunction_clock> einverstanden?
Vielen Dank für diese Seite! Sie eröffnet eine Menge interessanter
zusätzlicher Fragen (siehe dort).
Jens Schweikhardt
in <slrn9pelq...@c.zeiss.de>:
#
# On 6 Sep 2001 11:41:35 GMT, Jens Schweikhardt <use...@schweikhardt.net> wrote:
#>Frank Klemm <p...@c.zeiss.de> wrote
#> in <slrn9pe1u...@c.zeiss.de>:
#>...
#># Ansonsten sollte im Standard folgendes festgeschrieben sein:
#># - Minimalauflösung
#>
#>Ist 0.
#>
#># - Maximalauflösung
#>
#>Warum nach oben begrenzen?
#>
#># - minimal garantierte Zeitspanne
#>
#>Ist 0.
#>
# Was will ich mit so einer Funktion?
Ist das so schwer zu begreifen? Sie dort benutzen, wo sie mehr garantiert.
Und nicht benutzen, wo sie es nicht tut.
# Was ist das für ein architektonischer Dummfug?
Was ist das für ein unsachlicher Einwand?
# Wenn in der Baustatik so gearbeitet würde, dann gäbe es jährlich zigtausende
# Tote.
Warum? Der Bauingenieur (Programmierer) der sein Geld Wert ist, kennt
seine Materialien (Standards und deren Garantien). Es ist kein Fehler
der Sprache, wenn sie außerhalb der Spec betrieben wird, genausowenig
wie es ein Materialfehler ist, wenn die Brücke unter der eigenen Last
zusammenbricht.
Wenn Compiler für alle Systeme die gesammelten Vorlieben der Person X
implementieren müßten, gäbe es heute noch keinen. Und Bauingenieure
würden zum Ausbaggern eines Kellers einen Braunkohlebagger anschleppen.
Vielen Dank für den Vergleich :-)
#>Nö. Es ist einfach nicht Aufgabe von ISO C. Es gibt weitergehende
#>Standards wie POSIX, die hier mehr festlegen. Lies diese, benutze
#>diese.
# Was will ich mit so einem Murks anfangen? Wie will ich Programme evaluieren?
Ich kann mit nichtexistenten Compilern nichts anfangen. Wie will ich
Programme schreiben? Kannst Du Dir vorstellen, daß es Systeme gibt, die
keine Zeitzähler haben und wo das auch völlig unnötig ist?
# Dagegen ist Treibsatz ja was hochstabiles!
Ich weiß jetzt nicht, was das mit Stabilität zu tun hat. Nur so viel:
Eine C Standard Library ist umso stabiler, je weniger Umfang sie hat. Es
ist ein Naturgesetz, daß die Anzahl der Bugs mit der Anzahl der Zeilen
in etwa proportional ist.
Jens Schweikhardt
in <3B975880...@t-online.de>:
#
# Jens Schweikhardt wrote:
#>
#> Helmut Schellong <sche...@t-online.de> wrote
#> in <3B965860...@t-online.de>:
#> #> # Ich hatte *nicht* wörtlich zitiert: ".........."
#> #>
#> #> Wundert mich nicht, da Du überhaupt nichts Relevantes zitiert hast. Es
#> #> aus, clock() würde immer und unbedingt die Zeit seit Programmstart
#> #> liefern.
#> #
#> # Doch. Die entsprechenden Postings hatte ich inhaltlich gepostet.
#> Nein. Ein Zitat aus einen Kochrezept hat genauso viel Belegkraft für
#> Deine Behauptung, irgendjemand hätte gemeint, der Standard sage aus,
#> clock() würde immer und unbedingt die Zeit seit Programmstart liefern.
#
#
# Vielleicht fällt es jetzt auf:
# -----------------------------------------------------------------
#> clock() liefert diejenige Zeit, die seit einem vorherigen Aufruf
#> von clock() vergangen ist.
Also das ist offensichtlich verschieden von "der Standard sage aus,
clock() würde immer und unbedingt die Zeit seit Programmstart liefern."
# | 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 ist auch verschieden von "der Standard sage aus, clock() würde immer
und unbedingt die Zeit seit Programmstart liefern."
Frank Klemm
unendlich lang.
clock () = clock_anfang () + Zeitspanne * CLOCKS_PER_SEC
ist dort prinzipiell immer garantiert.
2. Also ist die garantierte Zeitspanne für Systeme mit garantierter
Funktion 0. Das ist vollständig unbrauchbar.
># Wenn in der Baustatik so gearbeitet würde, dann gäbe es jährlich zigtausende
># Tote.
>
> Warum? Der Bauingenieur (Programmierer) der sein Geld Wert ist, kennt
> seine Materialien (Standards und deren Garantien). Es ist kein Fehler
> der Sprache, wenn sie außerhalb der Spec betrieben wird, genausowenig
> wie es ein Materialfehler ist, wenn die Brücke unter der eigenen Last
> zusammenbricht.
>
Stell' Dir vor es gäbe in der Baustatik nur Materialien wie:
* Strohballen
* Eisblöcke
* Blöcke aus Natrium
* Luftballons
und Du sollst damit eine Zivilisation aufbauen.
Man sollte sofort den Beruf wechseln.
> Wenn Compiler für alle Systeme die gesammelten Vorlieben der Person X
> implementieren müßten, gäbe es heute noch keinen.
>
Ja. Richtig.
> Und Bauingenieure
> würden zum Ausbaggern eines Kellers einen Braunkohlebagger anschleppen.
>
Es geht eher um Grundmaterialien, nicht um komplexe technische Gebilde wie
ganze Applikationen. C sollte keinen Textprozessor innerhalb der Sprache
haben. Bezogen auf die Bauindustrie hätte ich gerne Dinge wie:
- Glas
- Holz
- Stahl
- Beton
Daraus kann ich mir dann alles wichtige selbst herstellen.
Aber nicht aus
- Strohballen
- Eisblöcke
- Blöcke aus Natrium
- Luftballons
Es fehlen elementare Dinge.
> Vielen Dank für den Vergleich :-)
>
>#>Nö. Es ist einfach nicht Aufgabe von ISO C. Es gibt weitergehende
>#>Standards wie POSIX, die hier mehr festlegen. Lies diese, benutze
>#>diese.
># Was will ich mit so einem Murks anfangen? Wie will ich Programme evaluieren?
>
> Ich kann mit nichtexistenten Compilern nichts anfangen.
>
Dummfug. Du willst nicht denken. Du bist götzenhaft in C bis über beide Ohren verliebt.
Ich beziehe mich mal im nächsten nur auf die Sprache C im Sinne von Ada (die Sprache,
nicht die Bibliotheken):
- Ein Compiler besteht aus mindestens zwei Teilen
* Syntax+Sematik analysieren und daraus eine RTL-Beschreibung generieren (1)
* optional: Optimierer der RTL (2)
* Codegenerator (3)
- Der Compiler ist nur ein kleiner Teil einer Entwicklungsumgebung.
- (1) ist für alle Systeme identisch, wenn die Compilerhersteller nicht
gezwungen werden, Schwalbenkolonien zu basteln
- in (2) steckt heutzutage der meiste Aufwand (Tendenz steigend),
er ist für Sprachen wie C, Pascal, Fortran, Ada, Algol u.s.w.
identisch.
- (2) und (3) muß auf einem System existieren, wenn es auf diesem System C gibt.
Was ist jetzt das Problem, eine heftig komplizierte Sprache zu entwickeln,
eine gute Referenzimplementation dieser EINMAL zu schreiben, die sie in RTL
übersetzt. Diese Sprache existiert dann automatisch für alle Systeme, für
die ein modular aufgebauter C-Compiler existiert.
Die Bemerkung "Ich kann mit nichtexistenten Compilern nichts anfangen" halte ich
für Dummenfang. Ich will nicht, also geht das nicht.
Mit der gleichen Hartnäckigkeit hat man sich Anfang des 19. Jh. gegen
die Standardisierung von Schrauben und Muttern gewehrt. Dort würde ich
Softwaremanufakturen auch entwicklungsgeschichtlich einsortieren.
> Wie will ich
> Programme schreiben? Kannst Du Dir vorstellen, daß es Systeme gibt, die
> keine Zeitzähler haben und wo das auch völlig unnötig ist?
>
Wenn die Sprache etwas umfangreicher wäre, würde es nochlange keine Compiler
geben. Ich hatte außerdem schon mal den Vorschlag einer garantierten
Grundfunktionalität und möglichen Erweiterungen gemacht.
Reale C Compiler sind ein unbeschreiblicher Wust an Wildwuchs. Mit der
Kernfunktionalität von C kann man nicht viel anfangen, derwegen erweitert
jeder diese "Sprache" ins einer Weise. Die eigentliche Sprache ist nur noch
ein winziges Gerippe inmitten eines komplexen Systems.
Es sind Dinge nicht realisiert, die JEDER C-Compiler können muß.
Beweis ist, daß man es in C implementieren kann. Allerdings steht hochgradig
ineffizienter Code. Das einfachste Beispiel:
Nenne mir einen Grund, warum sleep() nicht Teil von ANSI-C ist:
#include <time.h>
int sleep ( time_t sec )
{
time_t t = time (NULL) + sec;
while ( time(NULL) < t )
;
return 0;
}
--
Frank Klemm
Holger Berger
wrote:
>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.
Also ich habe den Thread jetzt gerade komplett und am Stueck gelesen,
und mir ist noch KEIN Posting aufgefallen, in dem diese Behauptung
von irgendjemanden aufgestellt wurde. Allerdings unterstellt Du hier staendig
aenderen Leuten, dass Sie das behaupten wuerden.
Ich HABE allerdings ein Posting gelesen, in dem Du schreibst, dass Du clock()
seit langen Jahren benutzt, und daher weisst, dass es beim ersten Aufruf
immer 0 liefert.
Das wurde durch ein Beispiel von Jenz auf einer FreeBSD Maschine leicht
widerlegt.
Was also soll der ganze Thread?
JEDER ist der Meinung, das man clock auf jeden Fall zweimal aufrufen muss,
wenn man eine Zeitspanne messen will.
Nur einer ist der Meinung, das clock() beim ersten Mal immer 0 liefert,
was schon widerlegt wurde.
>
>Der Standard erlaubt, daß clock() initialisiert werden muß,
>und genau so ist es auch oft in der Praxis.
Nein. Du kannst den ersten Wert von clock verwenden.
Du hast nur leider keine Ahnung, wann der beginn des Zeitintervalls
war, dessen Ende der Wert liefert.
Du weisst aber, dass er vom Programmstart abhaengt.
Gut - damit kann man nichts sinnvolles mit clock machen. Aber kann
Ihn verwenden :-)
Man muss clock nicht "initialisieren".
>Das 0-Thema gibt es nur, weil es beweist, daß clock() eben
>oft nicht die Zeit seit Programmstart liefert.
>
Was ja keiner behauptet (gaehn). Man behauptet nur (weils im Standard steht)
das clock() in einem Zusammenhang mit dem Programmstart steht.
--
no signature left on device
Helmut Schellong
>
> On Tue, 04 Sep 2001 10:57:54 +0200, Helmut Schellong <sche...@t-online.de>
> wrote:
> >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.
>
> Also ich habe den Thread jetzt gerade komplett und am Stueck gelesen,
> und mir ist noch KEIN Posting aufgefallen, in dem diese Behauptung
> von irgendjemanden aufgestellt wurde. Allerdings unterstellt Du hier staendig
> aenderen Leuten, dass Sie das behaupten wuerden.
>
> Ich HABE allerdings ein Posting gelesen, in dem Du schreibst, dass Du clock()
> seit langen Jahren benutzt, und daher weisst, dass es beim ersten Aufruf
> immer 0 liefert.
Das habe ich beispielsweise *nicht* geschrieben.
Ich hatte von einem Regelfall geredet und direkt darunter explizit
geschrieben, daß der Startwert 0 *nicht* garantiert sei.
> >Der Standard erlaubt, daß clock() initialisiert werden muß,
> >und genau so ist es auch oft in der Praxis.
> Nein. Du kannst den ersten Wert von clock verwenden.
> Du hast nur leider keine Ahnung, wann der beginn des Zeitintervalls
> war, dessen Ende der Wert liefert.
> Du weisst aber, dass er vom Programmstart abhaengt.
> Gut - damit kann man nichts sinnvolles mit clock machen. Aber kann
> Ihn verwenden :-)
> Man muss clock nicht "initialisieren".
Laut Standard nicht, der das aber erlaubt.
Auf den meisten meiner diversen Systeme MUSS ich initialisieren!
Erst nach einem initialisierenden ersten Aufruf liefert clock()
eine Zeit, der erste Aufruf liefert *immer* 0, egal wann er kommt.
Bei diesem Verhalten ist es doch ganz klar, daß der Startaufruf
den Mechanismus freischaltet.
Du solltest beachten, daß die man-Page Vorrang vor dem Standard-Text
hat.
Jens Schweikhardt
in <slrn9pgtd...@c.zeiss.de>:
...
#># Wenn in der Baustatik so gearbeitet würde, dann gäbe es jährlich zigtausende
#># Tote.
#>
#> Warum? Der Bauingenieur (Programmierer) der sein Geld Wert ist, kennt
#> seine Materialien (Standards und deren Garantien). Es ist kein Fehler
#> der Sprache, wenn sie außerhalb der Spec betrieben wird, genausowenig
#> wie es ein Materialfehler ist, wenn die Brücke unter der eigenen Last
#> zusammenbricht.
#>
# Stell' Dir vor es gäbe in der Baustatik nur Materialien wie:
#
# * Strohballen
# * Eisblöcke
# * Blöcke aus Natrium
# * Luftballons
#
# und Du sollst damit eine Zivilisation aufbauen.
# Man sollte sofort den Beruf wechseln.
Wenn ich auch mal hinken darf:
Stell Dir vor es gäbe in der Baustatik nur Materialien wie:
* Verchromten Stahl
* Carbonfasern
* Blöcke aus Spaceshuttlekacheln
* Sekundenkleber
Du sollst damit ein Haus aufbauen, aber natürlich das Budget von ein
paar Lire nicht überschreiten. Da gehst Du doch lieber zu Obi und holst
ein paar Ziegel, Holzbalken, Mörtel und hast zum Schluß noch was über.
...
# Die Bemerkung "Ich kann mit nichtexistenten Compilern nichts anfangen" halte ich
# für Dummenfang. Ich will nicht, also geht das nicht.
Dann erkläre ich den Gedanken nochmal ausdrücklich: Warum sollte ISO C -
der am wenigsten umfangreiche C Standard, ausgelegt auf weite und
einfache Implementierbarkeit - ein Konzept namens "Uhr" verlangen, das
viele Implementierer vor eine unüberwindbare Hürde stellt? Eine Uhr
*ist* Luxus auf vielen Systemen.
Nenne mir einen Grund, warum diese Anforderungen nicht besser bei
POSIX aufgehoben sind.
...
# Nenne mir einen Grund, warum sleep() nicht Teil von ANSI-C ist:
Weil es eine funktionierende interne Uhr erfordert.
Frank Klemm
>
> Nenne mir einen Grund, warum diese Anforderungen nicht besser bei
> POSIX aufgehoben sind.
>
time() stellt mindestens die gleichen Anforderungen an ein System wie
clock(). Sie stellt sogar höhere Anforderungen, die auf einem IBM-XT nicht
ohne weiteres erfüllbar sind.
sleep() kann man mit time() in multitaskingschädlicher Weise immer
implementieren. Auf Singletasking-OS ist das dann auch die Art und Weise der
internen Implementierung, bei Multitasking-OS gibt es IMMER einen
entsprechenden Systemruf.
># Nenne mir einen Grund, warum sleep() nicht Teil von ANSI-C ist:
>
>Weil es eine funktionierende interne Uhr erfordert.
>
Das erfordert time() auch. Diese muß sogar kalibriert sein.
sleep() läßt sich auf einem billigen DDR-Heimcomputer problemlos
implementieren. time() hingegen nicht.
sleep() ist POSIX.
time() ist ANSI-C.
Völlig unverständlich von technischen Standpunkt aus.
Nur verständlich, wenn man das ganze vom menschlichen Standpunkt aus
betrachtet und sich den ganzen anderen Wirrwarr ansieht, der nichts
mit Hardware zu tun hat.
--
Frank Klemm