Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

Post reply on HN
Print view View original

161–170 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#161

Post by grashalm »

qwertyuiop924 wrote: post #157
Veedrac wrote: post #151

Earlier quoted context omitted.

You can do TCO relatively simply. You throw a special exception class for nonlocal control flow (eg. tail calls, breaks from loops, continues, etc.) and Graal knows how to optimize the cost away to a normal jump. http://cesquivias.github.io/blog/2015/01/15/writing-a-langua... ZipPy (an incomplete Python implementation) supports Python's coroutines, which are faster than any other implementation. In theory these might…

The TCO sounds like an ugly hack to me, but I'll take it. How would this interact with the magical AST merging? I would assume that languages with different calling conventions can't just merge like that.

If you do it in a language specific way, you would probably need to catch those TC exceptions when calling into functions of your language. That is very easy to do, as every Truffle language controls how its functions get called in a foreign languages.

Re: Graal and Truffle could accelerate programming language design

#162

Post by grashalm »

cpeterso wrote: post #150

Here is a video of a Graal/Truffle talk given by a researcher at Oracle (presented at Mozilla in 2013): https://air.mozilla.org/one-vm-to-rule-them-all/

This is quite outdated. here is an overview of Graal/Truffle papers and tutorials: https://wiki.openjdk.java.net/display/Graal/Publications+and...

Re: Graal and Truffle could accelerate programming language design

#163

Post by Veedrac »

qwertyuiop924 wrote: post #157
Veedrac wrote: post #151

Earlier quoted context omitted.

You can do TCO relatively simply. You throw a special exception class for nonlocal control flow (eg. tail calls, breaks from loops, continues, etc.) and Graal knows how to optimize the cost away to a normal jump. http://cesquivias.github.io/blog/2015/01/15/writing-a-langua... ZipPy (an incomplete Python implementation) supports Python's coroutines, which are faster than any other implementation. In theory these might…

The TCO sounds like an ugly hack to me, but I'll take it. How would this interact with the magical AST merging? I would assume that languages with different calling conventions can't just merge like that.

Imagine you have an AST. You execute it directly, by running a node. This node will run its sub-nodes, etc. The implemented language has its own stack frames stored in specific objects. Thus the stack is actually split between those variables in the Java call stack and those in the explicit object.

Let's say you're in a particular function at a tail call node. Since the tail call node is semantically (from the point of view of the Java program) many function calls deep into the implemented language's function and we want to get back to the start, we want some way of exiting a whole stack of function calls in one jump.

Exceptions offer a simple and neat way to do this. You throw from the call site and catch back at the start of the function. Graal will inline all of the internal function calls up to this point, since Graal uses inlining extremely heavily. This means that Graal will see the throw site and the call site next to each other in one block of code, and consider it to just be a jump.

Because Graal is just inlining Java functions, and the actual target language's call stack is stored separately as a particular object, the target language's calling convention for a large part doesn't matter. The jump to the first node doesn't invalidate any of the target language's stack - that has to be done by the language implementor manually at that point.

Re: Graal and Truffle could accelerate programming language design

#165

Post by qwertyuiop924 »

grashalm wrote: post #161
qwertyuiop924 wrote: post #157

Earlier quoted context omitted.

The TCO sounds like an ugly hack to me, but I'll take it. How would this interact with the magical AST merging? I would assume that languages with different calling conventions can't just merge like that.

If you do it in a language specific way, you would probably need to catch those TC exceptions when calling into functions of your language. That is very easy to do, as every Truffle language controls how its functions get called in a foreign languages.

Ah.

Re: Graal and Truffle could accelerate programming language design

#166

Post by ilostmykeys »

grashalm wrote: post #130
trishume wrote: post #126

Earlier quoted context omitted.

I wondered why this didn't get merged with my submission. Makes a neat example of how random getting on the HN front page is though. Although I'm sad that randomness chose to give the second posting karma instead of mine.

What was your title? Without a good one, your post might have been just skipped by most.

like Digg before it, HN can be easily easily gamed

you have sizable groups of people who work like one team, one person submits and others up vote

In the Digg days I was approached by some guys in Eastern Europe who offered to get me diggs for $$. I declined. I was hoping HN is harder to game, but I don't see any evidence that support that.

Re: Graal and Truffle could accelerate programming language design

#167

Post by qwertyuiop924 »

qwertyuiop924 wrote: post #156
hencq wrote: post #152

Earlier quoted context omitted.

I'm definitely not an expert on this, but how the article describes it is you basically implement an AST with "execute" methods on its nodes. So that's just an interpreter that happens to use the Truffle framework to implement that AST. You can then implement continuations or TCO however you see fit. As I understand it, Graal is able to 'magically' turn that into a JIT. Again, I'm not an expert (I just read the artic…

But if the calling and stack semantics are different from Java's (and the kind of have to be), than you can't just merge the ASTs. Ruby, provided you don't implement callcc, is almost, if not entirely identical in calling convention to C. So if truffle supports magical AST merging, as described, I don't think you can implement anything with a different set of conventions to C/Java.

Wait, nevermind. See above.

Re: Graal and Truffle could accelerate programming language design

#168

Post by nickpsecurity »

euyyn wrote: post #143
outworlder wrote: post #61

Earlier quoted context omitted.

> COBOL was a huge improvement at the time, an innovation in readability. BASIC is a good demonstration of why the platonic ideal language is wrong: it was designed for beginners (that's what the acronym stands for), and it did a reasonably good job at that. Sure. But these systems were created from the ground up, every single time. Given a good foundation, which could be Lisp or something even better, you can whip u…

Lisp didn't miss the train because it was too good or because people were idiots. For a good foundation to be good it has to meet the pre-requisite to work for most use cases. Lisp didn't when C did, in a time when hardware was small and expensive. Times have changed now? Sure, but history didn't wait.

That's a significant part of it. Check out PreScheme, though, for how that might have worked:

https://en.wikipedia.org/wiki/PreScheme

It's a Scheme created as a C alternative for low-level programming used in a verified Scheme48, VLISP. It was quite efficient. LISP's doing more of that kind of thing might have fueled more use of the language.

Re: Graal and Truffle could accelerate programming language design

#169

Post by pjmlp »

bitmapbrother wrote: post #145
pjmlp wrote: post #142

Earlier quoted context omitted.

Or maybe because no one capable of writing such applications wants to target 1% market share? Sometimes being good at something isn't enough.

I wonder if BB users also use that excuse.

I didn't use it as an excuse.

I am no real time audio expert, but as someone that does work on Windows, I saw the information I have posted back when it went live.

So it is possible, that in spite of the support being there, no one cares about it due to the sad state of the Windows Phone market and not because they suck.

Or I suck at understanding how real time audio is supposed to work and the support isn't really there in spite of what Microsoft says.

Re: Graal and Truffle could accelerate programming language design

#170

Post by kentonv »

nostrademons wrote: post #90
thomaswue wrote: post #86

Earlier quoted context omitted.

It works without common memory layout between Truffle languages. It even simplifies the ability to use diverse physical memory layouts within the same language. The programmer specifies the logical layout based on the semantics of a language. The runtime decides how to map this logical layout onto the physical hardware. It can take into account the trade-offs the programmer decided to choose.

Right, and my point is that the reason people continue to use C++ or Rust over JVM languages is because there are some use-cases where the JVM's decision about how to map the logical layout onto physical memory causes unacceptably high memory usage and/or cache misses, or prevents them from taking advantage of clever serialization formats (Cap'n Proto, for example, loses much of its performance benefits on the JVM wi…

> Cap'n Proto, for example, loses much of its performance benefits on the JVM without the use of sun.misc.unsafe

Not actually true. `ByteBuffer` lets you read integers from arbitrary offsets, which is all Cap'n Proto really wants.

Post reply on HN