Measuring time differences

[coder1024]

| The system can periodically refresh the time by synchronizing with a
| time source. Because the system time can be adjusted either forward or
| backward, do not compare system time readings to determine elapsed
| time.

yes, good point. however, if you're in control of the system time the
methods already presented should work fine. guess it depends on how
the user's system is setup.

 

[Mark McIntyre]

I said that that program was for msvc like compilers. For gnuish
compilers use:

(some highly nonportable and offtopic stuff)

 

[coder1024]

Sorry Keith, and the rest of the group. I normally manage to avoid
letting erroneous off topic advice tempt me in to a debate

My intent was simply to provide some help to the OP. I apologize if
this was not done correctly.

 

[jacob navia]

(some highly nonportable and offtopic stuff)

Portability:

That program will run under:

Windows (all versions)
Linux (all x86 versions)
Solaris (x86 versions)
BeOs

That is almost 80-90% of the market... Maybe 100% when
you consider that it has been designed for the future
x86 MAc OS.

This is meant as a demonstration of the power of C.

I bet there is no other language that manages doing
something like this with that kind of easy.

jacob

 

[coder1024]

Bollocks. And if you can't see why, you're probably also incapable of
understanding the other arguments that have been made to you.

No, I understand the arguments being presented quite well. There's the
opinion that the OP should simply be referred to another group. Thats
fine with me, however, I thought it would also be good to give the OP a
couple threads to pull which I thought might help. I really doubt that
was worth some of the responses received. Figuring out whether or not
you have the function available takes adding sys/time.h, adding a call,
and trying to compile.

You miss the point entirely. You failed in the latter, and are now
persisting in ignoring polite (though increasingly less polite)
requests to stop it.

I think a few people need to get some fresh air.

I know that you dolt. I don't give two hoots. Its not topical here, so
here I know nothing of it. Stop wittering on about it.

I only posted it as I thought it might be of use to the OP.

 

[Chris Torek]

The Apache Portable Runtime (APR) is a C runtime library designed to
provide a number of lower level basic functions for developers. See
http://apr.apache.org/ for more info.

Being the generally curious sort, I took a look at the URL above.
Besides not working at all in lynx, the documentation appears to
be largely nonexistent. But it does appear that the goal of the
time routines in the APR library is to support the "time of day"
notion, as used to tell people what a wall clock reads, similar
to the "struct tm" values from localtime() and gmtime().

These are not necessarily what one wants at all. In particular,
consider the way an accurate clock mounted on a wall will read around
the time when most of the USA transitions into or out of Daylight
Saving Time:

01:59:57
01:59:58
01:59:59
01:00:00
01:00:01
...

Or:

01:59:58
01:59:59
03:00:00

Instead of one second elapsing, one hour and one second suddenly
elapses (in the second case). In the first case, time actually
goes backwards!

Besides DST, one may have to deal with leap-seconds, in which there
is an xx:59:60. For these reasons, Coordinated Universal Time
(UTC) actually comes in three flavors: UTC, UT1, and TAI. See
<http://tycho.usno.navy.mil/leapsec.html> and
<http://tycho.usno.navy.mil/systime.html> for details.

And of course, on computers, we may also be interested in elapsed
CPU time (which is quite different from wall-clock time, especially
in multiprocessing and multiprocessor systems).

(I would write more but it is time to get ready for gym).

 

[Keith Thompson]

no, I think you're being a little dramatic there. the OP should be
able to very quickly determine if its available in their environment.
if its not, no loss. if its is, their problem has just been solved.
actually if it isn't they could also try the APR alternative presented.

And what if the OP's system happens to have gettimeofday() (perhaps
because Cygwin is installed), but other systems on which his code
needs to run don't?

He needs to measure times to high precision. There's no portable way
to do that. He's using a DOS/Windows system (I won't go into the
distinction between DOS and Windows), and presumably doesn't need his
code to be portable to other systems. The obvious answer is to use
some DOS-specific or Windows-specific function. Presumably
gettimeofday() and whatever the APR provides use that function, but
there's probably no good reason for the OP not to use the underlying
function directly.

