Re: clock(3) non-functional?
On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote: > Hello, > > Svante Signell, le Sun 29 Jun 2014 16:35:42 +0200, a écrit : > > Looking at libsamplerate test problems, I found that clock(3) used > > there is not reliable. Strange results are obtained on too Linux with a > > simple test program. > > What do you mean by "strange"? The output I get > > $ ./test > start = 3870 > end = 3910 > cpu_time_used = 0.40 I get: gcc -g -Wall test_clock.c ./a.out start = 0 end = 0 cpu_time_used = 0.00 ldd ./a.out libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0103f000) /lib/ld.so => /lib/ld.so.1 (0x1000) libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x011ff000) libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x01217000) -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404211307.31104.1.camel@PackardBell-PC
Re: clock(3) non-functional?
Svante Signell, le Tue 01 Jul 2014 12:41:47 +0200, a écrit : > On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote: > > Hello, > > > > Svante Signell, le Sun 29 Jun 2014 16:35:42 +0200, a écrit : > > > Looking at libsamplerate test problems, I found that clock(3) used > > > there is not reliable. Strange results are obtained on too Linux with a > > > simple test program. > > > > What do you mean by "strange"? The output I get > > > > $ ./test > > start = 3870 > > end = 3910 > > cpu_time_used = 0.40 > > I get: > gcc -g -Wall test_clock.c > ./a.out > start = 0 > end = 0 > cpu_time_used = 0.00 Well, yes, as I said sleep() doesn't consume CPU while sleeping, so clock() would only account the small overhead for starting the sleep, which is very small. Since the granularity is 1/100th second on the Hurd, that eventually amounts to zero. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140701120434.ga6...@type.ens-lyon.fr
Re: clock(3) non-functional?
On Tue, 2014-07-01 at 14:04 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 01 Jul 2014 12:41:47 +0200, a écrit :
> > On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote:
> > > Hello,
> > >
> > > Svante Signell, le Sun 29 Jun 2014 16:35:42 +0200, a écrit :
> > > > Looking at libsamplerate test problems, I found that clock(3) used
> > > > there is not reliable. Strange results are obtained on too Linux with a
> > > > simple test program.
> > >
> > > What do you mean by "strange"? The output I get
> > >
> > > $ ./test
> > > start = 3870
> > > end = 3910
> > > cpu_time_used = 0.40
> >
> > I get:
> > gcc -g -Wall test_clock.c
> > ./a.out
> > start = 0
> > end = 0
> > cpu_time_used = 0.00
>
> Well, yes, as I said sleep() doesn't consume CPU while sleeping, so
> clock() would only account the small overhead for starting the sleep,
> which is very small. Since the granularity is 1/100th second on the
> Hurd, that eventually amounts to zero.
Why are the integers start and end zero?
Consider the following program:
#define _GNU_SOURCE 1
#include
#include
#include
#include
int main(void)
{
clock_t start, end;
double cpu_time_used;
int i = 0;
double a = 1;
start = clock();
printf("start = %ld\n", start);
for (i=0; i < 3000; i++)
a /= 1.001;
end = clock();
printf("end = %ld\n", end);
cpu_time_used = end - start;
cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;
printf("cpu_time_used = %f\n", cpu_time_used);
return 0;
}
on Linux I get:
start = 1110
end = 2162016
cpu_time_used = 2.160906
and on Hurd:
start = 0
end = 423
cpu_time_used = 0.000423
I don't believe Hurd is more than 5000 times faster than Linux!
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404218444.31104.7.camel@PackardBell-PC
Re: clock(3) non-functional?
Svante Signell, le Tue 01 Jul 2014 14:40:44 +0200, a écrit : > > > > $ ./test > > > > start = 3870 > > > > end = 3910 > > > > cpu_time_used = 0.40 > > > > > > I get: > > > gcc -g -Wall test_clock.c > > > ./a.out > > > start = 0 > > > end = 0 > > > cpu_time_used = 0.00 > > > > Well, yes, as I said sleep() doesn't consume CPU while sleeping, so > > clock() would only account the small overhead for starting the sleep, > > which is very small. Since the granularity is 1/100th second on the > > Hurd, that eventually amounts to zero. > > Why are the integers start and end zero? For the same reason: the program doesn't even need 1/100th of a second to start, so the CPU consumption is basically zero. > cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC; > > and on Hurd: > start = 0 > end = 423 > cpu_time_used = 0.000423 It seems there is inconsistency between the value returned by clock() and CLOCKS_PER_SEC. See the implementation of clock() on the Hurd in ./sysdeps/mach/hurd/clock.c, it's really in 1/100th of seconds. I guess unsubmitted-clock_t_centiseconds.diff should probably also fix CLOCKS_PER_SEC. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140701124737.gk6...@type.ens-lyon.fr
Re: clock(3) non-functional?
On Tue, 2014-07-01 at 14:47 +0200, Samuel Thibault wrote: > Svante Signell, le Tue 01 Jul 2014 14:40:44 +0200, a écrit : > > > > > $ ./test > > > > > start = 3870 > > > > > end = 3910 > > > > > cpu_time_used = 0.40 > > > > > > > > I get: > > > > gcc -g -Wall test_clock.c > > > > ./a.out > > > > start = 0 > > > > end = 0 > > > > cpu_time_used = 0.00 > > > > > > Well, yes, as I said sleep() doesn't consume CPU while sleeping, so > > > clock() would only account the small overhead for starting the sleep, > > > which is very small. Since the granularity is 1/100th second on the > > > Hurd, that eventually amounts to zero. > > > > Why are the integers start and end zero? > > For the same reason: the program doesn't even need 1/100th of a second > to start, so the CPU consumption is basically zero. > > > cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC; > > > > and on Hurd: > > start = 0 > > end = 423 > > cpu_time_used = 0.000423 > > It seems there is inconsistency between the value returned by clock() > and CLOCKS_PER_SEC. See the implementation of clock() on the Hurd in > ./sysdeps/mach/hurd/clock.c, it's really in 1/100th of seconds. I > guess unsubmitted-clock_t_centiseconds.diff should probably also fix > CLOCKS_PER_SEC. Unfortunately CLOCKS_PER_SECOND if frozen by POSIX to 1 000 000 independent of the actual resolution, see e.g. man 3 clock. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404219541.31104.9.camel@PackardBell-PC
