lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.