The OP can find out about this by posting to a system-specific
newsgroup.

I understand that you were trying to help, but very often the best
help you can possibly offer is to say "We don't know, but the folks
over there probably do".

 

[Flash Gordon]

Portability:

That program will run under:

Windows (all versions)
Linux (all x86 versions)
Solaris (x86 versions)
BeOs

It won't work on the AIX box I use regularly, nor on the big AIX server
one of our customers has recently bought (even if they put Linux on it),
nor on my iMac running Linux, nor on my brothers notebook...

I've no idea if it will work on SCO, and I doubt you do either (yes, SCO
is still going). It won't work on the non-x86 version of Solaris.

That is almost 80-90% of the market... Maybe 100% when
you consider that it has been designed for the future
x86 MAc OS.

Should I tell our big customer they need to scrap many thousands of
pounds of investment the have recently made then? Will my brothers
notebook suddenly stop working?

Whatever you might think from your limited experience the code is a very
long way from portable. Your code may will be an appropriate solution to
the OPs problem, but it no-longer belongs here than the discussion of
Windows system calls I mistakenly let myself get dragged in to.

This is meant as a demonstration of the power of C.

I bet there is no other language that manages doing
something like this with that kind of easy.

Assembler, Pascal with extensions (you are not using standard C so this
is a valid comparison), ADA I'm sure (since it is used for embedded
systems), Forth (IIRC), C++ with the same non-standard tricks...

 

[Richard Heathfield]

jacob navia said:

I said that that program was for msvc like compilers.

Well, gcc is an msvc-like compiler, in the sense that it compiles ISO C90
programs just fine, same as msvc does.

Still, I tried your gcc-friendly replacement, and got this:

foo.c:2: warning: ANSI C does not support `long long'
foo.c: In function `main':
foo.c:7: warning: ANSI C does not support `long long'
foo.c:8: warning: ANSI C does not support `long long'
foo.c:10: warning: ANSI C does not support the `ll' length modifier

If I tried to squeeze that lot past peer review, I'd be laughed out of the
building.

 

[coder1024]

The obvious answer is to use some DOS-specific or Windows-specific function.
Presumably gettimeofday() and whatever the APR provides use that function, but
there's probably no good reason for the OP not to use the underlying
function directly.

I suppose the advantage of using something like APR instead of calling
the OS API directly would be in the event of the OP wanting to, in the
future, try running their code on a different OS. As long as APR was
provided you could then of course target the other OS and presumably
APR provides a similar call to that OS's appropriate APIs.

The OP can find out about this by posting to a system-specific
newsgroup.

I understand that you were trying to help, but very often the best
help you can possibly offer is to say "We don't know, but the folks
over there probably do".

Point taken.

 

[Randy Howard]

coder1024 wrote
(in article

Well, the Windows API documentation is easily accessible on the web, so
its pretty trivial to verify.

[snip]

I recall my comment earlier in this thread stating that you seem
to be capable of learning from your mistakes, which is no longer
apparent.

 

[Randy Howard]

jacob navia wrote

Portability:

That program will run under:

Windows (all versions)
Linux (all x86 versions)
Solaris (x86 versions)
BeOs

RDTSC *DOES NOT WORK PROPERLY* on all SMP systems. Period. So
much for that theory.

That is almost 80-90% of the market... Maybe 100% when
you consider that it has been designed for the future
x86 MAc OS.

You are completely ignoring the embedded market, which
represents a huge portion of where C code is actively deployed
today. There are far more of them than all of the Windows boxes
on the planet combined. Don't let that bother you though.
It doesn't work worth a flip on my Powermac G5 either.

It doesn't work a number of PDA's I have development kits for
either.

There is no guarantee that it will work on the x86 version of
Mac OS X either, but it probably will, unless you have more than
one processor, in which case, AGAIN, you may be hosed.

This is meant as a demonstration of the power of C.

No, it's a demonstration that once again you are confused about
what C is and is not.

I bet there is no other language that manages doing
something like this with that kind of easy.

It's even simpler in assembly, and about equally portable. Even
so, it's still not going to work on SMP boxes.

 

[Keith Thompson]

jacob navia said:


Well, gcc is an msvc-like compiler, in the sense that it compiles ISO C90
programs just fine, same as msvc does.

Still, I tried your gcc-friendly replacement, and got this:

foo.c:2: warning: ANSI C does not support `long long'
foo.c: In function `main':
foo.c:7: warning: ANSI C does not support `long long'
foo.c:8: warning: ANSI C does not support `long long'
foo.c:10: warning: ANSI C does not support the `ll' length modifier

