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

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

leaningtech.com

Post reply on HN
Print view View original

91–100 of 111 posts

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

#91

Post by fulafel »

titzer wrote: post #75
fulafel wrote: post #19

Earlier quoted context omitted.

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.

Superoptimizers have gotten a lot better in the past few years. E.g. have a look at [1]. [1] https://arxiv.org/abs/1211.0557

Thanks, cool stuff.

This paper from the same project was also cool: https://raw.githubusercontent.com/StanfordPL/stoke/develop/d...

Quote from abstract: " For many applications, the best possible code is conditionally correct: the optimized kernel is equal to the code that it replaces only under certain preconditions on the kernel’s inputs. The main technical challenge in producing conditionally correct opti- mizations is in obtaining non-trivial and useful conditions and proving conditional equivalence formally in the pres- ence of loops. We combine abstract interpretation, decision procedures, and testing to yield a verification strategy that can address both of these problems. This approach yields a superoptimizer for x86 that in our experiments produces binaries that are often multiple times faster than those pro- duced by production compilers"

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

#92

Post by fulafel »

fsiefken wrote: post #32
gavinray wrote: 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

What would the impact be on battery life compared to native execution? Can one get it just as power efficient as native execution, only slower? For computationally less intensive applications browser portability might be an excellent tradeoff. It gives a new meaning to the slogan "write once, run everywhere".

Users of computationally intensive applications aren't such efficiency freaks much of the time, they tend to take "good enough" in that dpartment, like it is in other areas. In addition to cross platform portability they appreciate outcomes that stem from development performance/productivity (timely app delivery, app correctness and robustness, low cost, features, adaptability to feature requests, usabiity, etc).

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

#93

Post by pjmlp »

johncolanduoni wrote: post #90
pjmlp wrote: post #40

Earlier quoted context omitted.

Imagine a WASM module used to control security authentication in the browser, or controlling IoT devices in a factory, now that it is fashionable to run WASM outside of the browser.

You could also imagine a native executable doing the same, which in most cases won’t even have the level of control flow integrity protection WASM will have. I’m not clear what superior alternative you’re comparing with.

Currently WASM has less security protections than native sandboxes, not more. Read security section of the standard.

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

#94

Post by pjmlp »

sfink wrote: post #52
pjmlp wrote: post #40

Earlier quoted context omitted.

Imagine a WASM module used to control security authentication in the browser, or controlling IoT devices in a factory, now that it is fashionable to run WASM outside of the browser.

Right, I agree that wasm being used to control nuclear launches is not fundamentally better than native sandboxed C++ code in terms of preventing unwanted nuclear launches. But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light. I'm guessing w…

Yes, it is those unwarranted assumptions that irk me, as then you see talks how everything is "magical" with WASM, when it is just yet another bytecode format.

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

#95

Post by pjmlp »

the_duke wrote: post #50
pjmlp wrote: post #45

Earlier quoted context omitted.

And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed. There is no magic in WASM, only when the only thing it does is warming up a CPU.

I'm happy to have a technical discussion, but your comments always stop at "Wasm bad", without countering the arguments.

No post body was provided.

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

#96

Post by detaro »

pjmlp wrote: post #26
unnouinceput wrote: post #21

Earlier quoted context omitted.

This sounds like ActiveX. Security issues related to ActiveX are solved or not? Because if they are not, then it's just a reskin of ActiveX and malware authors gonna have a field day.

That is the thing with fake security advertising of WebAssembly. You can just as easily compile heartbleed into WebAssembly and call it a day. Yes it is sandboxed, but hardly any different than running an OS process with sandboxing lock down regarding which OS syscalls are allowed. Think it this way, just because an OS container cannot exploit its host (minus hypervisor bugs), that doesn't mean that what is inside is…

So, a lot better than ActiveX, which didn't have effective sandboxing and all the problems webassembly still has due to (lack of) memory protection etc.

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

#98

Post by MaxBarraclough »

astrange wrote: post #85
eklitzke wrote: post #48

Earlier quoted context omitted.

Generally things that run faster are more power efficient, because the CPU has to run for less time to do the same work. There might be a few odd exceptions here and there, e.g. certain AVX instructions can use a lot of power, but they're not common.

I've seen several student projects that try to find "more energy efficient" compilations through random searches of compiler flags etc., but they never get any results. In a JIT language you might be able to save time by running the JIT less often though.

Have any of these attempts taken a profile-guided approach?

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

#99

Post by carlopi »

hackcasual wrote: post #74

How does this differ from existing LLVM interprocedural optimizations? Particularly value propagation sounds like it would handle a lot of these cases. > You might have heard of dead-code elimination, an LLVM optimization pass that removes code proven as unreachable. I was actually interested in less-obvious situations. In particular blocks that are reachable on the control flow graph, but not when consider wider exe…

Take this other example: https://gcc.godbolt.org/z/nebP68Tx8

Here by playing HumanCompiler it should be possible to prove that the if condition never evaluates to true, so removing the if is safe.

This is an example of optimization that PartialExecuter is able to do. Note that some combinations of other optimizations might also be potentially able to get to this result (say adding a tag "is always power of 2", but doing this in a general way it's what PartialExecuter does well).

Somehow similarly, clang might be instructed to enable a check to avoid including printf_float and somehow detect it and exclude it (this is what happens here), but this is hardly generalizable.

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

#100

Post by saagarjha »

astrange wrote: post #87
saagarjha wrote: post #77

Earlier quoted context omitted.

My understanding is that CheerpX, but simulating a full userspace, can optimize all the way through system libraries, which are typically very general and have lots of code that is “dead” to your application. How would this approach fail for applications where the code tends to be more specific to the task?

Seeing through system libraries sounds problematic already, since some of them like libc violate aliasing when you can see their implementations, even in LLVM byte code form.

That's actually a good point–more aggressive optimizations that peek through libraries that are not typically visible to the compiler are generally going to break things like allocators. Although, I guess something must be compiling them anyways, so perhaps it might end up OK?
Post reply on HN