Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

lambda-the-ultimate.org

Post reply on HN
Print view View original

11–19 of 19 posts

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#11

Post by olliej »

ardit33 wrote: post #3
WALoeIII wrote: post #2

This is not an apples to apples comparison, the implemented Languages are fundamentally different. I do think this is an inspiring factoid that shows what is possible with a well done JIT. Go Rubinius!

how are they very different? Syntax aside, Lua and Javascript are actually pretty similar. I would say they actually are close cousins.

One of the big issues is that any JS function can technically walks its own call stack, which makes inlining very difficult, and for many of these tests the ability to inline is actually a fairly substantial advantage.

The basic problem faced by a JS engine is that if it wants to be able to inline a function it has to be able to either:

* Prove that it knows everything that the function may do -- in effect this means you can't inline any functions that themselves call functions, or any functions that interact with any values you can't consider constant, or identify before you enter the inlined code; or

* Have the ability to at any point in time reconstruct the call stack, and all arguments correctly.

One of these choices is exceedingly limiting in what you can do, and the other is vastly complex.

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#12

Post by olliej »

olliej wrote: post #10

One question i have regarding these is how fair are the tests, a very quick look at the tests shows for "pidigits" the lua code has the line: require"c-gmp"(g, aux) Implying that it is using the GNU Multiprecision Library for it's big integer support, whereas the JS code has: load('/home/dunham/shootout/bench/Include/javascript/biginteger.js'); Which is apparently a big integer library implemented in javascript http:…

I have looked at a few of the other tests and nothing obviously pops out as being bogus, so it's likely just this pidigits test which has an unfair advantage

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#13

Post by tumult »

olliej wrote: post #10

One question i have regarding these is how fair are the tests, a very quick look at the tests shows for "pidigits" the lua code has the line: require"c-gmp"(g, aux) Implying that it is using the GNU Multiprecision Library for it's big integer support, whereas the JS code has: load('/home/dunham/shootout/bench/Include/javascript/biginteger.js'); Which is apparently a big integer library implemented in javascript http:…

V8 is implemented in C++, so should you count it as just a really bad C++ benchmark?

The Lua benchmark uses features Lua can use. JavaScript does not have that feature.

http://en.wikipedia.org/wiki/Turing_tarpit

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#14

Post by olliej »

tumult wrote: post #13
olliej wrote: post #10

One question i have regarding these is how fair are the tests, a very quick look at the tests shows for "pidigits" the lua code has the line: require"c-gmp"(g, aux) Implying that it is using the GNU Multiprecision Library for it's big integer support, whereas the JS code has: load('/home/dunham/shootout/bench/Include/javascript/biginteger.js'); Which is apparently a big integer library implemented in javascript http:…

V8 is implemented in C++, so should you count it as just a really bad C++ benchmark? The Lua benchmark uses features Lua can use. JavaScript does not have that feature. http://en.wikipedia.org/wiki/Turing_tarpit

If you're claiming that your interpreter is faster than someone elses you can't make your test depend on a native library for the bulk of the work. That may be a valid argument for "my language is better" but it isn't an argument for my interpreter is faster than yours.

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#15

Post by sjs »

olliej wrote: post #11
ardit33 wrote: post #3

Earlier quoted context omitted.

how are they very different? Syntax aside, Lua and Javascript are actually pretty similar. I would say they actually are close cousins.

One of the big issues is that any JS function can technically walks its own call stack, which makes inlining very difficult, and for many of these tests the ability to inline is actually a fairly substantial advantage. The basic problem faced by a JS engine is that if it wants to be able to inline a function it has to be able to either: * Prove that it knows everything that the function may do -- in effect this means…

As Mike Pall said: "None of the benchmarks make use of JavaScript's weird corners. And all of them can (or could) be reduced to simple constructs. So I wouldn't blame it on the language differences alone (maybe on the implementation)."

Only the use of such a feature should trip the "do it the safe but slow way" switch. Maybe that's not possible here though, I don't know that much about compiler optimization.

edit: I'm not implying it's easy either, but if it's possible the V8 team has the skills to implement it.

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#16

Post by tumult »

olliej wrote: post #14
tumult wrote: post #13

Earlier quoted context omitted.

V8 is implemented in C++, so should you count it as just a really bad C++ benchmark? The Lua benchmark uses features Lua can use. JavaScript does not have that feature. http://en.wikipedia.org/wiki/Turing_tarpit

If you're claiming that your interpreter is faster than someone elses you can't make your test depend on a native library for the bulk of the work. That may be a valid argument for "my language is better" but it isn't an argument for my interpreter is faster than yours.

Language Shootout, not Interpreter Shootout. You're playing directly into the Turing tarpit.

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#17

Post by beagle3 »

olliej wrote: post #11
ardit33 wrote: post #3

Earlier quoted context omitted.

how are they very different? Syntax aside, Lua and Javascript are actually pretty similar. I would say they actually are close cousins.

One of the big issues is that any JS function can technically walks its own call stack, which makes inlining very difficult, and for many of these tests the ability to inline is actually a fairly substantial advantage. The basic problem faced by a JS engine is that if it wants to be able to inline a function it has to be able to either: * Prove that it knows everything that the function may do -- in effect this means…

But 99.9% of JS code doesn't do that, so it should be optimized for that case.

LuaJIT keeps enough info around to go back to the interpreter at the moment anything goes different than previously traced -- I see no reason JS couldn't do the same.

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#18

Post by mikemike »

olliej wrote: post #10

One question i have regarding these is how fair are the tests, a very quick look at the tests shows for "pidigits" the lua code has the line: require"c-gmp"(g, aux) Implying that it is using the GNU Multiprecision Library for it's big integer support, whereas the JS code has: load('/home/dunham/shootout/bench/Include/javascript/biginteger.js'); Which is apparently a big integer library implemented in javascript http:…

Actually reading the Lua mailing list post http://lua-users.org/lists/lua-l/2010-03/msg00305.html, referenced in the linked text might help:

> For pidigits I'm comparing the pure JS and Lua programs, not the GMP bindings.

I'm comparing these two:

http://shootout.alioth.debian.org/u32/program.php?test=pidig...

http://shootout.alioth.debian.org/u32/program.php?test=pidig...

Both are written in pure Lua and JavaScript and do not use a C binding.

Re: "LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

#19

Post by olliej »

mikemike wrote: post #18
olliej wrote: post #10

One question i have regarding these is how fair are the tests, a very quick look at the tests shows for "pidigits" the lua code has the line: require"c-gmp"(g, aux) Implying that it is using the GNU Multiprecision Library for it's big integer support, whereas the JS code has: load('/home/dunham/shootout/bench/Include/javascript/biginteger.js'); Which is apparently a big integer library implemented in javascript http:…

Actually reading the Lua mailing list post http://lua-users.org/lists/lua-l/2010-03/msg00305.html , referenced in the linked text might help: > For pidigits I'm comparing the pure JS and Lua programs, not the GMP bindings. I'm comparing these two: http://shootout.alioth.debian.org/u32/program.php?test=pidig... http://shootout.alioth.debian.org/u32/program.php?test=pidig... Both are written in pure Lua and JavaScript…

The numbers you point to make use of http://shootout.alioth.debian.org/u32/program.php?test=pidig...

Which is using GMP, so maybe that particular link needs to be updated?

Post reply on HN