Earlier quoted context omitted.
And the formula given has at least two bugs, I think. They give it as -b + (Math.sqrt(b**2 - 4*a*c)) / 2*a Shouldn't it be (-b + (Math.sqrt(b**2 - 4*a*c))) / (2*a) (still ignoring the other root, of course).
Even wierder, the tree in their presentation seems to represent: -b + (Math.sqrt(b**2 - 4*a*c)) / (2*a) Which is neither the formula we'd expect nor the formula they show.
One VM to Rule Them All [pdf]
21–30 of 90 posts
Re: One VM to Rule Them All [pdf]
#22This looks interesting, but I am generally worried about something being owned by Oracle. Simple example; I own an Openpandora. I wrote a live coding environment in Java with a very basic, lispy language at it's core. Using any free Java implementation it either; did not start (core dump; suspect; not enough memory to get even the VM up) or ran very (unusable) slow. With the Java 7 closed source ARM version from Orac…
Re: One VM to Rule Them All [pdf]
#23The "Substrate VM Execution Model" slide talks about Ahead Of Time Compilation, which makes it sound like it might actually be the LLVM-based Substrate VM: http://vmkit.llvm.org. Alternatively, could it be a version of Maxine?
AOT as an option certainly sounds interesting...
Re: One VM to Rule Them All [pdf]
#24Caveat: I've not used HLVM or looked at its implementation, but the scope seems very similar.
Re: One VM to Rule Them All [pdf]
#25Earlier quoted context omitted.
Even wierder, the tree in their presentation seems to represent: -b + (Math.sqrt(b**2 - 4*a*c)) / (2*a) Which is neither the formula we'd expect nor the formula they show.
Apologies for my maths - I think I simplified the serialised expression to reduce space on the slide or something like that, and broke it in the process.
And how your approch fares compared to the state of art JIT implementations? Can your solution produce a faster Lua than LuaJIT, for example? Why starting with Ruby for which you implement 40%? And what have you used from JRuby?
Re: One VM to Rule Them All [pdf]
#26It would be interested how it compares to OpenResty (LuaJIT), Node.js (V8 JS engine) & co.
Re: One VM to Rule Them All [pdf]
#27Earlier quoted context omitted.
Apologies for my maths - I think I simplified the serialised expression to reduce space on the slide or something like that, and broke it in the process.
I understand you're an insider, so can you please explain what is the actual breakthrough compared to the previous attempts to make a faster Ruby? And how your approch fares compared to the state of art JIT implementations? Can your solution produce a faster Lua than LuaJIT, for example? Why starting with Ruby for which you implement 40%? And what have you used from JRuby?
The advantage of running on the Substrate VM is that, unlike JRuby, our startup time is about the same as MRI (slide 19).
There are several languages using this system, both by us (JS, Ruby) by academic partners (Python, R) and others (Smalltalk is one I know of). This talk just used Ruby as an example.
We used the parser from JRuby.
Re: One VM to Rule Them All [pdf]
#28Re: One VM to Rule Them All [pdf]
#29So what is the Substrate VM? The main presentation appears to be about Truffle, a language-implementation framework, which looks neat by itself. The "Substrate VM Execution Model" slide talks about Ahead Of Time Compilation, which makes it sound like it might actually be the LLVM-based Substrate VM: http://vmkit.llvm.org . Alternatively, could it be a version of Maxine? AOT as an option certainly sounds interesting..…
Oracle is planning eventually to replace the C++ based JIT with Graal in some version following 8.
Re: One VM to Rule Them All [pdf]
#30Earlier quoted context omitted.
I understand you're an insider, so can you please explain what is the actual breakthrough compared to the previous attempts to make a faster Ruby? And how your approch fares compared to the state of art JIT implementations? Can your solution produce a faster Lua than LuaJIT, for example? Why starting with Ruby for which you implement 40%? And what have you used from JRuby?
There are several techniques working together here. The Truffle system allows the running program to gradually become statically typed over time (slide 9), where as JRuby has to go through a generic IRubyObject type for almost everything. Also, where JRuby has to continually check that methods have not been redefined, we never check and instead we go in and stop the running machine code when a method is redefined (sl…