Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #94821 > unrolled thread

CLOCKS_PER_SEC

Back to article view | Back to comp.lang.c

Contents

  CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-13 14:49 +0100
    Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 08:57 -0700
      Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 09:07 -0700
        Re: CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-13 23:18 +0100
          Re: CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-13 23:30 +0100
            Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 16:27 -0700
              Re: CLOCKS_PER_SEC raltbos@xs4all.nl (Richard Bos) - 2016-10-16 10:02 +0000
                Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-16 11:32 -0700
      Re: CLOCKS_PER_SEC Lowell Gilbert <lgusenet@be-well.ilk.org> - 2016-10-13 12:19 -0400
        Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 11:29 -0700
          Re: CLOCKS_PER_SEC Lowell Gilbert <lgusenet@be-well.ilk.org> - 2016-10-13 14:39 -0400
            Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 12:03 -0700
          Re: CLOCKS_PER_SEC supercat@casperkitty.com - 2016-10-14 07:47 -0700
    Re: CLOCKS_PER_SEC Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-14 16:21 +0300
      Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-14 08:41 -0700
        Re: CLOCKS_PER_SEC Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-14 18:56 +0300
          Re: CLOCKS_PER_SEC Barry Schwarz <schwarzb@dqel.com> - 2016-10-14 09:49 -0700
          Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-14 11:14 -0700
            Re: CLOCKS_PER_SEC supercat@casperkitty.com - 2016-10-14 11:32 -0700
        Re: CLOCKS_PER_SEC Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-14 11:56 -0400
          Re: CLOCKS_PER_SEC Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-14 19:53 +0300
            Re: CLOCKS_PER_SEC supercat@casperkitty.com - 2016-10-14 09:57 -0700
            Re: CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-14 18:18 +0100
          Re: CLOCKS_PER_SEC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 02:55 -0700

Page 1 of 2  [1] 2  Next page →

#94821 — CLOCKS_PER_SEC

CLOCKS_PER_SEC determines how the result of the clock() function is 
interpreted.

But it seems to be defined as macro in time.h.

Any ideas on how to determine that value when calling clock() as foreign 
function from another language? I want to avoid OS-specific functions 
unless they are available on both Windows and Linux.

(At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and 
1000000 on Linux. I suppose I could detect abnormally large values of 
clock() and infer it that way, but I think there will be some overlap in 
the set of valid results.)

-- 
Bartc

[toc] | [next] | [standalone]

#94830

BartC <bc@freeuk.com> writes:
> CLOCKS_PER_SEC determines how the result of the clock() function is 
> interpreted.
>
> But it seems to be defined as macro in time.h.
>
> Any ideas on how to determine that value when calling clock() as foreign 
> function from another language? I want to avoid OS-specific functions 
> unless they are available on both Windows and Linux.
>
> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and 
> 1000000 on Linux. I suppose I could detect abnormally large values of 
> clock() and infer it that way, but I think there will be some overlap in 
> the set of valid results.)

Write a C function that returns the value of the macro, and call that
function from the foreign language.  Depending on your build system, you
can probably do this at configuration time rather than at run time.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94831

Keith Thompson <kst-u@mib.org> writes:
> BartC <bc@freeuk.com> writes:
>> CLOCKS_PER_SEC determines how the result of the clock() function is 
>> interpreted.
>>
>> But it seems to be defined as macro in time.h.
>>
>> Any ideas on how to determine that value when calling clock() as foreign 
>> function from another language? I want to avoid OS-specific functions 
>> unless they are available on both Windows and Linux.
>>
>> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and 
>> 1000000 on Linux. I suppose I could detect abnormally large values of 
>> clock() and infer it that way, but I think there will be some overlap in 
>> the set of valid results.)
>
> Write a C function that returns the value of the macro, and call that
> function from the foreign language.  Depending on your build system, you
> can probably do this at configuration time rather than at run time.

Or perhaps write a small C program that prints the value of
CLOCKS_PER_SEC, and compile it and capture its output during your
build process.

This assumes the build is done on the target system, which might not
always be the case.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94847

