Hacker News Reader

The article already explains this, doesn't it? The code had both a Trace-JIT and a Method-JIT [1], but that switching between the two to use the fastest is problematic and that its apparently easier to get the Method-JIT to incorporate more advanced optimization and outperform the Trace-JIT in the end.

If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise.

I'm not an expert but the existence of "SpiderMonkey" "TraceMonkey" "JeagerMonkey" and "IonMonkey" (which can apparently be disabled independently) seems to suggest they have no problems with that.

[1] I presume there is always a fallback interpreter as well.

The method I talked about would work diffrent let me expand a little. I can imagen that jumping between two jits is problematic spezially if there is an interpreter throwen in. The method I talk about would use a simple method jit that generates assembly and the code to enable tracing. This compiler would not optimize anything only get rid of the interpreter overhead. Then the trace jit would jump in if it finds a worthy trace. There would be no switching between the two only from one to the other. In the LtU thread they talk about this too.

I don't read anywhere that the method-jit is better in optimizing, i only that the trace-jit dosn't find enought stuff to win. Once you have a good trace you can optimize it like crazy.

Mozilla seams to move in this direction, they have thrown out Tracemonky but in the longrun add one again and as far as I know the want to throw out spidermonky too. The diffrence would be that they would have more power in the method jit and less in the trace jit.

The reason I said that they would have reimplemented alot is that for the intepreter/simple-jit method and trace-jit to work well you need a nicly designed bytecode and I'm not sure they have one atm (I don't really know). There existing implmentation would have to be reworked to use a new bytecode.

Part of the reason is also that Mike Pall is actually a hyper-advanced cyborg from the future.

In case you're not sure what I'm talking about, read through the LuaJIT source code at some point. It's a thing of beauty - he's handcrafted assembly to make everything run as fast as possible, on all of x86, x64, PowerPC and now ARM.

Yes.

"LuaJIT 2.0 intellectual property disclosure and research opportunities" <http://article.gmane.org/gmane.comp.lang.lua.general/58908&#...; is further proof to that.

Rumor has it that Mike Pall is actually a collective pseudonym used by an army of cycle counting language expert cyborgs (from the future).

Mike Pall is awesome but Mozilla has a hord of very talented compiler guys. They have to fight against legacy code and a badly designed language.

I have learned alot about LuaJit already and I will digg into it more in the future.

The article says the tracing JIT can be faster for tight, non-branchy code. I imagine that Lua programs would be tighter and less branchy than JavaScript, which has many small callback functions invoked by native code.

I would rather say that article says that the trace jit they build is only faster for tight, non-branchy code. I would say that the generall JS programmen has this property but Mike Pall has showed that in the end trace-jit are better. He wrote LuaJit 1 witch is a method jit and LuaJit 2 witch is a trace-jit and his conclution with luajit one was that he hit a performance wall.

"Lets see who comes out with the best implementation in the long run."

How does this differ from what in fact happens?

When theory and reality conflict, reality is correct. If tracing JIT didn't work as well as you expected, it is not reality that is wrong.

Its not diffrent. I was discribing what was happening.

Well I think the evidence is not fully in on that jet. Method Jits are much older and there is a alot of reserach done in it spezially the old Self papers. Almost everything done in JS has allready been used in Self. Even some of the same people work on the JS implmentation.

Tracing jit are relativly reason and LuaJit shows how it can work out. It could well be in the end a compination of both is best.