 |
lua-l archive |
|
|
||
|
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 5.3?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 /\ www.asciiribbon.org - against proprietary attachments