Re: JavaScript to Lua compiler

[Tim Caswell <tim@...>]

While of course you'll have better performance writing hand-tuned lua
in luvit than auto-generated lua from javascript, I don't think the
performance cost is as bad as you think.

The bulk of time spent in most luvit programs is *not* running lua
code.  It's making calls into the C library.  Just for fun, I took one
of my benchmarks and disabled the jit option in luajit (which should
make pure lua execution up to 64 times slower) and it was only about
2% slower!  Also comparing the same benchmark to an equivalent program
in nodejs and luvit was 4 times faster.  After digging in and talking
to someone on the V8 team, it seems the main difference was the fact
that V8's js/c++ boundary is much slower than the lua/C translation in
luajit.

So yes, auto-generated lua code would be slower, but I don't think it
would be very significant to overall program speed.  Also since luvit
uses 40 times less ram than node in my tests, you might even come out
ahead there too.

The harder problem would be making a clean and complete translation of
features.  The two languages are surprisingly similar but very
different in deep ways.

On Fri, Nov 18, 2011 at 9:33 AM, Axel Kittenberger <axkibe@gmail.com> wrote:
> Agreed
>
> Am 18.11.2011 16:21 schrieb "Javier Guerra Giraldez" <javier@guerrag.com>:
>>
>> On Fri, Nov 18, 2011 at 10:14 AM, Axel Kittenberger <axkibe@gmail.com>
>> wrote:
>> >> you're comparing apples to oranges dressed as apples.  won't be fair.
>> >
>> > Why is nodejs to luvit like apples to oranges?
>> > BTW one -can- compare apples to oranges.
>>
>> my point is that if you use emulation or translation to compare, then
>> you're comparing a whole system with another that includes (heavy)
>> overhead from the emulation.  it sure can be done; but it's not a fair
>> comparison.
>>
>> --
>> Javier
>>
>