This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g77 second function always returns 0.0 on mingw32/egcs-1.1
- To: khan at xraylith dot wisc dot edu
- Subject: Re: g77 second function always returns 0.0 on mingw32/egcs-1.1
- From: N8TM at aol dot com
- Date: Sat, 26 Sep 1998 02:16:38 EDT
- Cc: David dot Billinghurst at riotinto dot com dot au, egcs at cygnus dot com
In a message dated 9/25/98 12:21:32 PM Pacific Daylight Time,
khan@xraylith.wisc.edu writes:
> a testcase for your changes
I checked the results of running libf2c/libU77/u77-test.f (Dave Love's test
program) on your binary distribution of egcs-1.1 for cygwin32, and with the
standard egcs-19980914, under W95. Reading somewhat between the lines, I see
that the standard version requires over 1000 times as long to obtain a clock
tick, and even so never registers a non-zero result for etime() or dtime().
So this test program shows that your distribution behaves as I intended. The
test program doesn't call cpu_time() or second(), but the compiler treats
these as aliases for etime().
A longer way to test the timers is to use them to run Livermore Kernels or
some similar application which tests the resolution, overhead, and
repeatability of timer calls. The resolution of cpu_time et al under W95 with
Mumit's egcs-1.1 binary is about 6 microseconds, or about 7 ticks of the SCT
timer.
BTW, the hpux version of etime() has .010 seconds resolution for the returned
value of (user + system time) but the resolution of user time by itself is
1.000 second, so I won't shed any tears when they get around to providing
cpu_time(), which doesn't give access to separate user and system times.
Likewise, my linux has a resolution of .050 seconds for the separate
components of etime() and a resolution of .01 seconds for their sum.