← Back to context

Comment by gavinray

4 years ago

Are the authors of this paper present/the ones who posted?

This is really interesting. One thing I'm curious about -- is this technique applicable to applications which do JIT "compilation" in the business-logic/abstract sense of the term?

Realworld usecase: Hasura is fundamentally a Haskell GraphQL-to-SQL JIT compiler/transpiler. It parses, lowers to an internal IR format, and then translates to a specific SQL dialect.

I'm wondering if any of this would carry over to a usecase like that?

  https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/RQL/IR/Select.hs
  https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/Translate/Select.hs

Nonetheless, will be interesting to see whether this technique will get adopted by LLVM or some of the major WASM runtimes. I won't pretend to understand the majority of what the writeup stated, but on paper it seems a huge speedup?

I am the author.

> which do JIT "compilation" in the business-logic/abstract sense of the term?

If I understood what you said correctly, you mean translating something to SQL?

The problem this paper is trying to solve is how we can generate binary code fast. If your target (i.e. the stuff you want to generate in the end) is not binary code, but some high level representation like a SQL text, then I think it doesn't have much to do with the technique in our paper.

  • Got it -- yeah this is the key bit I was wondering about:

      > generate *binary* code fast
    

    Still really interesting though, thanks for sharing =)

    Surprised there aren't more comments/votes.