On 13/10/2016 17:07, Keith Thompson wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> BartC <bc@freeuk.com> writes:
>>> CLOCKS_PER_SEC determines how the result of the clock() function is
>>> interpreted.
>>>
>>> But it seems to be defined as macro in time.h.
>>>
>>> Any ideas on how to determine that value when calling clock() as foreign
>>> function from another language? I want to avoid OS-specific functions
>>> unless they are available on both Windows and Linux.
>>>
>>> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and
>>> 1000000 on Linux. I suppose I could detect abnormally large values of
>>> clock() and infer it that way, but I think there will be some overlap in
>>> the set of valid results.)
>>
>> Write a C function that returns the value of the macro, and call that
>> function from the foreign language.  Depending on your build system, you
>> can probably do this at configuration time rather than at run time.
>
> Or perhaps write a small C program that prints the value of
> CLOCKS_PER_SEC, and compile it and capture its output during your
> build process.

This needs to work without any C dependencies, other than what comes 
with the OS (msvcrt.dll or libc.so.6 or whatever it's called). So I 
cannot require the existence of a C compiler.

I was hoping that there might have been a function that did the trick, 
but those libraries are not going to export the value of a macro. (stdin 
and stdout were another similar problem.)

Sometimes, I will target C where there is the possibility of 
CLOCKS_PER_SECOND being picked up when the intermediate C is compiled, 
but this will not be known to the source language (it's a property of 
the C compiler used).

I think I will try and detect Windows or Linux and assume 1000 or 
1000000 respectively. Doing that would also require invocating a C 
compiler on something like '#ifdef WIN32', but I think I will try a 
quick and dirty method like detecting the existence of some known .exe 
file in C:/windows.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#94848

On 13/10/2016 23:18, BartC wrote:
> On 13/10/2016 17:07, Keith Thompson wrote:

> I think I will try and detect Windows or Linux and assume 1000 or
> 1000000 respectively. Doing that would also require invocating a C
> compiler on something like '#ifdef WIN32', but I think I will try a
> quick and dirty method like detecting the existence of some known .exe
> file in C:/windows.

The following seems to work! It's expressed here in C but only depends 
on standard fopen/fclose functions which can be called from anywhere.

I assume of course that it's always 1000 on Windows and 1000000 on 
Linux, but that might be enough (I think one compiler used to use 100). 
It's only for timing so it's not critical.


#include <stdio.h>
#include <stdlib.h>

int getclockspersec(void){
FILE *f;
if (f = fopen("c:/windows/notepad.exe","rb")) {
|   fclose(f);
|   return 1000;
}
return 1000000;
}

int main(int n, char** s) {

printf("%d\n",getclockspersec());

}

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#94849

BartC <bc@freeuk.com> writes:
> On 13/10/2016 23:18, BartC wrote:
>> On 13/10/2016 17:07, Keith Thompson wrote:
>
>> I think I will try and detect Windows or Linux and assume 1000 or
>> 1000000 respectively. Doing that would also require invocating a C
>> compiler on something like '#ifdef WIN32', but I think I will try a
>> quick and dirty method like detecting the existence of some known .exe
>> file in C:/windows.
>
> The following seems to work! It's expressed here in C but only depends 
> on standard fopen/fclose functions which can be called from anywhere.
>
> I assume of course that it's always 1000 on Windows and 1000000 on 
> Linux, but that might be enough (I think one compiler used to use 100). 
> It's only for timing so it's not critical.
>
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int getclockspersec(void){
> FILE *f;
> if (f = fopen("c:/windows/notepad.exe","rb")) {
> |   fclose(f);
> |   return 1000;
> }
> return 1000000;
> }
>
> int main(int n, char** s) {
>
> printf("%d\n",getclockspersec());
>
> }

I'd probably use long rather than int, though that's unlikely to
be an issue if you're assuming either Windows (1000 is within the
range of int) or POSIX (which requires at least 32-bit int).

Is notepad.exe under C:/windows in all versions of Windows?  Or at
least in all the versions you're concerned with?  Perhaps "NL:"
would be a better choice.  IIRC that's the Windows equivalent of
/dev/null.  You could conceivably get a false positive if there
happens to be a file with that name in the current directory,
but that's probably not worth worrying about.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94915

