Re: [ANN] Lua BitOp 1.0.0 released

[Mike Pall <mikelu-0812@...>]

Tim Channon wrote:
> loop baseline     65.4 ns
> tobit            286.1 ns
> [...]
> 
> XP, Watcom 1.7a, 4.3 AMD X2, slow RAM, be on one core.

Ignacio Burgueño wrote:
> loop baseline     72.3 ns
> tobit            240.3 ns
> [...]
>
> Intel CoreDuo 1.66 GHz, 667 MHz FSB, 2MB L2 cache, 2 GB RAM

Well, these timings are suprisingly slow. On a 3 GHz Core 2 Duo
E8400, everything compiled with GCC 4.1.2, I get:

loop baseline     15.5 ns
tobit             48.3 ns
[...]

I don't believe that GCC is that much better than either Watcom C
or whatever Ignacio used to compile Lua. Have both of you compiled
with full optimization and in release mode? And without Lua API
assertions? IMHO there should be a maximum factor of 2x-3x between
our timings.

Ignacio Burgueño wrote:
> However, the following does not act as expected:
> lua5.1 -lluarocks.require d:\Lua\LuaBitOp-1.0.0\nsievebits.lua 9
>
> Primes up to  5120000   356244
> Primes up to  2560000   187134
> Primes up to  1280000    98610
>
> Surely it's because nsievebits.lua uses 'arg' and my build of Lua has
> LUA_COMPAT_VARARG disabled.

Nope, that's the expected output. The argument is exponential, see
the description in doc/install.html. And 'arg' is used to get the
Lua command line arguments, not a vararg function argument.

--Mike