C9x <time.h> and clock precision

[Markus Kuhn]

"Clive D.W. Feather" wrote on 1998-10-08 19:14 UTC:
> In message <199810052044.NAA14428 at shade.twinsun.com>, Paul Eggert
> <eggert at twinsun.com> writes
> >Perhaps I'm paraphrasing you incorrectly; still, I am extremely
> >uncomfortable with the idea that the C standard should impose an upper
> >limit on the quality of the clock.
> 
> It shouldn't. However, that doesn't mean that it can't put a limit on
> Standard access to the clock. Thus a design that limited defined
> precision to 1ns, but didn't forbid an fs or as field would be
> reasonable.

If there really is a hard-core fraction of attosecond fanatics in
WG14, I'd be happy to replace xtime with

struct xtime {
  xtime_sec_t    sec;
  xtime_subsec_t subsec;
}

#define SUBSEC_PER_SEC ... /* subseconds per seconds */

I just tried to do the technically correct thing before the politically
correct thing. Nobody is ever going to need subnanosecond resolution
from xtime_get. Leaving the subsec encoding open will make portable
programming more cumbersome and less readable.

If you want to provide for direct hardware counter access (perfectly
reasonable idea), then the "right thing"[TM] to do is to make an
interface that looks precisely like clock() (just with a different
name), but that gives access to an integer real-time counter instead of
a process-time counter. This is what people interested in subnanosecond
timing might want to use, but as I said before, these things are much
more likely to be implemented in inline assembler or via direct I/O
access anyway, because they are incredibly non-portable by their very
nature. There is no chance to get even tens of nanosecond timing done in
a portable way, so portable subsecond nanosecond timing really is
science fiction.

It is an "interesting" balance of design to require on one side the
standard to provide provisions for unrealistic subnanosecond clock
readings, and on the other size to provide no delay function at all
(which will force authors of portable software to use inefficient wait
loops that continuously read the clock until it is too late). But hey,
if it makes the committee happy, ...

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>