Keith Thompson <kst-u@mib.org> wrote:

> Is notepad.exe under C:/windows in all versions of Windows?  Or at
> least in all the versions you're concerned with?  Perhaps "NL:"
> would be a better choice.  IIRC that's the Windows equivalent of
> /dev/null.  You could conceivably get a false positive if there
> happens to be a file with that name in the current directory,
> but that's probably not worth worrying about.

It's "NUL:", and you can't create a file with that name, but I'm not
sure you can open it the way Bart is doing, under all circumstances and
all versions of Windows.
In any case, relying on a Windows-specific file means you're limited to
Windows and Linux-like systems. At least it would be wise to add a
configuration file to override this detection should it become necessary
in the future.

Richard

[toc] | [prev] | [next] | [standalone]

#94932

raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Is notepad.exe under C:/windows in all versions of Windows?  Or at
>> least in all the versions you're concerned with?  Perhaps "NL:"
>> would be a better choice.  IIRC that's the Windows equivalent of
>> /dev/null.  You could conceivably get a false positive if there
>> happens to be a file with that name in the current directory,
>> but that's probably not worth worrying about.
>
> It's "NUL:", and you can't create a file with that name, but I'm not
> sure you can open it the way Bart is doing, under all circumstances and
> all versions of Windows.

You're right, I misremembered the name.  It's "NL:" (or "NLA0:") on VMS.

> In any case, relying on a Windows-specific file means you're limited to
> Windows and Linux-like systems. At least it would be wise to add a
> configuration file to override this detection should it become necessary
> in the future.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94832

Keith Thompson <kst-u@mib.org> writes:

> BartC <bc@freeuk.com> writes:
>> CLOCKS_PER_SEC determines how the result of the clock() function is 
>> interpreted.
>>
>> But it seems to be defined as macro in time.h.
>>
>> Any ideas on how to determine that value when calling clock() as foreign 
>> function from another language? I want to avoid OS-specific functions 
>> unless they are available on both Windows and Linux.
>>
>> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and 
>> 1000000 on Linux. I suppose I could detect abnormally large values of 
>> clock() and infer it that way, but I think there will be some overlap in 
>> the set of valid results.)
>
> Write a C function that returns the value of the macro, and call that
> function from the foreign language.  Depending on your build system, you
> can probably do this at configuration time rather than at run time.

Or write a wrapper that returns the equivalent in nanoseconds.

-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

[toc] | [prev] | [next] | [standalone]

#94837

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> BartC <bc@freeuk.com> writes:
>>> CLOCKS_PER_SEC determines how the result of the clock() function is 
>>> interpreted.
>>>
>>> But it seems to be defined as macro in time.h.
>>>
>>> Any ideas on how to determine that value when calling clock() as foreign 
>>> function from another language? I want to avoid OS-specific functions 
>>> unless they are available on both Windows and Linux.
>>>
>>> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and 
>>> 1000000 on Linux. I suppose I could detect abnormally large values of 
>>> clock() and infer it that way, but I think there will be some overlap in 
>>> the set of valid results.)
>>
>> Write a C function that returns the value of the macro, and call that
>> function from the foreign language.  Depending on your build system, you
>> can probably do this at configuration time rather than at run time.
>
> Or write a wrapper that returns the equivalent in nanoseconds.

Assuming that 1/CLOCKS_PER_SEC is a whole number of nanoseconds.
(I don't object to making the assumption, I'm just pointing out
that it is one.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94838

Keith Thompson <kst-u@mib.org> writes:

> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> BartC <bc@freeuk.com> writes:
>>>> CLOCKS_PER_SEC determines how the result of the clock() function is 
>>>> interpreted.
>>>>
>>>> But it seems to be defined as macro in time.h.
>>>>
>>>> Any ideas on how to determine that value when calling clock() as foreign 
>>>> function from another language? I want to avoid OS-specific functions 
>>>> unless they are available on both Windows and Linux.
>>>>
>>>> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and 
>>>> 1000000 on Linux. I suppose I could detect abnormally large values of 
>>>> clock() and infer it that way, but I think there will be some overlap in 
>>>> the set of valid results.)
>>>
>>> Write a C function that returns the value of the macro, and call that
>>> function from the foreign language.  Depending on your build system, you
>>> can probably do this at configuration time rather than at run time.
>>
>> Or write a wrapper that returns the equivalent in nanoseconds.
>
> Assuming that 1/CLOCKS_PER_SEC is a whole number of nanoseconds.
> (I don't object to making the assumption, I'm just pointing out
> that it is one.)

