Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94821 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-10-13 14:49 +0100 |
| Last post | 2016-10-16 02:55 -0700 |
| Articles | 4 on this page of 24 — 9 participants |
Back to article view | Back to comp.lang.c
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]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2016-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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-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]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-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