clock_t clock() ambiguity

[Matt]

Does clock_t clock() measure real time or process time? Unless I have
missed something, Stroustrup's treatment in TC++PL (section D.4.4.1) is
none too clear on that question.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

[Phlip]

Matt wrote:

Does clock_t clock() measure real time or process time? Unless I have
missed something, Stroustrup's treatment in TC++PL (section D.4.4.1) is
none too clear on that question.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

http://msdn.microsoft.com/library/de..._crt_clock.asp

Note the compatibility is "ANSI", which is MS's code for the "ISO C
Standard". All compilers worth using will have it.

Then note the first line is "Calculates the wall-clock time used by the
calling process." That "wall-clock" is jargon for real time, not process
time. And "used by the calling process" means the "epoch" starts when the
program starts.

In future, please hit a question with Google before posting it! I answered
all your questions with the first citation for [msdn clock_t].

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[mlimber]

Matt wrote:

Does clock_t clock() measure real time or process time? Unless I have
missed something, Stroustrup's treatment in TC++PL (section D.4.4.1) is
none too clear on that question.

IIRC, it's not defined by the C or C++ standards. Neither language has
the inherent concept of real time vs. process time, so implementations
will vary from platform to platform.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

Depends on what you mean by "well-implemented." The function is
required by the standard, yes, but does it function the same
everywhere? No.

Cheers! --M

[Kai-Uwe Bux]

Matt wrote:

Does clock_t clock() measure real time or process time? Unless I have
missed something, Stroustrup's treatment in TC++PL (section D.4.4.1) is
none too clear on that question.

C++ inherits clock() from the standard C header time.h. The publicly
available draft of the C standard says:

7.23.2.1 The clock function

Synopsis
1 #include <time.h>
clock_t clock(void);

Description
2 The clock function determines the processor time used.

Returns
3 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. To
determine the time in seconds, the value returned by the clock function
should be divided by the value of the macro CLOCKS_PER_SEC. If the
processor time used is not available or its value cannot be represented,
the function returns the value (clock_t)-1.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

I don't know, and I think it is not topical in this group.
Best

Kai-Uwe Bux

[Phlip]

Kai-Uwe Bux wrote:

3 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. To
determine the time in seconds, the value returned by the clock function
should be divided by the value of the macro CLOCKS_PER_SEC. If the
processor time used is not available or its value cannot be represented,
the function returns the value (clock_t)-1.

Oh-kay. The MSDN page I cited claimed "wall-clock" time. Processor time is
available, inside Win32, but not used. The page did not claim the function
returns (clock_t)-1, despite the processor time is not available to the
program.

Is there a language lawyer in the house??

>Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

I don't know, and I think it is not topical in this group.

It's not topical on any other group, either, by the same logic.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Default User]

Phlip wrote:

Matt wrote:

Does clock_t clock() measure real time or process time? Unless I
have missed something, Stroustrup's treatment in TC++PL (section
D.4.4.1) is none too clear on that question.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows,
and MacOS?

http://msdn.microsoft.com/library/de...ry/en-us/vclib
/html/_crt_clock.asp

Note the compatibility is "ANSI", which is MS's code for the "ISO C
Standard". All compilers worth using will have it.

Then note the first line is "Calculates the wall-clock time used by
the calling process." That "wall-clock" is jargon for real time, not
process time. And "used by the calling process" means the "epoch"
starts when the program starts.

That's not what it says, and that's not right.

"The clock function tells how much time the calling process has used."

It is not the wall time, it's the process time.

In future, please hit a question with Google before posting it! I
answered all your questions with the first citation for [msdn
clock_t].

Unfortunately, you answered them incorrectly.

Brian

[Default User]

mlimber wrote:

Matt wrote:

Does clock_t clock() measure real time or process time? Unless I
have missed something, Stroustrup's treatment in TC++PL (section
D.4.4.1) is none too clear on that question.

IIRC, it's not defined by the C or C++ standards. Neither language has
the inherent concept of real time vs. process time, so implementations
will vary from platform to platform.

From the C99 draft standard:

7.23.2.1 The clock function

