9 ms·

The article makes a rather hefty claim, that it is comparable or even in some ways faster performancewise than Sun's hotspot JVM. From what I've heard the JVM

by tinco 13y ago

The article makes a rather hefty claim, that it is comparable or even in some ways faster performancewise than Sun's hotspot JVM. From what I've heard the JVM is one of the most heavily researched and optimized bytecode VM out there. Could it really be that some guy can write a competitor in a scripting language in his spare time? Not saying it's impossible, just curious if there's anything to back that claim up, besides the very specific microbenchmarks. edit: I was a bit too quick to comment, reading again he doesn't really claim to be faster at anything other than small loops. Still interested if it's fast at any real world things though.

seiji 13y ago
It's using LuaJIT which regularly advances the state of the art in JIT'd language performance optimizations.
lucian1900 13y ago
Afaict this project isn't actually a JVM, it translates JVM bytecode to Lua and then runs that. It's perfectly reasonable to expect that to be very fast, assuming Lua(JIT) can compete with JVM in speed (which it does).
- tinco 13y ago
  There's usually a problem with that approach and that is when the virtual machine models don't match perfectly. This leads to any feature mismatches to be implemented in a roundabout way often leading to performance problems. An example of this is the projects that implement ruby virtual machines on the JVM and the CLR. Both VM's actually had features added later to better match Ruby's features. If LuaJIT can really execute Java bytecode so efficiently that says a lot for the genericity of the compiler, which makes it pretty awesome tech indeed :)
  - lucian1900 13y ago
    I don't think those two cases are comparable. Ruby is a fairly large and very generic language. It's possible to override pretty much anything, which makes running it efficiently on a runtime that doesn't is hard. On the other hand, JVM bytecode is a tiny, concrete language, pretty much just saver assembly. Few operations are generic, and when they are they're generic on the type of something, not much else. Most languages that are already fast could probably run translated JVM bytecode fast. (And of course LuaJIT is amazing, but for being that fast in the first place)
MrBuddyCasino 13y ago
Well he didn't write a fully jitted VM, this is just sort of translating the JVM opcodes into Lua scripts if I got that right, and then runs those with LuaJit 2. LuaJIT 2 is known to be fast, but I too was impressed by the numbers, outperforming HotSpot is pretty good, even if its just a tiny microbenchmark.
- copx 13y ago
  Seems it could be even faster: http://www.freelists.org/post/luajit/ANN-luje-01 http://www.freelists.org/post/luajit/ANN-luje-01
zeckalpha 13y ago
LuaJIT is heavily researched and optimized. http://article.gmane.org/gmane.comp.lang.lua.general/58908 http://article.gmane.org/gmane.comp.lang.lua.general/58908
pron 13y ago
HotSpot is indeed one of the most optimized runtimes around. It is, however, optimized for large, complex applications. It's quite possible to beat in a carefully designed microbenchmark. Beating it in a complex application is a whole other matter (in fact, it's pretty hard to beat even in C++).
- haberman 13y ago
  > in fact, it's pretty hard to beat even in C++ If there's one thing I've learned, it's that the wishful thinking will never stop.
  - dman 13y ago
    What?
    - deleted 13y ago
      [deleted]
  - peterashford 13y ago
    That's pretty snarky
    - haberman 13y ago
      It's really irritating, as someone who works in C and C++ with good reason, to hear people continually deny the very real performance benefits of working at a lower level. We (C/C++ guys) write the OS's, VMs, browsers, codecs, etc that power your software stacks, and then you (managed language fans) turn around and tell us we're wasting our time by using C and C++, while giving us stuff like Eclipse. So yes, when someone says it's hard to beat Java with C++, it inspires some snark. Write the next JVM in Java if you think it's that easy.
      - hermanhermitage 13y ago
        This is what happens when an important variable (the specific problem domain of performance comparison) is left as a free variable :-)
aaronblohowiak 13y ago
> In any non-trivial benchmark it usually manages about 50% to 75% of Hotspot.

by tinco 13y ago

seiji 13y ago

It's using LuaJIT which regularly advances the state of the art in JIT'd language performance optimizations.

lucian1900 13y ago

Afaict this project isn't actually a JVM, it translates JVM bytecode to Lua and then runs that. It's perfectly reasonable to expect that to be very fast, assuming Lua(JIT) can compete with JVM in speed (which it does).

tinco 13y ago
There's usually a problem with that approach and that is when the virtual machine models don't match perfectly. This leads to any feature mismatches to be implemented in a roundabout way often leading to performance problems. An example of this is the projects that implement ruby virtual machines on the JVM and the CLR. Both VM's actually had features added later to better match Ruby's features. If LuaJIT can really execute Java bytecode so efficiently that says a lot for the genericity of the compiler, which makes it pretty awesome tech indeed :)
- lucian1900 13y ago
  I don't think those two cases are comparable. Ruby is a fairly large and very generic language. It's possible to override pretty much anything, which makes running it efficiently on a runtime that doesn't is hard. On the other hand, JVM bytecode is a tiny, concrete language, pretty much just saver assembly. Few operations are generic, and when they are they're generic on the type of something, not much else. Most languages that are already fast could probably run translated JVM bytecode fast. (And of course LuaJIT is amazing, but for being that fast in the first place)

MrBuddyCasino 13y ago

Well he didn't write a fully jitted VM, this is just sort of translating the JVM opcodes into Lua scripts if I got that right, and then runs those with LuaJit 2. LuaJIT 2 is known to be fast, but I too was impressed by the numbers, outperforming HotSpot is pretty good, even if its just a tiny microbenchmark.

copx 13y ago
Seems it could be even faster: http://www.freelists.org/post/luajit/ANN-luje-01 http://www.freelists.org/post/luajit/ANN-luje-01

zeckalpha 13y ago

LuaJIT is heavily researched and optimized. http://article.gmane.org/gmane.comp.lang.lua.general/58908 http://article.gmane.org/gmane.comp.lang.lua.general/58908

pron 13y ago

HotSpot is indeed one of the most optimized runtimes around. It is, however, optimized for large, complex applications. It's quite possible to beat in a carefully designed microbenchmark. Beating it in a complex application is a whole other matter (in fact, it's pretty hard to beat even in C++).

haberman 13y ago
> in fact, it's pretty hard to beat even in C++ If there's one thing I've learned, it's that the wishful thinking will never stop.
- dman 13y ago
  What?
  - deleted 13y ago
    [deleted]
- peterashford 13y ago
  That's pretty snarky
  - haberman 13y ago
    It's really irritating, as someone who works in C and C++ with good reason, to hear people continually deny the very real performance benefits of working at a lower level. We (C/C++ guys) write the OS's, VMs, browsers, codecs, etc that power your software stacks, and then you (managed language fans) turn around and tell us we're wasting our time by using C and C++, while giving us stuff like Eclipse. So yes, when someone says it's hard to beat Java with C++, it inspires some snark. Write the next JVM in Java if you think it's that easy.
    - hermanhermitage 13y ago
      This is what happens when an important variable (the specific problem domain of performance comparison) is left as a free variable :-)

aaronblohowiak 13y ago

> In any non-trivial benchmark it usually manages about 50% to 75% of Hotspot.