4 ms·
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, assumi
by 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 agoThere'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 agoI 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)