Synopsis

[#1]

#include <time.h>
clock_t clock(void);

Description

[#2] The clock function determines the processor time used.

Returns

[#3] 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. To determine the time in
seconds, the value returned by the clock function should be
divided by the value of the macro CLOCKS_PER_SEC. If the
processor time used is not available or its value cannot be
represented, the function returns the value (clock_t)-1.252)

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

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows,
and MacOS?

Depends on what you mean by "well-implemented." The function is
required by the standard, yes, but does it function the same
everywhere? No.

No, but it should be reasonably close. Unlike tine(), the semantics for
clock() are fairly well defined. It does waffle a bit, with "best
approximation", but it's not unspecified like time() and time_t.


Brian

[Phlip]

Default User wrote:

"The clock function tells how much time the calling process has used."

It is not the wall time, it's the process time.

Despite, uh, saying "wall" time at the top of the page?

Please Google [wall-clock time]. If it's meaning isn't related to the
movement of a clock's hands while the program runs, then I'm wrong.
Otherwise, the MSDN page is inconsistent with itself.

A Win32 test involving Sleep() and two clock() calls would instantly answer
questions about the actual implementation.

And please be more careful with your own claims.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Default User]

Phlip wrote:

Default User wrote:

"The clock function tells how much time the calling process has
used."

It is not the wall time, it's the process time.

Despite, uh, saying "wall" time at the top of the page?

It's poorly (or incorrectly) worded in that section. The Remarks and
the example code get it right.

Please Google [wall-clock time]. If it's meaning isn't related to the
movement of a clock's hands while the program runs, then I'm wrong.

I know what it means, but that not what clock() measures. That's what
time() measures.

Otherwise, the MSDN page is inconsistent with itself.

Good thing it's not the Standard.

A Win32 test involving Sleep() and two clock() calls would instantly
answer questions about the actual implementation.

And please be more careful with your own claims.

As you're incorrect, I'd watch the atty-tude.

Brian

[Kai-Uwe Bux]

Phlip wrote:

Kai-Uwe Bux wrote:

>3 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. To
determine the time in seconds, the value returned by the clock function
should be divided by the value of the macro CLOCKS_PER_SEC. If the
processor time used is not available or its value cannot be represented,
the function returns the value (clock_t)-1.

Oh-kay. The MSDN page I cited claimed "wall-clock" time.

If so, that page is mistaken or describes a non-compliant implementation of
clock(). Pick your poison.

Processor time is available, inside Win32, but not used.

Huh? And that relates to the clock() function in C or C++ like how?

The page did not claim the function returns (clock_t)-1, despite the
processor time is not available to the program.

Is there a language lawyer in the house??

I think, no lawyer is needed. The quote from the draft standard is pretty
clear, isn't it? I do not have a copy of the final version, but I would not
imagine that it changed substantially.

>>Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

I don't know, and I think it is not topical in this group.

It's not topical on any other group, either, by the same logic.

Well, that's too bad then. How about splittig the question and asking in a
Linux forum about Linux, in a Windows forum about Windows, in a gcc forum
about gcc, ...?
Best

Kai-Uwe Bux

[Ian Collins]

Phlip wrote:

Default User wrote:

>>"The clock function tells how much time the calling process has used."

It is not the wall time, it's the process time.

Despite, uh, saying "wall" time at the top of the page?

Please Google [wall-clock time]. If it's meaning isn't related to the
movement of a clock's hands while the program runs, then I'm wrong.
Otherwise, the MSDN page is inconsistent with itself.

A Win32 test involving Sleep() and two clock() calls would instantly answer
questions about the actual implementation.

And please be more careful with your own claims.

Brian's claim is correct.

From C99 7.23.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.

--
Ian Collins.

[Matt]

Phlip wrote:

Matt wrote:

>>Does clock_t clock() measure real time or process time? Unless I have
missed something, Stroustrup's treatment in TC++PL (section D.4.4.1) is
none too clear on that question.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows, and
MacOS?

http://msdn.microsoft.com/library/de..._crt_clock.asp

Note the compatibility is "ANSI", which is MS's code for the "ISO C
Standard". All compilers worth using will have it.

Then note the first line is "Calculates the wall-clock time used by the
calling process." That "wall-clock" is jargon for real time, not process
time. And "used by the calling process" means the "epoch" starts when the
program starts.

In future, please hit a question with Google before posting it! I answered
all your questions with the first citation for [msdn clock_t].

Thanks for your answers to all my two questions!

Your answer to my first question was wrong.

Your answer to my second question was nonexistent.

[Victor Bazarov]

Matt wrote:

Phlip wrote:

>Matt wrote:

>>Does clock_t clock() measure real time or process time? Unless I
have missed something, Stroustrup's treatment in TC++PL (section
D.4.4.1) is none too clear on that question.

