[ECOS] clock() problem?

[ECOS] clock() problem?

[Chris Houston]

Has anyone else encountered strange behaviour when using the "clock()" 
function?  When I use it, the result seems to roll over int 16 bits.

In packages/language/c/libc/time/v1_x_x/src/clock.cxx, in the clock() 
function, if I change

    clocks = ((clock_t)curr_clock * resolution.dividend) /
     (resolution.divisor * (1000000000 / CLOCKS_PER_SEC));  

to

      clocks = (clock_t)((curr_clock * resolution.dividend) /
     (resolution.divisor * (1000000000 / CLOCKS_PER_SEC)));      

then the function seems to behave correctly.  It seems that in 
the first case, the multiplication in the numerator gets truncated to 
32 bits.

Re: [ECOS] clock() problem?

[Hugo Tyson]

Chris Houston <chouston@logikos.com> writes:
> Has anyone else encountered strange behaviour when using the "clock()" 
> function?  When I use it, the result seems to roll over int 16 bits.
> 
> In packages/language/c/libc/time/v1_x_x/src/clock.cxx, in the clock() 
> function, if I change
> 
>     clocks = ((clock_t)curr_clock * resolution.dividend) /
>      (resolution.divisor * (1000000000 / CLOCKS_PER_SEC));  
> 
> to
> 
>       clocks = (clock_t)((curr_clock * resolution.dividend) /
>      (resolution.divisor * (1000000000 / CLOCKS_PER_SEC)));      
> 
> then the function seems to behave correctly.  It seems that in 
> the first case, the multiplication in the numerator gets truncated to 
> 32 bits.

Overflow bites, I guess.  Or maybe a more liberal sprinkling of casts is
needed to make all the maths be 64 bit.

This really needs rewriting to use the C++ clock conversion facility in the
kernel; look for the word "converter" in clock.hxx and also see the
clockcnv.cxx kernel testcase.  Clock converters split

	foo = bar * A / (B * (10^9/CLOCKS_PER_SEC))

into

	foo = bar * P / Q * R / (S * (10^9/CLOCKS_PER_SEC))

where PR==A and QS==B so as to retain accuracy whilst avoiding overflow.

Contributions welcome ;-)

	- Huge

Re: [ECOS] clock() problem?

[Jonathan Larmour]

Hugo Tyson wrote:
> 
> Chris Houston <chouston@logikos.com> writes:
> > Has anyone else encountered strange behaviour when using the "clock()"
> > function?  When I use it, the result seems to roll over int 16 bits.
> >
> > In packages/language/c/libc/time/v1_x_x/src/clock.cxx, in the clock()
> > function, if I change
> >
> >     clocks = ((clock_t)curr_clock * resolution.dividend) /
> >      (resolution.divisor * (1000000000 / CLOCKS_PER_SEC));
> >
> > to
> >
> >       clocks = (clock_t)((curr_clock * resolution.dividend) /
> >      (resolution.divisor * (1000000000 / CLOCKS_PER_SEC)));
> >
> > then the function seems to behave correctly.  It seems that in
> > the first case, the multiplication in the numerator gets truncated to
> > 32 bits.
> 
> Overflow bites, I guess.  Or maybe a more liberal sprinkling of casts is
> needed to make all the maths be 64 bit.

This happened inadvertently a while back due to clock_t being changed to be
more Linux compatible, but it's now fixed (and in anoncvs).

> This really needs rewriting to use the C++ clock conversion facility in the
> kernel;

Too much overhead for something straightforward IMHO.

> look for the word "converter" in clock.hxx and also see the
> clockcnv.cxx kernel testcase.  Clock converters split
> 
>         foo = bar * A / (B * (10^9/CLOCKS_PER_SEC))
> 
> into
> 
>         foo = bar * P / Q * R / (S * (10^9/CLOCKS_PER_SEC))
> 
> where PR==A and QS==B so as to retain accuracy whilst avoiding overflow.

Which is now what clock() does. I think. Depending on what you thing PQRS
are :-).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault