4 ms·

I played with it a few weeks ago, mostly interested in Python and the article I read and the Graal home page didn't make it clear that the Python support is not

I played with it a few weeks ago, mostly interested in Python and the article I read and the Graal home page didn't make it clear that the Python support is not even close. I tried a "print 'hello world'", and that didn't work at all. sys.stdout.write did work. I then did a simple test of startup time and Python was an order of magnitude faster than Graal. The Graal Python prints a warning when you start it that it is a very early state. So I tried Ruby, and I was able to do a simple print, and the startup time for Graal vs Ruby was about the same. Looks like Java is the real target right now. A very interesting project, looking forward to seeing where it goes.

pron 9y ago
Re the startup time: native images are intended to reduce startup time of Java code, as they AOT compile Java. Other languages are not, AFAIK, AOT-compiled, and so reducing startup time is not a goal -- overall performance is.
- chrisseaton 9y ago
  We get this confusion every time we talk about native compilation. GraalVM can do ahead-of-time compilation of Java code. That Java code could be an interpreter for JavaScript, written in Java. But GraalVM cannot do ahead-of-time compilation of JavaScript. We struggle to always make this clear. And it's actually more complicated than that: Of course GraalVM can compile JavaScript to native code, it just only does it at runtime, as a JIT. GraalVM can run JavaScript during ahead-of-time compilation, so you can run your JavaScript program so far, and then compile it at that point with all its state compiled into the image. We use this to do things like pre-initialise libraries ahead-of-time so when you start to run everything is set up and ready to go. Finally, the mathematical trick we use to compile JavaScript to native code at runtime, which is called partial evaluation, or more formally, the First Futamura Projection, has a theoretical more advanced variant called the Second Futamura Projection, which could be implemented in GraalVM to, indeed, compile JavaScript ahead-of-time to native code. But implementing this practically is an open problem and not really our goal.
  - yunglono 9y ago
    How do you people get this much knowledge about programming and maths?
  - quelltext 9y ago
    I wish people stopped using niche terms as a) if they were common knowledge, and b) as if they were crucial to the discussion at hand. It's much more intuitive to explain what's going on and then say that what is described is also known as ___. The Futamura Projections can be explained in about three lines and is not at all a complex concept to wrap your head around. Casually inserting these terms in a forum where most people likely haven't had much exposure to partial evaluation terminology makes it sound like you want to either forcefully polularize these terms or make yourself sound more important. ...not saying you intended either.
    - gliboc 9y ago
      I think you are wrong about this. Contrary to a normal conversation, specific vocabulary used on the internet can be instantly looked up. This allows for diving more into the topics if they interest you.
igouy 9y ago
> So I tried Ruby fwiw https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/yarv-truffle.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- chrisseaton 9y ago
  Thanks for adding those to the Benchmarks Game - I think it was you? If you are interested in very short running programs, then these benchmarks can be interesting to look at. If you are more interested in long running programs, like web servers, then I don't think you'll find many professional virtual machine implementors who will agree that this is a valid way to benchmark things. But we probably also have some optimisation bugs to work out still. There's even some errors in the logs of those.
  - igouy 9y ago
    > very short running Let's be clear that we're talking about minutes not milliseconds.
  - djur 9y ago
    I think Truffle has a pretty good showing there that matches your description -- quick scripts don't get much help but longer-running ones have some pretty incredible improvements.
    - igouy 9y ago
      > …quick scripts … longer-running ones… What's "quick" and "long running" in CPU secs on some machine? What language implementation are we using as a baseline when we say "quick" and "long running"? Otherwise someone might well say that 8 minutes with TruffleRuby is "long running" and CRuby 2.5 makes "some pretty incredible improvement" over that :-)
kjeetgill 9y ago
I've been playing with graalpython this last week too. The python implementation is in its early stages. I could get a "hello world" working with both their binary builds and from source but not much else. Also: Try "print('hello world')". It's targeting python3

pron 9y ago

Re the startup time: native images are intended to reduce startup time of Java code, as they AOT compile Java. Other languages are not, AFAIK, AOT-compiled, and so reducing startup time is not a goal -- overall performance is.

chrisseaton 9y ago
We get this confusion every time we talk about native compilation. GraalVM can do ahead-of-time compilation of Java code. That Java code could be an interpreter for JavaScript, written in Java. But GraalVM cannot do ahead-of-time compilation of JavaScript. We struggle to always make this clear. And it's actually more complicated than that: Of course GraalVM can compile JavaScript to native code, it just only does it at runtime, as a JIT. GraalVM can run JavaScript during ahead-of-time compilation, so you can run your JavaScript program so far, and then compile it at that point with all its state compiled into the image. We use this to do things like pre-initialise libraries ahead-of-time so when you start to run everything is set up and ready to go. Finally, the mathematical trick we use to compile JavaScript to native code at runtime, which is called partial evaluation, or more formally, the First Futamura Projection, has a theoretical more advanced variant called the Second Futamura Projection, which could be implemented in GraalVM to, indeed, compile JavaScript ahead-of-time to native code. But implementing this practically is an open problem and not really our goal.
- yunglono 9y ago
  How do you people get this much knowledge about programming and maths?
- quelltext 9y ago
  I wish people stopped using niche terms as a) if they were common knowledge, and b) as if they were crucial to the discussion at hand. It's much more intuitive to explain what's going on and then say that what is described is also known as ___. The Futamura Projections can be explained in about three lines and is not at all a complex concept to wrap your head around. Casually inserting these terms in a forum where most people likely haven't had much exposure to partial evaluation terminology makes it sound like you want to either forcefully polularize these terms or make yourself sound more important. ...not saying you intended either.
  - gliboc 9y ago
    I think you are wrong about this. Contrary to a normal conversation, specific vocabulary used on the internet can be instantly looked up. This allows for diving more into the topics if they interest you.

igouy 9y ago

> So I tried Ruby fwiw https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/yarv-truffle.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

chrisseaton 9y ago
Thanks for adding those to the Benchmarks Game - I think it was you? If you are interested in very short running programs, then these benchmarks can be interesting to look at. If you are more interested in long running programs, like web servers, then I don't think you'll find many professional virtual machine implementors who will agree that this is a valid way to benchmark things. But we probably also have some optimisation bugs to work out still. There's even some errors in the logs of those.
- igouy 9y ago
  > very short running Let's be clear that we're talking about minutes not milliseconds.
- djur 9y ago
  I think Truffle has a pretty good showing there that matches your description -- quick scripts don't get much help but longer-running ones have some pretty incredible improvements.
  - igouy 9y ago
    > …quick scripts … longer-running ones… What's "quick" and "long running" in CPU secs on some machine? What language implementation are we using as a baseline when we say "quick" and "long running"? Otherwise someone might well say that 8 minutes with TruffleRuby is "long running" and CRuby 2.5 makes "some pretty incredible improvement" over that :-)

kjeetgill 9y ago

I've been playing with graalpython this last week too. The python implementation is in its early stages. I could get a "hello world" working with both their binary builds and from source but not much else. Also: Try "print('hello world')". It's targeting python3