On 7/3/2014 8:29 PM, chen wrote:
> At 2014-07-04 03:00:31,"Derek Buitenhuis" <derek.buitenh...@gmail.com> wrote:
>> On 7/3/2014 7:40 PM, Min Chen wrote:
>>> - double scale = pow((double)2, g_maxCUSize / 16);
>>> + static const uint32_t scaleTable[] = {2, 4, 16};
>>> + uint32_t scaleIndex = (g_convertToBit[g_maxCUSize] + 2 - 4);
>>> + double scale = (double)scaleTable[scaleIndex];
>>> + X265_CHECK(pow((double)2, (int)(g_maxCUSize >> 4)) == scale,
>>> "Failed on scale!\n");
>>
>> Any reason you cant just use 1<<N ?
> In here, you need (1 << (1 << N)), it is more operators
Uh? Do yo perhaps mean:
double scale = (double)(1 >> (g_maxCUSize / 16)); // Yes, every compiler
can figure out that /16 is >>4. Seriously.
So, two operations one var access.
Yous has one operation, two table accesses, one var access.
My money is that it is *possibly* slower due to cache misses, but that is
just wild speculation by me.
Just my 1 cents on micro-optimzation via obfuscation.
- Derek
_______________________________________________
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
