[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Best Practices for Lua -> "Lua+"?
- From: "Alexander Gladysh" <agladysh@...>
- Date: Mon, 24 Mar 2008 14:36:49 +0300
On Mon, Mar 24, 2008 at 2:09 PM, Asko Kauppi <email@example.com> wrote:
> Yes, LNUM patch is at the moment The way to optimize Lua integer
> I have yet to hear what Lua authors think of the latest version, but
> it would seem to me to be beneficial for the whole language to include
> the patch (or: parts of it).
> The current version does not slow down FP platforms. In places, it
> simplifies the Lua code internally. It has been extensively tested and
> it comes with a test suite to make sure changes wouldn't break anything.
Good. Then I'll clarify my reply to the OP question on changing core Lua:
> >>>> * Seperating LuaNumber into ints/floats for range/performance
> >>>> reasons
1. I have no pressing reason to do that right now.
2. However, as I see from performance charts that it would most likely
benefit my code, I'd like to have it in the core language.
3. Speaking about LNUM patch specifically, I would not apply it unless
I have to -- I'm too conservative, and prefer to have unpatched albeit
somewhat slower Lua.
BTW, is LNUM patch compatible with LuaJIT? Is it needed with LuaJIT at
all? When I would have to divert from pure unmodified Lua for
performance reasons, I'll give LuaJIT a try first -- as it seems to
have greater potential in performance gain. While I have no resources
to invest into this switch yet, I eagerly anticipate it.
Obviously, having faster core language would only delay such switch,
and such switch would only delay heavy algorithmic optimization -- but
both delays may be significant.