Re: bit.lshift and performance - luabitop v.s. lua-5.2.0-work4

[KHMan <keinhong@...>]

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
> [0, 32].

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 
returned)

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?

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia