I worked on lua earlier and performed extensive benchmarking in lua (unfortunately i don't have numbers now). For performance comparison, I used standard benchmark applications like FFT, dense matrix multiplication, Scimark etc. and compared c, LuaJIT, LLVM-Lua (static compilation), LuaVM
I observed that LuaJIT is very close to the performance of c because of tracing JIT.. while normal LuaVM is orders of magnitude slower. This performance can be observed only if operations are in pure lua. If there are calls between other languages Lua -> C/Java, Java/C -> Lua then its performance was poor (din't get much performance gain between Lua and C). Some performance numbers: http://factor-language.blogspot.com/2010/05/comparing-factors-performance-against.html http://attractivechaos.wordpress.com/2011/01/23/amazed-by-luajit/ If required I can get the old performance numbers or experiment it again now. Thanks -- Prasanth On Sep 19, 2012, at 12:42 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > The thought is that a JIT might be a good part of an execution engine. > > The second thought is that LuaJIT is probably very good at dynamically > typed data which will be common with schemaless data like JSON. > > The third thought is that Lua is such a simple language that it might make > an easy target to compile the (as yet unspecified) output of the optimizer > to. > > These are just first thoughts. I think that somebody could look into it > and bring more than first thoughts to the question. Measurements and > examples might be particularly interesting. > > On Tue, Sep 18, 2012 at 7:09 PM, Timothy Chen <tnac...@gmail.com> wrote: > >> I wonder if I missed the discussion or I just don't understand the whole >> picture, but why are we considering LuaJIT as the execution engine? >> >> Are we planning to generate Lua code to be the input into the execution >> nodes? And where does this fit into the architecture (some IR after >> optimizing get transformed into Lua?) ? >> >> Thanks, >> >> Tim >> >> >> >> >> >> On Tue, Sep 18, 2012 at 6:20 PM, NAVEEN MAANJU < >> naveen.maanju.apa...@gmail.com> wrote: >> >>> I can start with project web-site..... >>> >>> On Tue, Sep 18, 2012 at 4:09 PM, Ted Dunning <ted.dunn...@gmail.com> >>> wrote: >>> >>>> Excellent. >>>> >>>> I think that the key next steps are: >>>> >>>> 1) codify some API's (Jason and Julian are on this) >>>> >>>> 2) build out the "hello world" app using the available parser and Optiq >>> and >>>> a trivial data model (#1 is not a blocker for this) >>>> >>>> 3) evaluate where we are implications are relative to nested data and >>>> columnar formats >>>> >>>> Once we have that, we should be able to open up the parallelism of >>>> development massively. >>>> >>>> Some open questions/tasks that many people may be able to determine >>>> include: >>>> >>>> - is it possible to change Optiq operators and optimization rules >>> without a >>>> recompile? >>>> >>>> - what has to happen to make Optiq handle nested data? >>>> >>>> - is LuaJit usable as an execution engine? >>>> >>>> - can somebody build a project web-site? >>>> >>>> - what mechanisms from this: >>>> >>>> http://phdopen.mimuw.edu.pl/lato10/boncz_mimuw.pdf >>>> >>>> actually make sense for Drill. Many do not, such as the stuff to do >> with >>>> updates. Many do make sense. Which ones? Do we have all of the >>> pertinent >>>> papers on the links page? >>>> >>>> >>>> >>>> On Tue, Sep 18, 2012 at 3:23 PM, Dan Di Spaltro < >> dan.dispal...@gmail.com >>>>> wrote: >>>> >>>>> Hey guys, just wanted to reach out to see if I could help with >>>> anything... >>>>> >>>>> I am (along with my employer Rackspace) interested in this project. >>> Even >>>>> though it's early days, I'd love to help in any way I can... anything >>>> from >>>>> event space in SF to coding. I look forward to participating, and >>>> getting >>>>> some of my co-workers to as well. We have a lot of team experience >>>>> operating at scale and could see the need as a service provider who's >>>>> product portfolio is growing. >>>>> >>>>> Let me know if there are any specifics otherwise Ill just keep my eye >>> on >>>>> the list and help where I can, >>>>> >>>>> -Dan >>>>> >>>>> -- >>>>> Dan Di Spaltro >>>>> >>>> >>> >>