Well, 10^9 rather than 1.

I don't think that assumption is actually required; rounding to
the nearest nanosecond is not going to introduce additional error
in any existing implementations I know, and that probably won't
change in the near future.

But, yes, I was making an implicit assumption that nanoseconds
can adequately represent the time value involved.


-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

[toc] | [prev] | [next] | [standalone]

#94839

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
[...]
>>> Or write a wrapper that returns the equivalent in nanoseconds.
>>
>> Assuming that 1/CLOCKS_PER_SEC is a whole number of nanoseconds.
>> (I don't object to making the assumption, I'm just pointing out
>> that it is one.)
>
> Well, 10^9 rather than 1.

No, I wrote "whole number of nanoseconds".  (And to be clear,
1/CLOCKS_PER_SEC is intended to be a mathematical expression over
the real numbers, not a C expression which would almost certainly
yield 0.)

> I don't think that assumption is actually required; rounding to
> the nearest nanosecond is not going to introduce additional error
> in any existing implementations I know, and that probably won't
> change in the near future.
>
> But, yes, I was making an implicit assumption that nanoseconds
> can adequately represent the time value involved.

Just returning the integer value of CLOCKS_PER_SEC and doing any
required calculations in the "foreign" language avoids the issue
altogether.  If there are rounding issues, I'd rather isolate them
within the code that works on the values than expose them in the
interface that defines the values.

But it's not a huge deal.  If having the interface give you a number
of nanoseconds is more convenient for some reason, it's probably
not going to cause too many problems.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94851

On Thursday, October 13, 2016 at 1:28:22 PM UTC-5, Keith Thompson wrote:
> Assuming that 1/CLOCKS_PER_SEC is a whole number of nanoseconds.
> (I don't object to making the assumption, I'm just pointing out
> that it is one.)

The original IBM PC's "14.3818MHz" master clock had a nominal period of
precisely 1.01E9/14332500ns, i.e. 69.84127ns.  Rounding that to the nearest
nanosecond would introduce a rounding error of 0.227% (8.16 seconds per
hour)--totally unacceptable for many forms of timekeeping.

It might have been helpful to have specified macros for an integer numerator
and denominator of a "ticks per second" value, since there are many systems
whose clock rates don't work out to an integer number of Hz, and whose clock
period doesn't work out to an integer number of ns, but whose clock in Hz
may be expressed as a fraction of the form a*b*c/d using 16-bit integers,
thus making it practical to perform accurate calculations without floating-
point (16-bit scale factors would have left headroom for multiplications with
products that would fit in 32 bits).  The PC's default rate, for example,
would be 5733*2500*1000/1001.

[toc] | [prev] | [next] | [standalone]

#94850

BartC:

>CLOCKS_PER_SEC  determines  how  the  result of the
>clock() function is interpreted.
>
>But it seems to be defined as macro in time.h.
>
>Any ideas on how to determine that value when call-
>ing  clock()  as foreign function from another lan-
>guage? I want to avoid OS-specific functions unless
>they are available on both Windows and Linux.
>
>(At  the moment, CLOCKS_PER_SEC seems to be usually
>1000 on Windows and 1000000 on Linux. I  suppose  I
>could detect abnormally large values of clock() and
>infer it that way, but I think there will  be  some
>overlap in the set of valid results.)

