time in milliseconds in c

hi,

i am running some sorting algos so i need to print ans in milliseconds. how do i do that

Use the sys/timeb.h header file. Use a timeb struct

Code:

---

struct timeb {
  long time ;      /* seconds since 00:00:00, 1/1/70, GMT */
  short millitm ;  /* fraction of second  (in milliseconds) */
  short timezone ;  /* difference between local time and GMT */
  short dstflag ;  /* 0 if daylight savings time is not in effect */
};

---

and use the function ftime() to get the current time and store it in a timeb struct.

> i am running some sorting algos so i need to print ans in milliseconds. how do i do that
Without knowing which OS/Compiler you have, its hard to say. C has no standard sub-second clocks.

You could run your algorithms inside a loop like so

Code:

---

t1 = time(NULL);
for ( i = 0 ; i < 1000 ; i++ ) {
  // code to time goes here
}
t2 = time(NULL);
printf( "Average time=%f\n", difftime(t2,t1)/1000 );

---

Or perhaps if you're using an intel processor and gcc, then you could use the rdtsc

orthanc.

This may provide a clue.

Code:

---

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

int main(void)
{
        clock_t start, stop;


        start = clock();
       
        getchar();        /* Wait for keypress...        */

        stop = clock();


        printf("Approx seconds, tenths, hundredths and milliseconds: %.3f\n",
                ((double)(stop - start) / CLOCKS_PER_SEC));

        return 0;
}

---

What if CLOCKS_PER_SEC is 1 on your machine?
or any value < 1000 for that matter.

Quote:

---

Originally posted by Salem
What if CLOCKS_PER_SEC is 1 on your machine?
or any value < 1000 for that matter.

---

Then I'd say you have an extremely slow machine and should probably upgrade...

Seriously though,

CLOCKS_PER_SEC is different on different machines, but whatever
the actual value of CLOCKS_PER_SEC it should be an approxiamate representation of how many ticks the actual CPU cycles in a second.

I doubt CLOCKS_PER_SEC would be much less than 1000 and I've
certainly seen it defined much larger (1,000,000).

In any event regardless of what CLOCKS_PER_SEC actually is,
((double)stop - start) / CLOCKS_PER_SEC) works.

((double)stop / CLOCKS_PER_SEC) will also work just fine for this example.

Quote:

---

Originally posted by c99
orthanc.

This may provide a clue.

...code snipped...

---

This gives me the following output:

Quote:

---

Approx seconds, tenths, hundredths and milliseconds: 0.000000

---

No matter how long i wait. (The second version, with the division by 1000.0, I didn't try the first.)

Quzah.

quzah.

Sorry, somehow external influences (points at Salem) convinced me not to use
CLOCKS_PER_SEC when in reality using CLOCKS_PER_SEC was the correct
and standard course to take.

What is CLOCKS_PER_SEC defined as on your implementation?

Code:

---

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


int main(void)
{
        clock_t stop;


        getchar();

        stop = clock();

        printf("Approx seconds, tenths, hundredths and milliseconds: %.3f\n",
                (double)((double)stop / CLOCKS_PER_SEC));

        printf("Approx milliseconds: %.0f\n",
                (double)((double)stop / CLOCKS_PER_SEC) * 1000);

        return 0;
}

---

> CLOCKS_PER_SEC it should be an approxiamate representation of how many ticks the actual CPU cycles
It has nothing to do with how fast your processor is, a little to do with which OS you're running on and the rest is up to the compiler implementer.
Its an approximate measure of time, not the rate at which the processor executes instructions.

There's certainly no reason to assume that its anything like a 1ms resolution.

Even if you have CLOCKS_PER_SEC as 1000, that still doesn't mean that the value returned by clock() is incremented by 1 at 1Khz. It could be incremented by 100 at 10hz, and it would still be compliant.
Then you'd have to start answering questions like 'why is my time measurement always x.xx0 milliseconds'

If it works for you, use it. But it isn't a works for everybody deal.

> start = clock();
At least your first example had this - your 2nd example assumes that clock() returns 0 when main() starts.

Salem.

True, everything is just too approxiamate about these clock calls.