Harald >why is times(2) no real system call as `man times' implies ?
Harald >
Harald >for alpha this is implemented in libc using 3 syscalls
Harald >
Harald > getrusage(RUSAGE_SELF, {...})
Harald > getrusage(RUSAGE_CHILDREN, {...})
Harald > gettimeofday({...}, NULL)
Harald >
Harald > and it is not values in terms of clock ticks (which would be 1024/sec
Harald > for Linux/AXP) but are scaled to "CLK_TCK"s which are defined as 100
Harald > in <time.h>.
Harald >
Harald > for x86-Linux times() really is a system call and thus really
returning
Harald > clock tickes.
Harald >
Harald > for DEC Unix times() again is implemeted using getrusage/gettimeofday
Harald > (thanks to Linux strace ;-) but here CLK_TCK is 60 :-(
Harald >
Harald > I slipped into this when I tried to figure out why I get different
Harald > CPU time results for my "benchmark" fortran application which I
Harald > compiled with both gcc and DEC-cc using the same f2c-converted C
Harald > sources. [...]
Thanks Harald: I had similar trouble with Linux-Alpha times(`2') some weeks
ago, but I was too busy [?] to have a look in the source code for times() in
Linux-Alpha libc.
Harald > [...] I've checked the
Harald > correct cpu time output first with "time program ..."
A wise idea, since the time(1) command itself used to return silly numbers on
Linux-Alpha, e.g., on the [so-called `obsolete'] BLADE_0.3, and perhaps
on the first RedHat Linux-Alpha ("2.1-beta") release also.
In response to the remarks I made on time(1)/times(2|3), David M-T gave me
the following explanation (along with a quick source code fix):
there was a bug in the current libc [<= .040 ], that would be fixed in a
future release for it.
So the Linux-Alpha old times story was not quicked off by the modern
headers+libc, by the RedHat Linux-Alpha 2.1 release, etc. ? Strange?
Not so much, I think.
Your response, David, sounds ubiquitous to me:
David > Harald> for DEC Unix times() again is implemeted using
David > Harald> getrusage/gettimeofday (thanks to Linux strace ;-) but here
David > Harald> CLK_TCK is 60 :-(
David >
David >This seems the "standard" value. It's the same value that glibc uses.
David >I don't think there is anything in POSIX requires CLK_TCK to equal HZ.
David >And since OSF/1 uses 60 as well, it's probably better to stick with
David >that value.
While the Linux[-Alpha] system interfaces do not intend to
conform with the XPG4 specs, we could pick some ideas inside. The XPG4 specs
for times() are (an overview only):
#include <sys/times.h>
clock_t times(struct tms *buffer) ;
[...]
RETURN VALUE:
Upon sucessfull completion, the times() function returns the elapsed
real time, in clock ticks, since an arbirary point in the past [...].
[...]
APPLICATION USAGE:
Applications should use sysconf(_SC_CLK_TCK) to determine the number of
clock ticks per second as it may vary from system to system.
[...]
Issue 4
The following changes are incorporated for alignment with the
ISO-POSIX-1 standard:
. All references to the constant {CLK_TCK} are removed.
[...]
I don't know if the sysconf() call mentioned above, or similar, is supported
the current libc/kernel of Linux-Alpha. If not, defining
CLK_TCK in the system headers, and giving to it a different value
than the one for HZ could be messy, beacause it's unusual.
This sort of things could lead some people --since you are not the 1st to
report things like that, Harold-- to DISTRUST the Linux-Alpha C libraries/
system headers, and perhaps also to distrust the current Linux-Alpha gcc;
this is to prefer, as soon posssible, to borrow tools to Digital
Unix when delevelopping/porting applications for Linux-Alpha. I am not
talking of performances here, but of the ability of re-using existing source
code with limited headhaches when porting it to Linux-Alpha.
About using the Digital compiling chain instead of the Linux-Alpha one, it's
not the legal issues which are, perhaps, the most dangerous, but the technical
ones: Linux-Alpha may behave unlike DEC Unix in respect to some system
interfaces!
E.g., the definition for clock_t is `long' for (some?) Linux-Alpha,
[see <asm/types.h>], but `int' on Digital Unix (V1.3) [see <sys/types.h>].
David >IMHO: avoid times() if you can...
David >
David > --david
? I would prefer to use times() than getrusage()/gettimeofday();
I don't mind how times() is implemented in the system headers /
the libc / the kernel... if it works "as usual". Support for times()
is granted by both SVID and POSIX, while getrusage()/gettimeofday() are
available only on platforms that include some BSD compatibility.
For the future: Does anybody know what are the Linux-Alpha today
priorities in respect to the compliance/compatibility of its system interfaces
(its APIs):
a) to be POSIX[x]-compliant, as Linux-Intel is ?
b) to be BSD-compliant, as Linux-Intel is ? [e.g., to easy the port of BSD
commands/utilities]
c) to be (fully?) compatible with the Linux-Intel APIs ? [they are many...]
d) to be/to remain compatible with Digital Unix (aka DEC OSF1),
at source level and/or at binary level ? [e.g., "almost" compatible]
d) others (e.g., XPGx, 64-bit interfaces).
I guess it's a difficult choice.
Misc:
- I don't talk about SPEC1170, since I did not yet have the chance? to
develop/port for such;
- the souce code for the Linux time(1) command can be configured to use
either times() or getrusage() : it is worthy to read it.
fred
email: froy@gr.osf.org -- www: http://www.osf.org