Estimate  its  value using the native time-measuring
functions!  I had to do that in my innovative  snake
game  for  MS-DOS  when  I wrote it in Turbo Pascal,
whose delay procedure took a value in units the val-
ue  whereof  depended  on the machine speed, so that
every game would start with a time-calibration loop.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#94852

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> BartC:
>
>>CLOCKS_PER_SEC  determines  how  the  result of the
>>clock() function is interpreted.
>>
>>But it seems to be defined as macro in time.h.
>>
>>Any ideas on how to determine that value when call-
>>ing  clock()  as foreign function from another lan-
>>guage? I want to avoid OS-specific functions unless
>>they are available on both Windows and Linux.
>>
>>(At  the moment, CLOCKS_PER_SEC seems to be usually
>>1000 on Windows and 1000000 on Linux. I  suppose  I
>>could detect abnormally large values of clock() and
>>infer it that way, but I think there will  be  some
>>overlap in the set of valid results.)
>
> Estimate  its  value using the native time-measuring
> functions!  I had to do that in my innovative  snake
> game  for  MS-DOS  when  I wrote it in Turbo Pascal,
> whose delay procedure took a value in units the val-
> ue  whereof  depended  on the machine speed, so that
> every game would start with a time-calibration loop.

That would be difficult to do accurately.  The clock() function measures
CPU time, not real time.  You'd have to execute a loop that consumes a
known amount of CPU time and compare that to the values returned by
clock() before and after the loop.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94853

Keith Thompson:
>Anton Shepelev:
>>BartC:
>>
>>>CLOCKS_PER_SEC  determines  how the result of the
>>>clock() function is interpreted.
>>>
>>>But it seems to be defined as macro in time.h.
>>>
>>>Any ideas on how to  determine  that  value  when
>>>calling  clock() as foreign function from another
>>>language? I want to avoid  OS-specific  functions
>>>unless  they  are  available  on both Windows and
>>>Linux.
>>>
>>>(At the moment, CLOCKS_PER_SEC seems to be usual-
>>>ly  1000  on Windows and 1000000 on Linux. I sup-
>>>pose I could detect abnormally  large  values  of
>>>clock()  and infer it that way, but I think there
>>>will be some overlap in  the  set  of  valid  re-
>>>sults.)
>>
>>Estimate its value using the native time-measuring
>>functions!  I had to  do  that  in  my  innovative
>>snake  game  for  MS-DOS  when I wrote it in Turbo
>>Pascal, whose delay  procedure  took  a  value  in
>>units  the  value  whereof depended on the machine
>>speed, so that every game would start with a time-
>>calibration loop.
>
>That  would  be  difficult  to  do accurately.  The
>clock() function measures CPU time, not real time.

Is it not proportional to real time?

>You'd have to execute a loop that consumes a  known
>amount  of  CPU time and compare that to the values
>returned by clock() before and after the loop.

Well, I should go the other way round, i.e.  wait  a
known  length  of  time  and  compare  it  with what
clock() has counted:

   const Seconds = 10;
   t1 := clock();
   native_delay( Seconds );
   t2 := clock();
   CLOCKS_PER_SECOND := (t2 - t1) / Seconds;

where native_delay() is whatsoever delay routine the
host language or OS provides.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#94855

On Fri, 14 Oct 2016 18:56:07 +0300, Anton Shepelev
<anton.txt@g{oogle}mail.com> wrote:

>Keith Thompson:
>>Anton Shepelev:
>>>BartC:
>>>
>>>>CLOCKS_PER_SEC  determines  how the result of the
>>>>clock() function is interpreted.
>>>>
>>>>But it seems to be defined as macro in time.h.
>>>>
>>>>Any ideas on how to  determine  that  value  when
>>>>calling  clock() as foreign function from another
>>>>language? I want to avoid  OS-specific  functions
>>>>unless  they  are  available  on both Windows and
>>>>Linux.
>>>>
>>>>(At the moment, CLOCKS_PER_SEC seems to be usual-
>>>>ly  1000  on Windows and 1000000 on Linux. I sup-
>>>>pose I could detect abnormally  large  values  of
>>>>clock()  and infer it that way, but I think there
>>>>will be some overlap in  the  set  of  valid  re-
>>>>sults.)
>>>
>>>Estimate its value using the native time-measuring
>>>functions!  I had to  do  that  in  my  innovative
>>>snake  game  for  MS-DOS  when I wrote it in Turbo
>>>Pascal, whose delay  procedure  took  a  value  in
>>>units  the  value  whereof depended on the machine
>>>speed, so that every game would start with a time-
>>>calibration loop.
>>
>>That  would  be  difficult  to  do accurately.  The
>>clock() function measures CPU time, not real time.
>
>Is it not proportional to real time?

