[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (work1) now available
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Tue, 09 Jul 2013 17:23:15 +0200
On 09/07/2013 16.56, Roberto Ierusalimschy wrote:
Does this mean that if we don't pay attention to this new behaviour
we could get worse performance than Lua 5.2/5.1 or the only drawback
is simply that we wouldn't gain any performance boost from the new
int arithmetic? May existing scripts exhibit worse performance in
That depends *a lot* on your architecture. My machine is an old Pentium
32 bits, which is famous for its slowness in converting floats to ints.
Even here, I got this performance hit in only one case, which is easily
found by looking for uses of 'floor' in your code. In that particular
case, the next line was enough to solve the problem:
local floor = math.ifloor or math.floor
Thanks for the prompt reply! (@Luiz also)
Just for curiosity: what is the rationale behind this version bump with
this new "int" transparent mechanism? It seems that it complicates the
innards of Lua a lot and appears useful mostly for people working with
some "float hostile" environments. Wouldn't have been easier to improve
support for int types at compile time for people needing Lua working
with an int number type instead?
Moreover it seems mostly a performance improvement (did I miss
something? Are there other advantages besides possible performance
increase?) and this came a bit unexpected to me: I grew the gut-feeling
that a new Lua version would have had some enhancement on the pattern
matching side (lpeg or pattern improvements) or some enhanced/added
meta-mechanisms (new metamehods to enhance table virtualization
capability or some "macro-like" facility).
I admit I could have been utterly mislead, though - I've some 4000
unread lua-l posts in my mailbox - over past 2 yrs :-).
Thank you again and keep up the good job!
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments