lua-users home
lua-l archive

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

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

-- Roberto

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!

-- Lorenzo

()  ascii ribbon campaign - against html e-mail
/\   - against proprietary attachments