Hardly ever.  If the code is extremely CPU bound (e.g., massive
complex computations), CPU time may be very close to real time.  If
the code performs a lot of I/O operations, the CPU time would be a
mere fraction of real time.  If the I/O was on a network, the ratio
would effectively be random.


-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#94859

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Keith Thompson:
[...]
>>That  would  be  difficult  to  do accurately.  The
>>clock() function measures CPU time, not real time.
>
> Is it not proportional to real time?

No.  For example, a process waiting on I/O, or swapped out,
consumes little or no CPU time, and on a multicore system a
process can consume more than one CPU second per real-time second.
(Obviously this can be system-specific.)

>>You'd have to execute a loop that consumes a  known
>>amount  of  CPU time and compare that to the values
>>returned by clock() before and after the loop.
>
> Well, I should go the other way round, i.e.  wait  a
> known  length  of  time  and  compare  it  with what
> clock() has counted:
>
>    const Seconds = 10;
>    t1 := clock();
>    native_delay( Seconds );
>    t2 := clock();
>    CLOCKS_PER_SECOND := (t2 - t1) / Seconds;
>
> where native_delay() is whatsoever delay routine the
> host language or OS provides.

The value returned by clock() will probably not advance while
native_delay() is running.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#94860

On Friday, October 14, 2016 at 1:13:14 PM UTC-5, Keith Thompson wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> > Keith Thompson:
> [...]
> >>That  would  be  difficult  to  do accurately.  The
> >>clock() function measures CPU time, not real time.
> >
> > Is it not proportional to real time?
> 
> No.  For example, a process waiting on I/O, or swapped out,
> consumes little or no CPU time, and on a multicore system a
> process can consume more than one CPU second per real-time second.
> (Obviously this can be system-specific.)

The Standard grants enormous latitude as to what the function is supposed
to measure; for some single-processor single-threaded implementations, CPU
time may be indistinguishable form clock time (the processor may be executing
instructions at all times when powered on, even if most of those instructions
happen to be "Loop: If no key pushed, branch to loop").

[toc] | [prev] | [next] | [standalone]

#94854

On 10/14/2016 11:41 AM, Keith Thompson wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>> BartC:
>>
>>> CLOCKS_PER_SEC  determines  how  the  result of the
>>> clock() function is interpreted.
>>>
>>> But it seems to be defined as macro in time.h.
>>>
>>> Any ideas on how to determine that value when call-
>>> ing  clock()  as foreign function from another lan-
>>> guage? I want to avoid OS-specific functions unless
>>> they are available on both Windows and Linux.
>>>
>>> (At  the moment, CLOCKS_PER_SEC seems to be usually
>>> 1000 on Windows and 1000000 on Linux. I  suppose  I
>>> could detect abnormally large values of clock() and
>>> infer it that way, but I think there will  be  some
>>> overlap in the set of valid results.)
>>
>> Estimate  its  value using the native time-measuring
>> functions!  I had to do that in my innovative  snake
>> game  for  MS-DOS  when  I wrote it in Turbo Pascal,
>> whose delay procedure took a value in units the val-
>> ue  whereof  depended  on the machine speed, so that
>> every game would start with a time-calibration loop.
> 
> That would be difficult to do accurately.  The clock() function measures
> CPU time, not real time.  You'd have to execute a loop that consumes a
> known amount of CPU time and compare that to the values returned by
> clock() before and after the loop.
> 

And don't forget - modern PC's can adjust CPU frequency on the fly.
What you get in one calculation may be much different when repeated.
Things like instruction prefetch, bus contention on multiple core CPUs
can also affect results, although usually not as significantly.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web