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


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

CLOCKS_PER_SEC

Started byBartC <bc@freeuk.com>
First post2016-10-13 14:49 +0100
Last post2016-10-16 02:55 -0700
Articles 4 on this page of 24 — 9 participants

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 2 of 2 — ← Prev page 1 [2]


#94856

FromAnton Shepelev <anton.txt@g{oogle}mail.com>
Date2016-10-14 19:53 +0300
Message-ID<20161014195348.b58ccefe064bded596425856@g{oogle}mail.com>
In reply to#94854
Jerry Stuckle:
>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  usu-
>>>>ally  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-measur-
>>>ing 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.
>>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 fre-
>quency 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.

Thanks, I now see  that  I  was  wrong.   My  method
worked  in  MS-DOS  but  will not on modern hardware
running modern OSes.

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

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


#94857

Fromsupercat@casperkitty.com
Date2016-10-14 09:57 -0700
Message-ID<385d61ac-770a-44b5-abf0-16db3d072edf@googlegroups.com>
In reply to#94856
On Friday, October 14, 2016 at 11:53:57 AM UTC-5, Anton Shepelev wrote:
> Thanks, I now see  that  I  was  wrong.   My  method
> worked  in  MS-DOS  but  will not on modern hardware
> running modern OSes.

The meaning of what a "CPU time" measurement actually measures will be
implementation-dependent.  On some platforms it may not be possible to
measure anything usefully.  Still, having a consistent way of asking
platforms to measure whatever they define as CPU time can be helpful.

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


#94858

FromBartC <bc@freeuk.com>
Date2016-10-14 18:18 +0100
Message-ID<ntr40k$jjd$1@dont-email.me>
In reply to#94856
On 14/10/2016 17:53, Anton Shepelev wrote:
> Jerry Stuckle:

>> And don't forget -- modern PC's can adjust CPU fre-
>> quency 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.
>
> Thanks, I now see  that  I  was  wrong.   My  method
> worked  in  MS-DOS  but  will not on modern hardware
> running modern OSes.

You also have to persuade a compiler not to completely optimise out what 
it thinks is a pointless loop.

-- 
Bartc

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


#94913

FromMalcolm McLean <malcolm.mclean5@btinternet.com>
Date2016-10-16 02:55 -0700
Message-ID<ed91a303-a3f6-4a0c-aa40-69f9198bd220@googlegroups.com>
In reply to#94854
On Friday, October 14, 2016 at 4:56:57 PM UTC+1, Jerry Stuckle wrote:
> On 10/14/2016 11:41 AM, Keith Thompson wrote:
> > Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>
> 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.
> 
Yes, you need to time for about a tenth of a second to get a reliable comparison
of two subroutines.I don't know what the actual figure is, but that's the ballpark.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

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


csiph-web