Is clock() well-implemented for the major compilers g++, VC++, and
Macintosh compilers and other C++ compilers on Linux/Unix, Windows,
and MacOS?

http://msdn.microsoft.com/library/de..._crt_clock.asp

Note the compatibility is "ANSI", which is MS's code for the "ISO C
Standard". All compilers worth using will have it.

Then note the first line is "Calculates the wall-clock time used by
the calling process." That "wall-clock" is jargon for real time, not
process time. And "used by the calling process" means the "epoch"
starts when the program starts.

In future, please hit a question with Google before posting it! I
answered all your questions with the first citation for [msdn
clock_t].

Thanks for your answers to all my two questions!

Your answer to my first question was wrong.

In what way was it "wrong"? You asked "real time or process time"? The
answer was 'wall-clock' and the explanation given that it is "real time
not process time". How in hell is it "wrong"?

Your answer to my second question was nonexistent.

The asnwer to your second question was "All complers worth using will have
it". To me it means "implemented". As to "well" or "not well", we cannot
tell -- it's implementation-specific and we don't discuss implementations.
Most compilers have their own newsgroups, consider posting there. Also,
if you need information on "other compilers for <blahplatform", please
consider asking in the newsgroup[s] dedicated to the platform[s].

Also, complaining about free advice is non-sensical. You asked a question,
you received _a_ response. Take it or leave it, don't bitch about it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[peter koch]

Matt wrote:

Does clock_t clock() measure real time or process time?

[snip]

To add to the confusion, I have just tested a program using clock() on
Solaris and Windows NT. On both platforms clock() did seem to give
wall-clock (that is elapsed) time - the same result as is available
with gettickcount() on windows and time() on Solaris.
To get processor time, I had to use GetProcessInfo on Windows and
getrusage on Solaris (not 100% confident on those last names - i do not
have the code present).

/Peter

[Phlip]

peter koch wrote:

Matt wrote:

>Does clock_t clock() measure real time or process time?

To add to the confusion, I have just tested a program using clock() on
Solaris and Windows NT. On both platforms clock() did seem to give
wall-clock (that is elapsed) time - the same result as is available
with gettickcount() on windows and time() on Solaris.
To get processor time, I had to use GetProcessInfo on Windows and
getrusage on Solaris (not 100% confident on those last names - i do not
have the code present).

Did your test use a Sleep(big number)? Sleep's documentation claims it
suspends the CPU activity for a process...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[peter koch]

Phlip wrote:

peter koch wrote:

Matt wrote:

Does clock_t clock() measure real time or process time?

To add to the confusion, I have just tested a program using clock() on
Solaris and Windows NT. On both platforms clock() did seem to give
wall-clock (that is elapsed) time - the same result as is available
with gettickcount() on windows and time() on Solaris.
To get processor time, I had to use GetProcessInfo on Windows and
getrusage on Solaris (not 100% confident on those last names - i do not
have the code present).

Did your test use a Sleep(big number)? Sleep's documentation claims it
suspends the CPU activity for a process...

Yes. I did measure a few busy loops (calculating e.g. sin() repeatedly)
and one sleep for app. six seconds. The results were consistent: clock
gave same result as gettickcount on windows, whereas GetProcessInfo
gave the same results on the busy loops and 0 when calling Sleep.

/Peter

>
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Phlip]

peter koch wrote:

