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

Skeleton WebAssembly target

reviews.llvm.org

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Skeleton WebAssembly target

#51

Post by vmorgulis »

ZenoArrow wrote: post #49
TazeTSchnitzel wrote: post #48

Earlier quoted context omitted.

> From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks. At least initially it'll be similar to asm.js, yes. > You can do AOT compilation of JS too. No, you can't. You don't have all the type information needed.

> "No, you can't. You don't have all the type information needed." https://github.com/toshok/echojs

"I want to play around with what is essentially profile guided optimization, but with runtime type information. So you get a partially specialized (at least as much as the static compilation can give you) implementation, which then records type information at runtime."

Very advanced optimizations. Emscripten doesn't do that (not yet, but LLVM has PGO).

Re: Skeleton WebAssembly target

#52

Post by serve_yay »

andybak wrote: post #10

If webassembly is essentially asm.js directly converted to a more compact bytecode format but with the same semantics - and emscripten already provides llvm with a backend that outputs asm.js, then what's significant about this? I had assumed from the original webassembly announcement that this would be a fairly trivial step but I expect I've misunderstood something.

From what I have heard, with asm.js, the parser becomes the hotspot. And WebAssembly is a compressed representation of the AST. (Please note that everything I've written could be completely incorrect)

Re: Skeleton WebAssembly target

#53

Post by vmorgulis »

azakai wrote: post #28
bobajeff wrote: post #22

Earlier quoted context omitted.

Emscripten doesn't provide LLVM with a backend it uses a fork of LLVM called Fastcomp and that has a asm.js backend. Also the current backend isn't integrated with LLVM the way normal ISA backends are. This I believe (can't access page either) will be upstream and integrated with LLVM proper. Providing performance advantages as well as allowing frontends that aren't supported in Fastcomp but are based off upstream LL…

All of those advantages are true, except for performance. We actually don't know which approach will be faster to compile, nor which approach will emit faster code. There are reasons to guess either way. The new backend being begun here is something of an experiment, as LLVM shared backend infrastructure was just not designed for this kind of thing (emitting a high-level AST IR without physical registers, etc.). Ther…

Will you continue with C++ (especially for tools outside LLVM)?

Do you plan to use something else (like Rust)?

Re: Skeleton WebAssembly target

#55

Post by azakai »

vmorgulis wrote: post #53
azakai wrote: post #28

Earlier quoted context omitted.

All of those advantages are true, except for performance. We actually don't know which approach will be faster to compile, nor which approach will emit faster code. There are reasons to guess either way. The new backend being begun here is something of an experiment, as LLVM shared backend infrastructure was just not designed for this kind of thing (emitting a high-level AST IR without physical registers, etc.). Ther…

Will you continue with C++ (especially for tools outside LLVM)? Do you plan to use something else (like Rust)?

We use a mix of C++, JS and Python outside of LLVM. No plans to change that, but it could, depends on which tools contributors prefer.

vdohaeris, btw ;)

Re: Skeleton WebAssembly target

#56

Post by vmorgulis »

azakai wrote: post #55
vmorgulis wrote: post #53

Earlier quoted context omitted.

Will you continue with C++ (especially for tools outside LLVM)? Do you plan to use something else (like Rust)?

We use a mix of C++, JS and Python outside of LLVM. No plans to change that, but it could, depends on which tools contributors prefer. vdohaeris, btw ;)

> vdohaeris, btw ;)

:-)

Re: Skeleton WebAssembly target

#57

Post by TazeTSchnitzel »

kayamon wrote: post #47
TazeTSchnitzel wrote: post #36

Earlier quoted context omitted.

It doesn't yet exist. The specifications haven't been written, these are high-level design documents.

Based on the spec so far, there's a very good chance it'll look _almost exactly like asm.js_

Yes. Like asm.js it will more closely resemble C than assembly language, having expressions and variables.

Re: Skeleton WebAssembly target

#58

Post by TazeTSchnitzel »

ZenoArrow wrote: post #49
TazeTSchnitzel wrote: post #48

Earlier quoted context omitted.

> From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks. At least initially it'll be similar to asm.js, yes. > You can do AOT compilation of JS too. No, you can't. You don't have all the type information needed.

> "No, you can't. You don't have all the type information needed." https://github.com/toshok/echojs

I've done something similar for PHP before. But what you get is code that essentially embeds a dynamic language runtime into your code in the places where the types aren't known. It's less efficient than JIT compilation.

Re: Skeleton WebAssembly target

#59

Post by vmorgulis »

TazeTSchnitzel wrote: post #58
ZenoArrow wrote: post #49

Earlier quoted context omitted.

> "No, you can't. You don't have all the type information needed." https://github.com/toshok/echojs

I've done something similar for PHP before. But what you get is code that essentially embeds a dynamic language runtime into your code in the places where the types aren't known. It's less efficient than JIT compilation.

Did you include a feedback mecanism in your solution ? (like PGO)

Re: Skeleton WebAssembly target

#60

Post by StefanKarpinski »

jashkenas wrote: post #14
StefanKarpinski wrote: post #11

Earlier quoted context omitted.

My understanding is that it will only initially mirror asm.js but will eventually become a full-blown, independent bytecode IR that departs from JavaScript semantics (while continuing to support expressing them), allowing other languages to be compiled down to WebAssembly and run in the browser efficiently. Having a bytecode format also eases the considerable burden of parsing JavaScript – which is especially problem…

Got some Julia plans or hopes?

Sure – with a first-class LLVM backend for WebAssembly, we could absolutely compile to it, which would mean running fully in the browser, which is something Emscripten can't quite manage at this point. That would certainly be very cool (and useful too). See https://github.com/JuliaLang/julia/issues/9430.
Post reply on HN