On Wed, Nov 25, 2015 at 9:22 PM, Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 6:03 PM Timothy Gu wrote:
>
>> On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
>> > +double f = value * cbrt_lut[value] * pow(2, (exponent -
>> 400) * 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
On Wed, Nov 25, 2015 at 6:03 PM Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
> > +double f = value * cbrt_lut[value] * pow(2, (exponent -
> 400) * 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
>
> While at it, you could change pow(2 to exp2(, which h
On Wed, Nov 25, 2015 at 9:03 PM, Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
>> +double f = value * cbrt_lut[value] * pow(2, (exponent - 400) *
>> 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
>
> While at it, you could change pow(2 to exp2(, which
On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
> +double f = value * cbrt_lut[value] * pow(2, (exponent - 400) *
> 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
While at it, you could change pow(2 to exp2(, which has a libm.h shim
and is easily 4 times faster than pow() o
This does some miscellaneous stuff mainly avoiding the usage of pow to
achieve significant speedups. This is not speed critical, but is
unnecessary latency and cycles wasted for a user.
All tables tested and are identical to the old ones
(bit-exact even in floating point case).
Sample benchmark (
