Add a page about a JIT/Optimization library idea.

[sunfishcode]

Following up on the suggestion in #264, here is my PR proposing my idea for a JIT and optimization library, which while not being part of the spec, would be important in allowing us to keep the WebAssembly spec itself simple, general-purpose, and providing primitive operations.

[jfbastien]

"Just-in-Time compilation" for the first mention.

[jfbastien]

I agree with the general direction (wordsmithing separate), but I think the title isn't quite accurate, and this section should be much higher in this document, if not in another document or even self-standing. Referring to the extensible web manifesto is what I've defaulted to so far, and you somewhat echo it (add a callout!) while giving concrete examples (great, I'd keep them in).

I think @titzer may disagree with the math functions though. In #264 I tried to clarify what he thought was important while making sure it reflected the entire discussion we'd had. I think #264 is a good increment (capture more background), whereas this PR will need a bit of discussion we're all on board: it's a pretty fundamental principle and I'd like to get a few more people agreeing first.

[titzer]

I'm conflicted on this PR. On the one hand, defining a new higher-level
layer with looser semantics than WebAssembly can free the lower layer from
having to service conflicting goals. On the other hand, it's an pretty
overt admission that WebAssembly isn't serving an important use case well.
In the case of the latter, maybe we can do some use-case enumeration and
exploration as to why wasm as-is doesn't serve this need.

Not that I disagree that a JIT library is a bad goal; I think it's
something that will be eminently useful to many developers and programs.
The question is how far it will need to diverge from wasm to be that useful
artifact. If the answer is "too far", then that points in the direction
that we need to make "raw wasm" better.

On Fri, Jul 17, 2015 at 7:13 PM, JF Bastien notifications@github.com
wrote:

I agree with the general direction (wordsmithing separate), but I think
the title isn't quite accurate, and this section should be much higher in
this document, if not in another document or even self-standing. Referring
to the extensible web manifesto is what I've defaulted to so far, and you
somewhat echo it (add a callout!) while giving concrete examples (great,
I'd keep them in).

I think @titzer https://github.com/titzer may disagree with the math
functions though. In #264 #264
I tried to clarify what he thought was important while making sure it
reflected the entire discussion we'd had. I think #264
#264 is a good increment
(capture more background), whereas this PR will need a bit of discussion
we're all on board: it's a pretty fundamental principle and I'd like to get
a few more people agreeing first.

—
Reply to this email directly or view it on GitHub
#265 (comment).

[titzer]

As for optimizations, the specific kinds of information about operations that are useful to optimizers are:

1. intput/output types
2. intput/output ranges (feeds range analysis)
3. purity (feeds dead code elimination, constant folding, partial evaluation, and code motion)
4. algebraic identities (feeds strength reduction and partial evaluation)

In particular, most of the trigonometric functions under consideration have some important properties that optimizers will want to use.

If we're talking about a JIT library, then one important question is whether the JIT is generating raw wasm to feed to an unmodified wasm engine or an improved "custom" wasm, or whether it internally is working on a different representation of the code than the underlying engine. I think we want to avoid a design where we have two complex JITs in operation, one in the library, and one in the engine.

[sunfishcode]

I think "custom wasm extensions" is indeed one of the places this is going. It'd be similar to a polyfill; a library optimizes and then lowers extensions into standard wasm before delivering them to the underlying implementation. Popular extensions could even be promoted into standard wasm, if appropriate.

At the same time, C/C++ compilers do trigonometric optimizations before translation to wasm. I expect Java/C#/etc. will often do so too, since popular implementations optimize their own IL. So while I expect there is a need for a JIT/Optimization library, I don't think it necessarily indicates a deficiency in wasm itself.

[titzer]

Would you be OK moving the discussion of a JIT library into another document? The worry here is that FutureFeatures sounds somewhat official and we might want to avoid committing to something too early.

[sunfishcode]

Ok. It's also starting to grow big enough where putting it in its own document is a good idea anyway.

[sunfishcode]

@titzer This PR has now been updated to move the discussion of a JIT library into another document. Would you mind taking another look?

[sunfishcode]

@titzer: Ok. I've now updated the opening paragraph and the third paragraph along the lines you suggested. Would you mind taking another look? Thanks!

[titzer]

lgtm

On Thu, Aug 20, 2015 at 12:48 AM, Dan Gohman notifications@github.com
wrote:

@titzer https://github.com/titzer: Ok. I've now updated the opening
paragraph and the third paragraph along the lines you suggested. Would you
mind taking another look? Thanks!

—
Reply to this email directly or view it on GitHub
#265 (comment).

[sunfishcode]

Merging based on lgtm above and no other objections.