0

I use AMD FX 4300 with 3.8GHz, that means 3.8G clocks per sec. But when I run the command CLOCKS_PER_SEC it shows something else.

#include <time.h>    
#include <stdio.h>

int main()    
{       
   printf("%lu\n",CLOCKS_PER_SEC);

   return 0;
}

it shows: 1000

Is it right?

Is there any problem in my processor or the working of this program?

drescherjm
  • 10,365
  • 5
  • 44
  • 64
  • 1
    These days I would just use `std::chrono` – drescherjm Aug 31 '16 at 06:32
  • 3
    ***Is there any problem in my processor or the working of this program?*** I say neither. `CLOCKS_PER_SEC` is not measuring cpu cycles. Although even if it was that is not so good today being that your cpu will dynamically adjust the multiplier anyways.. – drescherjm Aug 31 '16 at 06:34
  • 'it shows: `1000`' - it's all your fault. Stop running a non-POSIX compliant system and you'll see the performance [boosted by 1000](http://en.cppreference.com/w/cpp/chrono/c/CLOCKS_PER_SEC) :D – Adrian Colomitchi Aug 31 '16 at 06:36
  • `CLOCK_PER_SEC` is just a system clock, not an hardware one. – Jean-Baptiste Yunès Aug 31 '16 at 06:39

1 Answers1

1

Putting other issues aside, CLOCKS_PER_SEC isn't dependable.

for example (see the linux clock man page):

POSIX requires that CLOCKS_PER_SEC equals 1000000 independent of the actual resolution.

Myst
  • 18,516
  • 2
  • 45
  • 67
  • 2
    That doesn't mean it isn't dependable, you can depend on it to be `1000000`, just as POSIX defines it, every time you call it. The issue I think you are hinting at is there will be little correlation between what you are using `CLOCKS_PER_SEC` for and your processor ticks. – David C. Rankin Aug 31 '16 at 07:10
  • @DavidC.Rankin that's mostly true however, not everyone implements the POSIX requirement. So I guess both are true, since on most systems (but not all) you can depend on the POSIX value. – Myst Aug 31 '16 at 07:44
  • 1
    There was a small wink and nod buried in the comment above `:)` – David C. Rankin Aug 31 '16 at 08:45