[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.2 (rc1) now available
- From: Coda Highland <chighland@...>
- Date: Mon, 23 Nov 2015 21:21:54 -0800
On Mon, Nov 23, 2015 at 4:57 PM, Hisham <firstname.lastname@example.org> wrote:
> On 23 November 2015 at 11:31, Roberto Ierusalimschy
> <email@example.com> wrote:
>> If by "nuisance" you
>> mean expensive, we only call it for partitions larger than 100, so
>> it seems their cost is quite diluted in the sort work.
> Are you sure? The first thing I thought when I saw this thread was
> "what!? table.sort now invokes system calls!?"
> In a quick test here, where I looped a million times sorting tables
> with 200 elements, the overall test in the new version took 50s and it
> spent 0.45s in kernel time (whereas in previous Lua versions, of
> course, 0s are spent in kernel time for the same test). The constant
> back-and-forth between userspace and kernel can be seen running that
> test via strace.
> That's on Linux; in my experience going through syscalls on Cygwin,
> for example, is way more expensive.
> Isn't it possible to, alternatively, initialize a PRNG once with the
> clock data when the VM loads and then produce values from that for
> table.sort? (Or is producing pseudorandom numbers more expensive than
> context-switching twice to get time and clock data?)
> -- Hisham
Initializing it with the value of clock() on startup nullifies much of
the benefit of doing it at all. The whole point is that the input to
the PRNG needs to be unpredictable.
That said, clock() alone is sufficient, so time() could be cached on
startup, which would cut the number of syscalls in half.