[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: bit.lshift and performance - luabitop v.s. lua-5.2.0-work4
- From: KHMan <keinhong@...>
- Date: Fri, 15 Oct 2010 12:02:00 +0800
On 10/15/2010 10:00 AM, David Manura wrote:
On Thu, Oct 14, 2010 at 10:46 AM, KHMan wrote:
On 10/13/2010 10:34 AM, David Manura wrote:
Another area of difficulty involves a function that reverses the order
of bits ....
Do you have timing data on the relative cost of building the Huffman trees?
Should check it before deciding on whether to optimize this. It is called up
to only ~300 times for both tables and this is done once per block of max
64KB of data. In any case, this one is restricted to the lengths of the
Huffman code, 1-15 bits, as stated in the source code.
It is fairly minor. The bit reverse is called only 322 times when
decompressing the ~200KB lua-5.1.4.tar.gz.
The more time consuming places seem to deal with the small loops of
reading/writing bits from the stream.
Yeah, I agree it would be nice to have bit retrieval running with
a range of [0,31] on both Lua implementations. Most distance codes
need extra bits.
In which case, IIRC the original:
local bits = bit.band(buffer, bit.lshift(1, nbits)-1)
*did* work sanely for 0-31 bits for both Lua. Looks good to me :-)
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia