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

The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

dakkak.dev

Post reply on HN
Print view View original

11–19 of 19 posts

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#11

Post by pizlonator »

carry_bit wrote: post #8
pizlonator wrote: post #2

Super cool to see a description of how Wolfram is compiled. I've used the Wolfram language for a long time but never really took a peak inside. Some thoughts: - The paper seems to suggest that compilation of scripting languages is not widely used outside academia. In fact, it's super common - all major browsers do it for JavaScript. - What they call "soft failure mode" is what I would call "OSR exit" or what others w…

I wouldn't really classify "soft failure mode" as OSR; from my experimentation it reinvokes the entire function when there's a failure rather than migrating over the execution state. In terms of tests, I get the impression that this compiler doesn't (yet) have to deal with much of the complexity a modern JavaScript one has to (OSR, GC info, inline caches, probably even most ISA-level details), so there are whole clas…

Interesting that it just reinvokes the whole function. I always thought that Wolfram does have some effects - like, you can print things. You can’t rerun the whole function if you have done any effects. But maybe I’m wrong about the effectfulness of the language.

Wolfram may not have inline caches or GC but it has lots of super interesting things that JS doesn’t have. Must be a fun system to work on!

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#12

Post by daneelsan »

pizlonator wrote: post #11
carry_bit wrote: post #8

Earlier quoted context omitted.

I wouldn't really classify "soft failure mode" as OSR; from my experimentation it reinvokes the entire function when there's a failure rather than migrating over the execution state. In terms of tests, I get the impression that this compiler doesn't (yet) have to deal with much of the complexity a modern JavaScript one has to (OSR, GC info, inline caches, probably even most ISA-level details), so there are whole clas…

Interesting that it just reinvokes the whole function. I always thought that Wolfram does have some effects - like, you can print things. You can’t rerun the whole function if you have done any effects. But maybe I’m wrong about the effectfulness of the language. Wolfram may not have inline caches or GC but it has lots of super interesting things that JS doesn’t have. Must be a fun system to work on!

It has GC, e.g. DataStructures (https://reference.wolfram.com/language/guide/DataStructures....) are GC'd. IIRC it uses refcounting for this.

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#13

Post by carry_bit »

daneelsan wrote: post #12
pizlonator wrote: post #11

Earlier quoted context omitted.

Interesting that it just reinvokes the whole function. I always thought that Wolfram does have some effects - like, you can print things. You can’t rerun the whole function if you have done any effects. But maybe I’m wrong about the effectfulness of the language. Wolfram may not have inline caches or GC but it has lots of super interesting things that JS doesn’t have. Must be a fun system to work on!

It has GC, e.g. DataStructures ( https://reference.wolfram.com/language/guide/DataStructures.... ) are GC'd. IIRC it uses refcounting for this.

By GC info in my post I mean tracking which registers and stack slots at each safepoint contain object references so the tracing GC can precisely identify all of the GC roots.

Since Wolfram Language uses referencing counting instead, it doesn't need all of that complexity; it just has to insert MemoryAcquire/MemoryRelease at the appropriate spots in the IR.

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#14

Post by carry_bit »

pizlonator wrote: post #11
carry_bit wrote: post #8

Earlier quoted context omitted.

I wouldn't really classify "soft failure mode" as OSR; from my experimentation it reinvokes the entire function when there's a failure rather than migrating over the execution state. In terms of tests, I get the impression that this compiler doesn't (yet) have to deal with much of the complexity a modern JavaScript one has to (OSR, GC info, inline caches, probably even most ISA-level details), so there are whole clas…

Interesting that it just reinvokes the whole function. I always thought that Wolfram does have some effects - like, you can print things. You can’t rerun the whole function if you have done any effects. But maybe I’m wrong about the effectfulness of the language. Wolfram may not have inline caches or GC but it has lots of super interesting things that JS doesn’t have. Must be a fun system to work on!

The effects are how I tested this out; I used FunctionCompile on a function that uses first uses KernelFunction to call a user-defined function that increments a counter, and then calls Sqrt on the function's argument.

When you give it a non-negative argument, the counter increases by one; when you give it a negative argument you get the message of it reverting to the uncompiled evaluation and the counter increases by two.

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#15

Post by daneelsan »

carry_bit wrote: post #13
daneelsan wrote: post #12

Earlier quoted context omitted.

It has GC, e.g. DataStructures ( https://reference.wolfram.com/language/guide/DataStructures.... ) are GC'd. IIRC it uses refcounting for this.

By GC info in my post I mean tracking which registers and stack slots at each safepoint contain object references so the tracing GC can precisely identify all of the GC roots. Since Wolfram Language uses referencing counting instead, it doesn't need all of that complexity; it just has to insert MemoryAcquire/MemoryRelease at the appropriate spots in the IR.

I see what you mean, simpler indeed!

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#16

Post by daneelsan »

carry_bit wrote: post #14
pizlonator wrote: post #11

Earlier quoted context omitted.

Interesting that it just reinvokes the whole function. I always thought that Wolfram does have some effects - like, you can print things. You can’t rerun the whole function if you have done any effects. But maybe I’m wrong about the effectfulness of the language. Wolfram may not have inline caches or GC but it has lots of super interesting things that JS doesn’t have. Must be a fun system to work on!

The effects are how I tested this out; I used FunctionCompile on a function that uses first uses KernelFunction to call a user-defined function that increments a counter, and then calls Sqrt on the function's argument. When you give it a non-negative argument, the counter increases by one; when you give it a negative argument you get the message of it reverting to the uncompiled evaluation and the counter increases b…

Interesting...

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#17

Post by pizlonator »

carry_bit wrote: post #13
daneelsan wrote: post #12

Earlier quoted context omitted.

It has GC, e.g. DataStructures ( https://reference.wolfram.com/language/guide/DataStructures.... ) are GC'd. IIRC it uses refcounting for this.

By GC info in my post I mean tracking which registers and stack slots at each safepoint contain object references so the tracing GC can precisely identify all of the GC roots. Since Wolfram Language uses referencing counting instead, it doesn't need all of that complexity; it just has to insert MemoryAcquire/MemoryRelease at the appropriate spots in the IR.

You don’t need to track registers and stack slots to do GC. JSC doesn’t.

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#18

Post by dwohnitmok »

carry_bit wrote: post #14
pizlonator wrote: post #11

Earlier quoted context omitted.

Interesting that it just reinvokes the whole function. I always thought that Wolfram does have some effects - like, you can print things. You can’t rerun the whole function if you have done any effects. But maybe I’m wrong about the effectfulness of the language. Wolfram may not have inline caches or GC but it has lots of super interesting things that JS doesn’t have. Must be a fun system to work on!

The effects are how I tested this out; I used FunctionCompile on a function that uses first uses KernelFunction to call a user-defined function that increments a counter, and then calls Sqrt on the function's argument. When you give it a non-negative argument, the counter increases by one; when you give it a negative argument you get the message of it reverting to the uncompiled evaluation and the counter increases b…

Isn't this a potential for a lot of crazy bugs then?

I've never used Wolfram in earnest (touched it once in undergrad ever so briefly) so I may be misunderstanding.

EDIT: I see that the documentation for FunctionCompile indicates it's for pure functions only.https://reference.wolfram.com/language/ref/FunctionCompile.h...

Re: The Design and Implementation of the Wolfram Language Compiler (2020) [pdf]

#19

Post by carry_bit »

dwohnitmok wrote: post #18
carry_bit wrote: post #14

Earlier quoted context omitted.

The effects are how I tested this out; I used FunctionCompile on a function that uses first uses KernelFunction to call a user-defined function that increments a counter, and then calls Sqrt on the function's argument. When you give it a non-negative argument, the counter increases by one; when you give it a negative argument you get the message of it reverting to the uncompiled evaluation and the counter increases b…

Isn't this a potential for a lot of crazy bugs then? I've never used Wolfram in earnest (touched it once in undergrad ever so briefly) so I may be misunderstanding. EDIT: I see that the documentation for FunctionCompile indicates it's for pure functions only. https://reference.wolfram.com/language/ref/FunctionCompile.h...

In Wolfram Language, a "pure function" is what others would call an "anonymous function" or a "lambda". It doesn't actually imply the lack of side-effects.

The older Compile function also does the same thing when there's an error.

Given the difficulties of doing something fancier, I think it's a reasonable strategy. Mutating state that doesn't originate in a function isn't too common, and less so with the kinds of functions you'd compile. If the compiled function fails, you probably have some other bug in your code anyways.

Post reply on HN