Live data from Hacker News

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

leaningtech.com

11–20 of 111 posts

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#11

This looks great! Please consider upstreaming this into LLVM; it would benefit many other users of LLVM. I'd love to see this used in Rust, for instance. What kind of compilation performance do you see for how long this pass takes? Do you apply this to all functions, or to all functions with certain properties, or to functions tagged some particular way?

I'd love if the is pass submitted upstream as well if possible. I think a lot of ecosystems could benefit from the awesome work you did!

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#12
post #9

This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167

> This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser.

Direct link to our latest demo in case anybody would like to see this tech in action: https://webvm.io

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#13

Is this something that could be exposed as a generic CLI tool to replace something like wasm-opt from Binaryen?

A subset of this could possibly be applied at the wasm-opt level, but consider that at the LLVM's IR level there is more information to be leveraged (in particular PartialExecuter uses information on what memory ranges are read-only).

In general the whole concept behind Cheerp (C++ to WebAssembly + JavaScript compiler) is doing as much as possible at the LLVM IR level, JavaScript concept included, since it's easier and more powerful to do code transformation there.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#15
post #4

Are the these new techniques only applicable to WebAssembly? If so, why?

WebAssembly implies static linking (malloc / printf & all are part of the shipped module) and code size matters since it directly influence users (since there might be delays in downloading big payloads). Both factors plays a role in deciding to plan putting work in optimizations like this.

There are some general gains to be had with this optimization, and probably the same ideas were already around for a while, but putting together in this way was helped by thinking about WebAssembly specific constraints.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#16
I love all these techniques where you can find static info about a program by 'running' it at compile time.

Normally you run a program at runtime (obviously) at which point you have the full environment and inputs, so you can run the program fully.

However... you can also kind of "run" a program at compile time. You can do this using some known and some unknown values in the source code, so you can "partially" run it.

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

Or you can use abstract/pretend values instead of real values, so you can "abstractly" interpret it.

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

Running at compile time lets you learn things about the program at compile time, allowing advanced optimisations and error checking.

You might realise that some code can never execute, so you can remove it (as in the project above). Or you can learn that some code is incorrect and give an error at compile time...

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#17
post #9

This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167

At what point does the browser become an "os", what's next? Chrome hypervisor?

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#18
post #10

Have you guys looked the literature of supercompilation? This seems to be a special case of it.

Hi, author of the post here, I am not familiar with this concept, do you have any pointers?

The idea is to evaluate the program at compile time and obtain a trace of the program that allows you to reconstruct a semantically equivalent program which has some desirable properties. In your case (and most cases in literature) it's done for optimization. Partial evaluation, which is a subset of supercompilation, is similar to what you are doing. See the wiki page: https://en.wikipedia.org/wiki/Partial_evaluation

Some literature:

https://dl.acm.org/doi/10.1145/5956.5957

https://ndmitchell.com/downloads/paper-rethinking_supercompi...

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#19

Have you guys looked the literature of supercompilation? This seems to be a special case of it.

All analytical solutions to optimization problems can be seen as special cases of the brute force search I guess. But SC is impractically slow for anything except a few instructions long sequences.

edit: actually I was thinking of superoptimizers, I guess it's a different concept.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#20
post #15
post #4

Are the these new techniques only applicable to WebAssembly? If so, why?

WebAssembly implies static linking (malloc / printf & all are part of the shipped module) and code size matters since it directly influence users (since there might be delays in downloading big payloads). Both factors plays a role in deciding to plan putting work in optimizations like this. There are some general gains to be had with this optimization, and probably the same ideas were already around for a while, but…

Code size always matters, and while wasm may be an extreme case, hopefully this kind of benefit can contribute to shrinking other kinds of code targets.
Post reply on HN