Hacker News Reader

Comment by dmpk2k | Hacker News Reader

If you're referring to LuaJIT 1 vs 2, the big differences are that LuaJIT 2 has a trace-tree JIT, and interpreters for each platform written in assembly. The improvement in performance is significant: LuaJIT2's interpreter alone is faster than LuaJIT1's JIT.

It's hard to compare LuaJIT1 and 2, since LuaJIT2 is the most advanced JIT for a dynamically-typed language on the planet. The performance it can achieve with zero type annotations still blows me away.

View on HN

Pedantry: it's actually not a trace-tree JIT. It doesn't treat traces as trees. See: http://lambda-the-ultimate.org/node/3851#comment-57679

Yes. Thats a very importend point, its one of the majar diffrences between LuaJit and most other advanced trace jits.

Also everybody should read that thread, at least once a year.

What an amazing thread. Thanks

I think you're forgetting the gold standard in dynamic languages from the 80s: Common Lisp. It's still around, and it's still faster than almost every other dynamically typed language out there.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

Half of the benchmarks are less than a factor of 2x slower than C, which is better than even GHC can do for Haskell.

Edit: Disclaimer: http://shootout.alioth.debian.org/dont-jump-to-conclusions.p...

This code does do 'safety 0', which make lisp much closer to C (no array out-of-bounds checks, no int overflow checks among others).

There is no need for LuaJIT to generate completely unsafe code to achieve it's performance.

Well, dmpk2k did say "with zero type annotations". How does SBCL fare without them?

Careful, you might hurt some people's feelings. Has anyone done a systematic comparison of LuaJIT's performance with PyPy's?

Yes, on synthetic benchmarks for LuaJIT-2.0.0-beta10 and PyPy 1.9. Those numbers need updating for the latest versions, but the basics are as follows. LuaJIT is incredibly fast to warm-up. On short benchmarks (around a second or less), it is way ahead of PyPy. As code runs for longer and longer, PyPy tends to catch up, and sometimes overtake, LuaJIT.

My experience of RPython and PyPy suggests that there is a fair bit of scope for reducing some of the warm-up cost. I don't think PyPy will ever match LuaJIT's warm-up time, but it may well move quite a bit closer over time. It'll be interesting to see.

Are you sure PyPy can overtake LuaJit after warmup. I think it can maybe do it in a micro benchmark but I doute that in a complex benchmark PyPy has any chance.

LuaJit uses more advanced elimnation of loads and other optimications, also Lua is easier to optimize in generall.

I dont know the numbers but I would really be astunished if that was true.

Any way to of the cooles projects around.

To me, the real deciding factor that tells me that LuaJIT will win in the long run is that LuaJIT traces the high-level semantics of Lua, whereas PyPy has to work with Python bytecode, which may have a considerable amount of lost information. There are some good examples in the lambda-the-ultimate thread (for example, optimizing based on the knowledge that HLOAD and ASTORE will never alias).

PyPy can't feasibly optimize the high-level Python AST, because the language is very large compared to Lua, and more or less behaviorally defined by Python's bytecode compiler.

This is one of the interesting things about LuaJIT: it demonstrates the value of a small, well-designed language in a shockingly awesome way. The care that the Lua designers put into making Lua simple and regular is one of the reasons why a single programmer (a demigod, yes, but still — one demigod) is able to make so impressive an implementation.

> Are you sure PyPy can overtake LuaJit after warmup. I think it can maybe do it in a micro > benchmark but I doute that in a complex benchmark PyPy has any chance.

When comparing the performance of different languages, micro benchmarks are about all we have, for better or worse. The best we can do is to run a fair number of different such benchmarks and make the comparison over them. I made my statement on the basis of such a comparison.

Both LuaJIT and RPython / PyPy are very clever systems and there's a surprising amount of overlap between the way they do things. But every system has its own strengths and weaknesses, and it doesn't surprise me personally that neither one is a winner 100% of the time.

I don't think PyPy is faster. Their design is significantly more complicated and thus takes longer to tune. Additionally I think python is a small bit more dynamic then Lua, complicating things.

I remember seeing a comparison between LuaJit and V8, both of which are highly tuned. LuaJit won on some of the benchmarks while V8 won others, and there were actually bit of a difference in the performance. That's the problem with Jitting, it's all tradeoffs. So what's good for a Jit in a browser is different from what's good in server environment. So you have to make a lot of benchmarks, testing widely different things, while at the same time not spending more time on optimizing one benchmark implementation in one language more than another.

Reply on news.ycombinator.com