[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: Thu, 14 Oct 2010 13:22:39 +0800
On 10/14/2010 11:55 AM, David Manura wrote:
On Wed, Oct 13, 2010 at 1:12 AM, KHMan wrote:
On 10/13/2010 10:34 AM, David Manura wrote:
local bits = bit.band(buffer, bit.lshift(1, nbits)-1)
...Is there any actual technical problem with using this instead?
bit.rshift(0xFFFFFFFF, 32 - nbits)
One downside is that the code
local bits = bit.band(buffer, rshift(0xffffffff, 32 - nbits))
buffer = bit.rshift(buffer, nbits)
now requires two special cases: nbits == 0 and nbits == 32. Both
actually occur in my code. I don't know if this is a rare case, but
it can affect code containing shifts by both n and 32 - n where n in
I'm sorry, I am interested in this particular problem, but it's
very hard to parse the entire context of the brief description.
I'm guessing there's involvement of Lua 5.1.x, Lua 5.2.x and
LuaJIT, but I can't tell which is which or what's going on with
the special cases.
bit mask for data:
bit.rshift(0xffffffff, 32-0) => 0 (all masked, nothing returned)
bit.rshift(0xffffffff, 32-16) => 65536 (1/2 masked, 1/2 returned)
bit.rshift(0xffffffff, 32-32) => 4294967295 (none masked, all
data left in buffer:
bit.rshift(0x12345678, 0) => 0x12345678 (all left)
bit.rshift(0x12345678, 16) => 0x00001234 (half left)
bit.rshift(0x12345678, 32) = > 0x00000000 (none left)
Well, it seems all right on Lua 5.2.x, at first glance. Do you
have some sample output you can share?
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia