Subject: Re: [linux-audio-dev] EVO 0.0.5 released , resampling (interpolation) support added
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Sep 20 2000 - 01:00:27 EEST
On Tue, 19 Sep 2000, Karl JH Millar wrote:
>
> I think what you're seeing here is that 1.5 is actually 1.5 + something small,
> which the FPU correctly rounds to 2. 2.5 is 2.5 - something small, which is
> again correctly rounded to 2 as well. Remember that floating point numbers
> aren't exact.
nope, Intel manuals specify this rounding behaviour explicitly,
(they have chosen it because it delivers the best results on a large chain of
operations)
and 1.5 can for example be represended exactly in floating point
because it's mantisse is 1.100000000 .....
>
> > so what I had in mind is the following:
> > fistl the pos value so that you get the rounded value
> > store it in pos_int
> > pos_fract = pos - pos_int
> > if(pos_fract >= 1.0) { pos_fract -= 1.0; pos_int++; }
> >
> > or alternatively:
> > pos -= 0.5
> > and repeat the procedure above:
> > fistl the pos value so that you get the rounded value
> > store it in pos_int
> > pos_fract = pos - pos_int
> > if(pos_fract >= 1.0) { pos_fract -= 1.0; pos_int++; }
>
> You should be able to do the latter without the last line and it should be
> fine. On modern processors the latter will be significantly faster. The
> subtraction is a few clock cycles (and can be pipelined). The branch in the
> first case is not readily predictable, and since branch misprediction penalties
> are around 10-20 cycles they will dominate the time the first method takes.
The second method won't work without the last if() due to to the rounding
behaviour described above.
So even with this final if() , do you still believe that method 2 will be
faster ?
At least in the second case the if is executed very seldom, thus the CPU
should achieve a high amount of hits when doing branch prediction.
does this make sense ?
Benno.
This archive was generated by hypermail 2b28 : Wed Sep 20 2000 - 00:09:46 EEST