timer in milliseconds

[gregg]

Hi,

I have to record the execution time of a program, but in milliseconds
(the target language of the project initially was Pascal, but I talked
the boss into letting me code it in C).

So now, time.h gives time_t time() all right, but it returns it in
milliseconds since the Epoch.

Do you know of a way I could grab time in milliseconds (while keeping to
ISO C) ?
(with current date, say, since milliseconds between now and Epoch won't
do with a (long)

Or shall i *really* recourse to Unix system calls ? :-(

thx,
gregg

 

[gregg]

So now, time.h gives time_t time() all right, but it returns it in
milliseconds since the Epoch.

^^^^^^^^^^^^

i meant "seconds" there, of course
sorry

 

[Thomas Stegen]

So now, time.h gives time_t time() all right, but it returns it in
milliseconds since the Epoch.

^^^^^^^^^^^^

(You mean seconds.)

Do you know of a way I could grab time in milliseconds (while keeping to
ISO C) ?

The range and precision of time_t is implementation defined. So no,
there is no standard way of doing this. Relevant section in the
standard is 7.23.1.

Or shall i *really* recourse to Unix system calls ? :-(

Looks like it, make sure you stay within POSIX at least.

 

[gregg]

gregg wrote:


Looks like it, make sure you stay within POSIX at least.

Eventually, i used gettimeofday, included in <sys/time.h>, converting
microseconds into millis.
Which is POSIX, AFAIK.

It should compile all right on any Unix (Posix), but not on Macs, and
Windows :-(

Anyway it is no ISO C, that's why i'm a bit embarassed.

How comes the only standard precision we have is "second", when such
languages as Java or Pascal offer milliseconds ?
I reckon second was enough in the 70s and probably 80s, but no longer is !
Updating time(), or adding a field to a structure wouldn't cost much,
and keep downward-compatibility (those old programs not using an added
field wouldn't be aware of it).

Gosh.

 

[CBFalconer]

.... snip ...

Anyway it is no ISO C, that's why i'm a bit embarassed.

How comes the only standard precision we have is "second", when
such languages as Java or Pascal offer milliseconds ?

Don't know about Java, but ISO7185 Pascal does not offer time,
while ISO10206 Extended Pascal only offers seconds. As with C,
many implementations supply extension functions.

 

[Keith Thompson]

How comes the only standard precision we have is "second", when such
languages as Java or Pascal offer milliseconds ?

Standard C doesn't guarantee 1-second precision. The types time_t and
clock_t are just "arithmetic types capable of representing times".
Type time_t often represents the number of seconds since the epoch,
but there's no guarantee in the C standard that it's even monotonic.

An implementation in which time_t is a 64-bit count of nanoseconds
since the epoch would be perfectly legal. So would an implementation
in which you have to extract ranges of bits from a time_t value to
determine year, month, day, etc.

<OT>
I think POSIX requires time_t to measure seconds since
1970-01-01 00:00:00 GMT. (Yes, I wrote GMT rather than UTC;
UTC wasn't invented until a few years later.)
</OT>.

 

[J. J. Farrell]

Standard C doesn't guarantee 1-second precision. The types time_t and
clock_t are just "arithmetic types capable of representing times".
Type time_t often represents the number of seconds since the epoch,
but there's no guarantee in the C standard that it's even monotonic.

<OT>
I think POSIX requires time_t to measure seconds since
1970-01-01 00:00:00 GMT. (Yes, I wrote GMT rather than UTC;
UTC wasn't invented until a few years later.)
</OT>.

If only POSIX were that simple ...

The bit that is simple is that time_t is defined as holding
'time in seconds'. So far so good. That time is usually
'Seconds since the Epoch', and that's where the fun starts.

POSIX has a somewhat mind-bending concept of time. The
Epoch is defined as 1970-01-01 00:00:00 UTC (not GMT). However
'Seconds since the Epoch' does not mean 'seconds since the
Epoch' as you might expect, but an "approximation" of seconds
since the Epoch as given by a fixed formula that ignores
leap seconds. Thus POSIX's 'Seconds since the Epoch' is
drifting gently away from a plain English interpretation of
that term as time goes by.

It's been a while since I gave myself a headache with this lot,
but I seem to remember that the best way to keep the various
function and 'Seconds since' definitions consistent is to
think of the Epoch moving each time a leap second is added or
removed.

Trying to maintain POSIX compliance at the same time as showing
the right real-world time (using Olson or whatever) is enough
to make a grown man cry.

 

[gregg]

Don't know about Java, but ISO7185 Pascal does not offer time,
while ISO10206 Extended Pascal only offers seconds. As with C,
many implementations supply extension functions.

Researchers in college made us use "gettime(hours, minutes, seconds,
100secs)".
It works with FreePascal, and also with Borland compilers.

Now, either it is a Borland feature, implemented by FreePAscal, and I'm
mistaken, or it is ISO-Pascal (which i'm not familiar with, i'd rather
code with C !)

gregg

 

[Tim Prince]

Researchers in college made us use "gettime(hours, minutes, seconds,
100secs)".
It works with FreePascal, and also with Borland compilers.

Now, either it is a Borland feature, implemented by FreePAscal, and I'm
mistaken, or it is ISO-Pascal (which i'm not familiar with, i'd rather
code with C !)

OK, let's get back toward C, although this much needed facility is not
standard C. gcc configure goes through several contortions to implement
functions which depend on this or equivalent facility:
<time.h> or <sys/time.h> just for the standard C, resolution 1 second.

For milliseconds, ifdef _WIN32 use GetLocalTime()
if gettimeofday() available, is it the ONE_ARGUMENT kind, with a pointer to
a struct return, no time zone, or the 2 argument kind, with the 2nd argument
either being a pointer to a struct timezone, or a NULL pointer.
Example: libf2c/libU77/datetime_.c
Yes, several languages have a better defined format for time than C (13
years now for Fortran), but depend on the various unstandardized C methods
to collect the information.
I doubt if anyone cares who suggested that certain extended Pascal compilers
implement gettimeofday(). We're in enough of a mess as it is.

 

[Michel Bardiaux]

Standard C doesn't guarantee 1-second precision. The types time_t and
clock_t are just "arithmetic types capable of representing times".
Type time_t often represents the number of seconds since the epoch,
but there's no guarantee in the C standard that it's even monotonic.

An implementation in which time_t is a 64-bit count of nanoseconds
since the epoch would be perfectly legal. So would an implementation
in which you have to extract ranges of bits from a time_t value to
determine year, month, day, etc.

<OT>
I think POSIX requires time_t to measure seconds since
1970-01-01 00:00:00 GMT. (Yes, I wrote GMT rather than UTC;
UTC wasn't invented until a few years later.)
</OT>.

With dire consequences: POSIX-compliant timing functions return times
since blah blah *AS IF THERE WERE NO LEAP SECONDS*. Which makes it a
real PITA to write real-time applications that behave correctly in the
presence of leap seconds.