Yes. I did measure a few busy loops (calculating e.g. sin() repeatedly)
and one sleep for app. six seconds. The results were consistent: clock
gave same result as gettickcount on windows, whereas GetProcessInfo
gave the same results on the busy loops and 0 when calling Sleep.

Thanks. You have restored my faith in MSDN.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[mlimber]

Default User wrote:

mlimber wrote:

Matt wrote:

Does clock_t clock() measure real time or process time? Unless I
have missed something, Stroustrup's treatment in TC++PL (section
D.4.4.1) is none too clear on that question.

IIRC, it's not defined by the C or C++ standards.

From the C99 draft standard:

[snip]

Apparently, IIRC = I didn't recall correctly. ;-)

Cheers! --M

[peter koch]

Phlip wrote:

peter koch wrote:

Yes. I did measure a few busy loops (calculating e.g. sin() repeatedly)
and one sleep for app. six seconds. The results were consistent: clock
gave same result as gettickcount on windows, whereas GetProcessInfo
gave the same results on the busy loops and 0 when calling Sleep.

Thanks. You have restored my faith in MSDN.

>From the other posts it seems to me that Windows NT as well as Solaris

got it wrong. This also explains my collegues surprise when I told them
that clock() returns elapsed time - they thought that clock() returned
processortime.
Could it be that Solaris and Windows NT shares a flawed codebase from
some time in the distant past?

/Peter

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Default User]

Phlip wrote:

peter koch wrote:

Yes. I did measure a few busy loops (calculating e.g. sin()
repeatedly) and one sleep for app. six seconds. The results were
consistent: clock gave same result as gettickcount on windows,
whereas GetProcessInfo gave the same results on the busy loops and
0 when calling Sleep.

Thanks. You have restored my faith in MSDN.

I'm not sure what faith. The documentation is either inconsistent,
confusing, or just wrong.

This whole conversation seemed somewhat familiar, a bit of Groupling
came up with this:

<http://groups.google.com/group/comp....hread/fb0f9076
19ac71fe/7a52324dcae9a6fd>
Victor said then that Microsoft screwed up the implementation of
clock() in Visual Studio, and my little experiment seemed to confirm
that.

Brian

[Phlip]

peter koch wrote:

Could it be that Solaris and Windows NT shares a flawed codebase from
some time in the distant past?

I always suspected WinNT's clock() to return wall-clock time for a simple
reason: The function has only an 18 millisecond resolution, or some high
number like that. So if it's already useless for timing and profiling, then
there's no point in making it return processor time.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Matt]

Default User wrote:

Phlip wrote:

>>peter koch wrote:

>>>Yes. I did measure a few busy loops (calculating e.g. sin()
repeatedly) and one sleep for app. six seconds. The results were
consistent: clock gave same result as gettickcount on windows,
whereas GetProcessInfo gave the same results on the busy loops and
0 when calling Sleep.

Thanks. You have restored my faith in MSDN.

I'm not sure what faith. The documentation is either inconsistent,
confusing, or just wrong.

This whole conversation seemed somewhat familiar, a bit of Groupling
came up with this:

<http://groups.google.com/group/comp....hread/fb0f9076
19ac71fe/7a52324dcae9a6fd>

Thanks for that link. It came up mangled in my browser. Hope this works:
http://groups.google.com/group/comp....52324dcae9a6fd

>
Victor said then that Microsoft screwed up the implementation of
clock() in Visual Studio, and my little experiment seemed to confirm
that.

Brian

[Matt]

Victor Bazarov wrote:

it's implementation-specific and we don't discuss implementations.

Okay, if you insist on being impractical, I am proposing a standard
replacement for clock_t clock(). The rationale is that Microsoft and
possibly others seem to have ruined clock()'s meaning and its usefulness
for cross-platform development. I propose we call it cpu_clock() or
maybe correct_clock() or lets_hope_ms_gets_it_right_this_time_clock().

Sheesh.

[Victor Bazarov]

Matt wrote:

Victor Bazarov wrote:

>it's implementation-specific and we don't discuss implementations.

