GCC time.h problem.

[Vladimir S. Oka]

I remember using execution profiler in keil cross compiler.Can I
implement it in a standalone program?I want to create a benchmarking
module.I've used clock() function several times with borland
compilers.Also execution profiler assumes full processor usage and
doesn't consider other processes running in background(Which are
irrelavant to C program).

Do not snip attribution lines. Do not quote signatures.

What you ask above is off-topic, quite unclear in what you actually want
to achieve, and so on. Come back when you have a genuine C question,
and learn how to post.

--
BR, Vladimir

I consider a new device or technology to have been
culturally accepted when it has been used to commit a murder.
-- M. Gallaher

 

[Tim Prince]

Data point: CLOCKS_PER_SEC is one million on SUSv2 compliant unix
systems, but this is one point where some BSD systems don't conform to
that standard. For example, on FreeBSD, it is 128, and on OpenBSD, and
from what I can tell earlier versions of NetBSD, it is 100.

This implies nothing about the resolution of the clock, but on modern
systems it's more likely to be better than worse.

clock() resolution of 10 ms, as it apparently was on your NetBSD system,
remains a common value. This is still not relevant to the O/P, as he
refused to correct his code, which is likely to truncate his result to
whole seconds, then fail to display any reasonable approximation to that
value. Among the systems I have access to, the best clock() resolution
is 1/1024 second, but all of them have CLOCKS_PER_SEC set to 1 million.

 

[Ben Bacarisse]

Among the systems I have access to, the best clock() resolution is
1/1024 second, but all of them have CLOCKS_PER_SEC set to 1 million.

POSIX requires it to be 1 million (I can't imagine why) and since this
does not interfere with the C standard, implementations can kill two
standard birds with one #define.

 

[Micah Cowan]

POSIX requires it to be 1 million (I can't imagine why) and since this
does not interfere with the C standard, implementations can kill two
standard birds with one #define.

You are the second person (I think) to have said this. AFAICT, it's
not strictly true. POSIX doesn't require this; the X/Open System
Interface Extension does. This according to my copy of SUSv3.

 

[Ben Bacarisse]

You are the second person (I think) to have said this. AFAICT, it's not
strictly true. POSIX doesn't require this; the X/Open System Interface
Extension does. This according to my copy of SUSv3.

Ah. Yes, you are entirely correct. I have no idea what the X/Open System
Interface is but the POSIX (IEEE 1003.1) documents explain differences
between POSIX and XSI and, as you say, this is one of them. Thanks.

 

[Jordan Abel]

Ah. Yes, you are entirely correct. I have no idea what the X/Open System
Interface is but the POSIX (IEEE 1003.1) documents explain differences
between POSIX and XSI and, as you say, this is one of them. Thanks.

Broadly, it's what makes an implementation "unix" instead of just
another half-assed posix system.