Live data from Hacker News

GraalVM: Run Programs Faster Anywhere

graalvm.org

181–190 of 218 posts

Re: GraalVM: Run Programs Faster Anywhere

#181
post #161

I wouldn't touch this with a ten-foot-pole without an explicit patent grant. Oracle has misbehaved too much in the past (and present) to ever be trusted again by the open source community in my opinion.

You know it's really motivating to read such comments after you've released years of work as open source...

Yes, indeed, but such comments are not without basis.

Re: GraalVM: Run Programs Faster Anywhere

#182
post #174

Earlier quoted context omitted.

OpenSSL and nokogiri already work pretty well. ActiveRecord works providing you have a database driver and I’ve got a rough set of patches for pg that I’m working on right now. I’m working on Discourse at the moment and can run the dB create and migrate tasks and I’m working on the asset compilation pipeline, but it’s all pretty rough and won’t be our final solution.

Just wondering if any Discourse or Rails Core people involved to get it working?

Not at the moment. I'm mostly doing some ugly hacks to get stuff working and generating a list of bugs for things we need to fix properly. Looking at my branch I think there's one small change that we will want to do PR for in the end, and some dependencies that we may want to make platform dependent (though they recently did change a couple for JRuby, which also helps us). Pretty much everything else I hope to back out when we've fixed a few of the root causes.

Re: GraalVM: Run Programs Faster Anywhere

#183
post #179

Earlier quoted context omitted.

I'm not on the Graal team but I can take a crack at an answer - it's because as languages get more dynamic, static ahead of time compilation becomes less and less effective and can even be counterproductive. To compile a Ruby program it really needs to be just-in-time compiled, or at least a partial ahead of time compile using injected profiling runs. The problem is that the semantics of Ruby are such that you can't…

That's partly true, but depends on the particular program. There are Ruby programs that could be compiled ahead-of-time quite efficiently, despite their dynamic features. The slow-path version of the code that violates runtime assumptions can still be compiled as an alternative variant - so instead of switching from fast compiled code to the interpreter, the code violating the assumptions can switch to slow-path comp…

While that's true, and switching to a slower path solves many problems, consider this common Ruby pattern:

    Dir.glob("some dir/*").each do |filename|
        require filename
    end
A lot of Ruby code messes with how code is loaded (heck, "require" in almost every Ruby install is not the built in "require" but one that has been dynamically replaced). Sometimes that is intended to implement static behavior: The expectation is that the code remains the same. It's just a way of avoiding having to maintain a list manually.

But other times it is used as a plugin mechanism, where the expectation is for the code to be provided by a user or other developer, and processing this statically at compile time would remove capabilities that the user would expect.

You can't automatically determine things like that, because it is down to developer intent and the code does not document the intent.

So the problem goes deeper than being about being able to revert to a slow path: To compile Ruby in a meaningful way you need to make some level of trade-off in what aspects of Ruby you decide to treat as "ahead of time" vs runtime, because there is no clear rule that says "now the program has been loaded; everything after this is runtime".

Re: GraalVM: Run Programs Faster Anywhere

#184
post #180

Going to try it out, but does anyone know offhand whether GraalVM can be ran within the Linux subsystem in Windows 10?

why would you want that... it should run directly on Windows too?!? Not sure what you gain from using the linux binary from LXSS. If you really insist, invoke instead as .exe so you can still use bash and other tools, but run the actual compile or runtime using the system-native implementation.

Can you show me any Windows build instructions or anything that indicates Windows support?

Re: GraalVM: Run Programs Faster Anywhere

#185
post #21

Might this (today, tomorrow) become another way to get access to the wonderful Lucene from non-Java environments? A long, long time ago there was a GCJ-based solution, but it was never loved much (either the port or GCJ itself). SubstrateVM looks potentially delicious here edit: lol: talk about a low blow! > The community version does not support DWARF information. The enterprise version supports all native tools tha…

Where's that quote from about DWARF? Pay for a backtrace, pah!

Re: GraalVM: Run Programs Faster Anywhere

#186
post #129

Earlier quoted context omitted.

I think it’s a legitimate licensing concern. I’m surprised you called it FUD, given the high-profile case against Android (google). I was about to recommend we try it at my company and gave up as soon as I read “Oracle” in the company name. Call it FUD if you want but Oracle does have a damaged reputation.

It happens when companies don't behave as they should, and others lack the money to enforce how things should be. "James Gosling: Oracle vs Google" https://www.youtube.com/watch?v=JQ7xVO9lqD0

I don't understand the point of the clip. He says that the code was similar to Sun's, but clearly admits that, not being involved with the trial, he didn't get to see Google's code.

Re: GraalVM: Run Programs Faster Anywhere

#187

> With the SubstrateVM it is possible to produce a single, statically linked native binary executable version of Graal.js, which doesn't need any JVM to run. How large is the resulting executable? There was some mention of shares libraries — is it possible to build a runtime that is callable from C? Relatedly, does the GraalVM java executable support JNI? I’m also curious about the runtime footprint in general; any i…

> How large is the resulting executable? A minimal executable is about 5 MB. > There was some mention of shares libraries — is it possible to build a runtime that is callable from C? Yes you can compile a JAR to a shared library with C function entry points. > Relatedly, does the GraalVM java executable support JNI? Yes. > I’m also curious about the runtime footprint in general; any idea what is the smallest possible…

>> I’m also curious about the runtime footprint in general; any idea what is the smallest possible VM for a real but relatively-small language like Lua?

> Real language VMs are quite a bit bigger - a hundred MB or so.

Don't know if you're trying to say Lua is not a real language, or just skipped the part about Lua.

Re: GraalVM: Run Programs Faster Anywhere

#188

Earlier quoted context omitted.

It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application. It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.

Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program? Will this be the case for truffle python, js,etc ?

> Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program?

I would think that the fact that Ruby constructs that look like what would be compiler directives in a more static language (e.g., Ruby's “require” vs C’s “#include”) have their semantics defined in a way which both depends on and affects runtime state means that AOT compiling Ruby in the strict sense gets you very little, whereas running it to a certain point AOT and saving the runtime state gets you closer to what you'd expect from compiling based on usually-compiled languages.

Re: GraalVM: Run Programs Faster Anywhere

#189

there is any roadmap to make available for MacOS?

GraalVM EE has a MacOS version that is free for evaluation uses. http://www.graalvm.org/downloads/ There are technical reasons we cannot have a CE for Mac OS as well. But we are working on that.

https://github.com/oracle/truffleruby/releases/tag/vm-1.0.0-... this will contain EE or CE version?

Re: GraalVM: Run Programs Faster Anywhere

#190

Earlier quoted context omitted.

This was the first thought that crossed my mind. If I have a choice between running our stack 50 times slower (and thereby 50 times the cost) or running anything Oracle, I know which choice is cheaper and doesn't come with an existential threat to my company. Only governments and big corp are rich and reckless enough to take on this kind of risk willingly.

>> existential threat to my company There is like a bajillion people out there running Oracle Java, MySql, Virtualbox and so on. All of them Oracle products, and with permissive licenses. Where is this "existential treat" thing coming from?

> There is like a bajillion people out there running Oracle Java, MySql, Virtualbox and so on. All of them Oracle products, and with permissive licenses.

All of those examples have dual commercial/copyleft licenses, none of them have permissive licenses. Moreover, the Free licenses are without explicit patent grants which may, therefore, be at risk of patent claims.

Post reply on HN