If I tried to squeeze that lot past peer review, I'd be laughed out of the
building.

If you used gcc's "-ansi" option, you were asking it to conform to the
C90 standard. With "-std=c99", or without any option to specify the
standard, it should accept "long long". (C99 is the current standard,
after all, even if it isn't yet universally supported.)

Apart from that, of course, the code is blatantly non-portable. It
even blew up on me on a Linux/x86 system (I haven't taken the time to
figure out why.)

 

[coder1024]

Well, the Windows API documentation is easily accessible on the web, so
its pretty trivial to verify.

[snip]

I recall my comment earlier in this thread stating that you seem
to be capable of learning from your mistakes, which is no longer
apparent.

the horse is dead

 

[Richard Heathfield]

Keith Thompson said:

If you used gcc's "-ansi" option, you were asking it to conform to the
C90 standard.

Quite so. Since writing portable code in C99 isn't a viable proposition yet,
C90 is all we have.

With "-std=c99", or without any option to specify the
standard, it should accept "long long". (C99 is the current standard,
after all, even if it isn't yet universally supported.)

It isn't supported by gcc yet. Even when it is, I'll still need my code to
conform to non-gcc compilers. So why would I use such a switch?

Apart from that, of course, the code is blatantly non-portable.

That was kind of my point.

 

[Keith Thompson]

Keith Thompson said:

Quite so. Since writing portable code in C99 isn't a viable proposition yet,
C90 is all we have.


It isn't supported by gcc yet. Even when it is, I'll still need my code to
conform to non-gcc compilers. So why would I use such a switch?

long long is supported by gcc, and by many other compilers.

That was kind of my point.

The use of long long isn't the worst non-portability.

 

[Emmanuel Delahaye]

jacob navia a écrit :

I said that that program was for msvc like compilers. For gnuish
compilers use:

printf("Cycles since machine start = %lld\n",cycles);

If your linker is using MSVCRT.DLL :

printf("Cycles since machine start = %i64\n", cycles);

Not only not portable but also not standard. Huh!

 

[Michael Mair]

My intent was simply to provide some help to the OP. I apologize if
this was not done correctly.

Meaning no harm (and much more meaning to be helpful) is not enough.
There are good reasons for avoiding off-topic advice. You have been
told many of them. Please, just stop giving it and stop this
discussion -- it costs time which could be spent better by really
helping people with their topical requests or whatever rocks the
participants' boats.

-Michael

 

[Mark McIntyre]

That program will run under:

Windows (all versions)

what, including Windows NT for RISC? Remember that?

Solaris (x86 versions)

but presumably nothing that runs on sparc, ie most of the solaris
insalled base

BeOs

right, that major OS.

That is almost 80-90% of the market...

You have so little clue its amusing. You seriously think that x86 is
80% of the computer market?

This is meant as a demonstration of the power of C.

Except it wasn't C, it was x86 assembler.

 

[Martin Ambuhl]

I suppose the advantage of using something like APR instead of calling
the OS API ....

Please stop it, for God's sake! Are you running for troll-of-the-year?
Off-topic is off-topic. And you are plonked.