Re: Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

[Dirk Laurie <dirk.laurie@...>]

I ran your code under various Lua versions.

Interestingly, LuaJIT was only slightly (maybe 10%) faster
than any of the authentic implementations.

The most interesting result, though, occurred in Lua 5.1.
'select' for very short varargs is indeed very fast.

    There was a young lady named Bright
    Who travelled much faster than light.
       She set out one day
       In a relative way
    And arrived on the previous night.

$ lua5.1 vabench.lua
Lua 5.1, N: 1000000
select #: 0  time: -0.128542 secs
{...}  #: 0  time: 0.003643 secs
select #: 1  time: -0.087071 secs
{...}  #: 1  time: 0.094904 secs
select #: 2  time: -0.036425 secs
{...}  #: 2  time: 0.115786 secs
select #: 3  time: 0.030874 secs
{...}  #: 3  time: 0.134189 secs
select #: 4  time: 0.083375 secs
{...}  #: 4  time: 0.156138 secs
select #: 5  time: 0.139583 secs
{...}  #: 5  time: 0.176892 secs
select #: 6  time: 0.196689 secs
{...}  #: 6  time: 0.195809 secs
select #: 7  time: 0.258292 secs
{...}  #: 7  time: 0.232934 secs
select #: 8  time: 0.275769 secs
{...}  #: 8  time: 0.250699 secs
select #: 16  time: 0.920754 secs
{...}  #: 16  time: 0.442022 secs
select #: 32  time: 2.65527 secs
{...}  #: 32  time: 0.765552 secs
select #: 64  time: 8.930093 secs
{...}  #: 64  time: 1.392816 secs

2016-06-23 13:16 GMT+02:00 Philipp Janda <siffiejoe@gmx.net>:
> Am 23.06.2016 um 11:53 schröbte Viacheslav Usov:
>>
>> On Thu, Jun 23, 2016 at 11:30 AM, Dirk Laurie <dirk.laurie@gmail.com>
>> wrote:
>>
>>> It is in fact slightly faster with this example to use a variadic
>>
>> function (perhaps because the table is local at a shallower level?), but
>> not very much.
>>
>> So for n > 9, there is no reason to prefer select over {...}.
>
>
> No performance reason at least. One advantage of `select` is that you can
> preallocate stack space so that the iteration itself won't allocate memory
> and thus can't raise an error. But this only matters if you are really
> paranoid about your deterministic cleanup (there was a thread a while ago).
>
>>
>>> The moment that you put an upper bound on n, there is no more any
>>
>> theoretical distinction between O(1), O(n) and O(n²).
>>
>> In practical computer science, there is ALWAYS an upper bound. Just like
>> the tests so far ALL had it.
>>
>>> If the upper bound is small enough (and I'd say in this case that
>>
>> anything less than LUA_MINSTACK qualifies on that score), there is no
>> practical distinction either.
>>
>> I'd say we should just see the facts, the whole nine of them :)
>
>
> I have attached another micro benchmark for iterating varargs. It appears
> that the break-even point is around 4 arguments in `...` (which is sooner
> than I expected):
>
> Lua 5.2, N: 1000000
> select #: 0  time: 0.106569 secs
> {...}  #: 0  time: 0.121158 secs
> select #: 1  time: 0.122787 secs
> {...}  #: 1  time: 0.190752 secs
> select #: 2  time: 0.161029 secs
> {...}  #: 2  time: 0.215188 secs
> select #: 3  time: 0.227528 secs
> {...}  #: 3  time: 0.244925 secs
> select #: 4  time: 0.283881 secs
> {...}  #: 4  time: 0.283572 secs
> select #: 5  time: 0.322693 secs
> {...}  #: 5  time: 0.290039 secs
> select #: 6  time: 0.392189 secs
> {...}  #: 6  time: 0.317025 secs
> select #: 7  time: 0.437019 secs
> {...}  #: 7  time: 0.35054 secs
> select #: 8  time: 0.496888 secs
> {...}  #: 8  time: 0.387774 secs
> select #: 16  time: 1.017306 secs
> {...}  #: 16  time: 0.583985 secs
> select #: 32  time: 2.523032 secs
> {...}  #: 32  time: 0.970641 secs
> select #: 64  time: 7.447786 secs
> {...}  #: 64  time: 1.812242 secs
>
>
>>
>> Cheers,
>> V.
>>
>
> Philipp
>
>