Re: luaJIT vs. lua-llvm

[Eric Wing <ewmailing@...>]

On 1/29/13, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 8:07 AM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
>> wouldn't even consider llvm-lua for my own uses. If I needed MORE speed
>> than
>> LuaJIT, and for whatever reason I didn't want to just use C++, I'd
>> probably
>> switch to a new language -- Google's "Go" [3] feels a bit like Lua to me,
>> for instance, and it gets the benefits of predefined types, which can
>> allow
>> a static compiler to create well-optimized code.
>
> Go does feel Lua-ish in many ways.  The entertaining thing is everyone
> believed your last sentence until the tracing compilers (particularly
> LuaJIT) showed that dynamic languages can touch C speed (although not
> as reliably) even without the apparently essential benefit of static
> typing to assist the compiler.
>
> Static typing has other advantages (thorough compile-time errors[1]
> and good IDE support[2]) but speed appears no longer to be one of
> them.
>
> steve d.
>

Yeah, I think people confuse static typing for performance. The common
example I see people give is C++ STL std::sort vs C qsort, pointing
out the former is usually faster, using "stronger" typing (ignoring
inconvenient truths about broken typing such as NULL) as the pretense
for the reason. They never actually acknowledge or recognize the
reason is everything gets inlined when you use a template (and you get
the code bloat as the cost/no-free-lunch trade-off) and has nothing to
do with typing.

(C++ myths and brokeness aside, I really like the ideas behind Google Go.)


Anyway as to lua-llvm, I don't think it has been touched in awhile,
but I think the author (Robert Jakabosky) is still interested in it
and the related project slua. And I have a bunch of crazy ideas for
them.

So others have touched on the performance aspects where LuaJIT wins.
But I've dreamt up other aspects for llvm-lua which I think are
compelling and interesting and hope they eventually materialize.

The first is tools. Speaking as somebody who doesn't really know the
details of llvm so I could be totally off, having a tool chain that
makes LLVM aware of Lua seems potentially useful to me from a tools
standpoint. From a very high level, we've seen what Apple has done
with LLVM and Xcode. You get syntax highlighting, autocompletion, live
validation, 'fix it' suggestions, and you get debugging and profiling
tools. I'm wondering/hoping there is a way to tap all that ultimately
through the llvm-lua project. Imagine a new generation of IDEs that
can be made, geared towards Lua.

For slua, it is interesting for platforms where JITs (mprotect) are
banned, e.g. iOS, Windows 8 Phone, Windows App Store, possibly some
consoles. If good optimizations can be applied by compiling it down,
it may be appealing in this case. RubyMotion is leading the way in
this arena. For LuaCocoa, I'm thinking that static analysis via slua
could be used to short circuit Objective-C method invocations at
compile time avoiding the cost of doing string lookups for selector
names at runtime which would be a big performance win.

Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/