Okay, if you insist on being impractical,

No, I insist on being on topic. If you have some complaints about some
implementations, take it up with the creator of those implementations.
Bitching about it here is not going to help.

I am proposing a standard
replacement for clock_t clock(). The rationale is that Microsoft and
possibly others seem to have ruined clock()'s meaning and its
usefulness for cross-platform development. I propose we call it
cpu_clock() or maybe correct_clock() or
lets_hope_ms_gets_it_right_this_time_clock().
Sheesh.

Whatever.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Matt]

Victor Bazarov wrote:

Also, complaining about free advice is non-sensical. You asked a question,
you received _a_ response. Take it or leave it, don't bitch about it.

I would hope that anybody who posts on usenet has higher expectations
than that. I know that there are a lot who don't, but if you don't want
more than that, what are you doing here and what do you think others are
doing here?

Now don't get non-sensical about my post. Please take my post or leave
it and don't bitch about it. :-)

[Default User]

Matt wrote:

Default User wrote:

This whole conversation seemed somewhat familiar, a bit of Groupling
came up with this:

Thanks for that link. It came up mangled in my browser.

Yes, my newsreader does that in standard mode. I can switch to another
mode, but it does other things I don't like.


Brian

[peter koch]

Default User skrev:

Phlip wrote:

peter koch wrote:

Yes. I did measure a few busy loops (calculating e.g. sin()
repeatedly) and one sleep for app. six seconds. The results were
consistent: clock gave same result as gettickcount on windows,
whereas GetProcessInfo gave the same results on the busy loops and
0 when calling Sleep.

Thanks. You have restored my faith in MSDN.

I'm not sure what faith. The documentation is either inconsistent,
confusing, or just wrong.

This whole conversation seemed somewhat familiar, a bit of Groupling
came up with this:

<http://groups.google.com/group/comp....hread/fb0f9076
19ac71fe/7a52324dcae9a6fd>

I just read that - interestimng. I just wonder how my investigations
on Solaris (also gcc .... 3.2 so far as i remember) made me conclude
that clock() is elapsed time there as well. I also had one large sleep
for about five seconds.

/Peter

>

Victor said then that Microsoft screwed up the implementation of
clock() in Visual Studio, and my little experiment seemed to confirm
that.

Brian

[trm]

Default User schrieb:

Unlike tine(), the semantics for clock() are fairly well defined.

But it doesn't matter, as fork() and its brethren are OT for clc++.

:p

[Default User]

trm wrote:

Default User schrieb:

Unlike tine(), the semantics for clock() are fairly well defined.

But it doesn't matter, as fork() and its brethren are OT for clc++.

Heh.

Brian

[Default User]

peter koch wrote:

>
Default User skrev:

Phlip wrote:

peter koch wrote:
>
Yes. I did measure a few busy loops (calculating e.g. sin()
repeatedly) and one sleep for app. six seconds. The results were
consistent: clock gave same result as gettickcount on windows,
whereas GetProcessInfo gave the same results on the busy loops
and 0 when calling Sleep.
>
Thanks. You have restored my faith in MSDN.

I'm not sure what faith. The documentation is either inconsistent,
confusing, or just wrong.

This whole conversation seemed somewhat familiar, a bit of Groupling
came up with this:

Here's the compiler/OS info for my test:

Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/3.3.1/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/l
d --disable-nls
Thread model: posix
gcc version 3.3.1

I just read that - interestimng. I just wonder how my investigations
on Solaris (also gcc .... 3.2 so far as i remember) made me conclude
that clock() is elapsed time there as well. I also had one large sleep
for about five seconds.

[Default User]

Default User wrote:

peter koch wrote:

I just read that - interestimng. I just wonder how my
investigations on Solaris (also gcc .... 3.2 so far as i remember)
made me conclude that clock() is elapsed time there as well. I also
had one large sleep for about five seconds.

Here's the compiler/OS info for my test:

Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/3.3.1/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/l
d --disable-nls
Thread model: posix
gcc version 3.3.1

Sorry about that, accidentally posted before finishing the edit. It
should look a bit cleaner now.

Brian