Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's a post by Mike Pall, author of LuaJIT, which explains why writing C is very suboptimal for maximally performant VMs:

http://article.gmane.org/gmane.comp.lang.lua.general/75426

Worth noting that IIRC, for a while LuaJIT in interpreted mode was able to beat V8 in optimized mode not all that infrequently (although it depended on the use case, they are different languages, and I do not know if this is still the case).



> Worth noting that IIRC, for a while LuaJIT in interpreted mode was able to beat V8 in optimized mode not all that infrequently

V8 had no optimizing compiler when Mike Pall sent his (in)famous mail about "LuaJIT interpreter beating V8 compiler"[1].

Also usual disclaimers about cross-language benchmarks apply (e.g. nobody looked how those benchmarks differ between JS and Lua implementation).

[1] http://lua-users.org/lists/lua-l/2010-03/msg00305.html


Common register allocation across different bytecode interpretation sequences was one of the things specifically on my mind that could be tuned using a high-level assembler.

Very suboptimal might be a slight overstatement. I can see a way, given known register calling conventions, that you could write an interpreter written as tail calls and post-process the machine code to effectively JMP instead of CALL. Guaranteed tail calls would save you a bunch of effort, and register calling convention would give you some guarantees about consistent allocation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: