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

81–90 of 111 posts

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

#81

Post by mhh__ »

deathanatos wrote: post #70
mhh__ wrote: post #64

Earlier quoted context omitted.

Those AVX instructions use more power at least in part because they massively better utilize the silicon, so you're making a tradeoff between speed and efficiency as per usual.

Sorry, but to be pedantic for a second: do they consume more energy , which is really what I care about for battery life? (Let's assume I'm committed to asking the machine to do whatever work it is that I asked it to do, so the required computation is constant, for discussion.) My understanding of AVX is that it consumes more power , yes — but the point the parent makes is a good one: if it finishes faster, where doe…

1. This all depends massively on the actual workload and chip, a lot of people are basically winging it when it comes to AVX power consumption stories. The rub is also that, especially on laptops, you can get convexity in all the scaling problems e.g. you do more work, good, but then the laptop throttles then stays throttled for a while etc.

2. The original (real) power issues with the original/early AVX-512 desktop chips have basically gone away. It's not far off the timescale that you'd looking back to be bashing AMD for bulldozer.

I'd measure it for you on my machine but I don't have an accurate power-o-meter for my computer.

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

#83

Post by enos_feedler »

runeks wrote: post #49
zeusk wrote: post #17

Earlier quoted context omitted.

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

> At what point does the browser become an "os", what's next? When it no longer requires an OS to run.

So ChromeOS

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

#84

Post by namibj »

carlopi wrote: post #22
JoshTriplett wrote: post #5

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?

Thanks a lot! I also believe it would be cool to upstream this, we will have to sit down and do some planning. Compilation time could improve (I was actually working on this today), but it's already in line with other optimizations, taking Currently it's applied to all functions, since runtime it's anyhow somehow linear in the number of Instructions a Function has, but possibly in more costly versions of this (that w…

Consider integrating with PGO there, at least for getting most of the gains (assuming they are about performance, not binary size) with a fraction of the cost.

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

#85

Post by astrange »

eklitzke wrote: post #48
fsiefken wrote: post #32

Earlier quoted context omitted.

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".

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.

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

#86

Post by astrange »

the_duke wrote: post #43
pjmlp wrote: post #26

Earlier quoted context omitted.

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…

You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access…

Darwin has quite good sandboxing, although how to actually use it isn't documented.

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

#87

Post by astrange »

saagarjha wrote: post #77
carlopi wrote: post #22

Earlier quoted context omitted.

Thanks a lot! I also believe it would be cool to upstream this, we will have to sit down and do some planning. Compilation time could improve (I was actually working on this today), but it's already in line with other optimizations, taking Currently it's applied to all functions, since runtime it's anyhow somehow linear in the number of Instructions a Function has, but possibly in more costly versions of this (that w…

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.

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

#88

Post by astrange »

api wrote: post #24

Please mainstream this in general. It would save a decent amount of RAM if it became a standard part of LLVM and would probably improve overall performance due to cache effects. Dead code sitting in RAM would be bad for cache locality.

PGO already solves that if you can do hot/cold splitting, though I don't think that pass in LLVM is very maintained.

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

#89

Post by jerry1979 »

jfoutz wrote: post #79
saagarjha wrote: post #76

Earlier quoted context omitted.

You can Rowhammer from JavaScript already, so this really has nothing to do with CheerpX.

Very true. Let me try to restate. I don't know how to prove the absence of a thing. I can only prove existence. I was trying to highlight that every layer of abstraction has vulnerabilities all the way down to the hardware level. I'm perfectly willing to accept that CheerpX has no known vulnerabilities.

It may have more to do with the idea that since CheerpX runs in the browser, the threat model of CheerpX is the same as the thread model of using your web browser to browse any other site.

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

#90

Post by johncolanduoni »

pjmlp wrote: post #40
sfink wrote: post #36

Earlier quoted context omitted.

Right, you can corrupt memory and thereby alter behavior, but that memory is a managed array. You can't corrupt anything outside of the application's own memory. As you say, you can change behavior, and thereby do whatever you want with whatever the wasm application is allowed to access. Which is a very limited set of things. Likening it to Java applets or Flash is deceptive -- yes, you can still hack them and exploi…

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.
Post reply on HN