why is times(2) no real system call as `man times' implies ?
for alpha this is implemented in libc using 3 syscalls
getrusage(RUSAGE_SELF, {...})
getrusage(RUSAGE_CHILDREN, {...})
gettimeofday({...}, NULL)
and it is not values in terms of clock ticks (which would be 1024/sec
for Linux/AXP) but are scaled to "CLK_TCK"s which are defined as 100
in <time.h>.
for x86-Linux times() really is a system call and thus really returning
clock tickes.
for DEC Unix times() again is implemeted using getrusage/gettimeofday
(thanks to Linux strace ;-) but here CLK_TCK is 60 :-(
I slipped into this when I tried to figure out why I get different
CPU time results for my "benchmark" fortran application which I compiled
with both gcc and DEC-cc using the same f2c-converted C sources.
this is part of the reason that I reportedsome days before that
gcc compiled f2c-converted code takes twice as much cpu time as
the same DEC-cc compiled binary because I relied on the timing
output of the program itself which uses times(2). I've checked the
correct cpu time output first with "time program ..." for the gcc version
and forgot to do the same for the DEC unix binary (partly because I didn't
have the idea that a "system call" can return different values for
differenct compiler/libc combinations (when returning reasonable values
which shows that the syscall succeeded...). so the cpu ratio between
the gcc and cc compiled programs are only 1.2.
for completeness here are the CPU times for this program for
gcc and cc (using f2c), DEC f77 and f90, always using "-O2":
gcc_ratio
gcc 1548.95user 8.06system 25:57.20elapsed 99%CPU 1.00
cc 1318.54user 6.93system 22:07.94elapsed 99%CPU 1.17
f77 1030.31user 2.09system 17:14.05elapsed 99%CPU 1.50
f90 1113.64user 2.24system 18:37.76elapsed 99%CPU 1.39
but no reason to be too happy about the optimisation of gcc (since 17% less
wouldn't be that bad for a weird f2c-converted strange fp based C program
only using REAL*4 aka float):
yesterday I run a "virtex" binary from a DEC Unix machine on Linux
(this one used shared libs; after borrowing /sbin/loader and /usr/shlib/libc.so
for this test the binary run fine) and compared it with the Red Hat binary
TeXing texbook.tex which is 494 pages plain TeX). this time
I used /usr/bin/time to get the CPU time and got
GCC binary : 37 seconds
DEC-cc & shared : 22 seconds
which is almost a ratio of 1.7 :-(
tomorrow hopefully I'll get a "stage 1" gcc compiler which has been built
with DEC cc. I'm really curious how much difference in compilation
CPU time this will give...
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^