azakai

24 ms·

331.
by azakai 5y ago
Ah, good point, memory consumption might indeed be a factor here. If that's the case I'd expect higher variance in the measurements perhaps - looking for that in the raw data could be interesting.
332.
by azakai 5y ago
In general you'd be right, but this is not a benchmark of code running in those languages. There is no loop, no heavy computation - it's just returning the headers. That should take less than 1ms in either language. Startup time m
333.
by azakai 5y ago
CFI helps with control flow exploits, but it doesn't prevent memory corruption for example. This sandboxing technique ensures that both control flow and memory accesses remain in the sandbox (except for when you explicitly allow otherw
334.
by azakai 5y ago
Thanks for the details bholley! Do you plan to use the signal handler trick eventually? Less portable but in my tests it shrinks the total overhead by half (from masking's 29% to 14%).
335.
by azakai 5y ago
Mostly that's the case, yes. The main benefit of wasm sandboxing in this situation is to keep any exploit of these libraries in the sandbox - no memory corruption outside. That's a big improvement on running the same code outside
336.
by azakai 5y ago
For something like SSE to work you'd need both wasm and wasm2c to support it. Wasm doesn't support all of SSE, but wasm does have SIMD support which is a portable subset of common SIMD instructions. You may lose some performance t
337.
by azakai 5y ago
There are detailed performance numbers here on a variety of real-world codebases: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html tl;dr Something like ~14% when using the best bounds ch
338.
by azakai 5y ago
There is that risk, yes. For wasm2c to be correct it must emit C code without undefined behavior. As best we know it does that properly today, and we've tested and fuzzed it quite a lot, but whenever you use an optimizing C compiler on
339.
by azakai 5y ago
Wasm is defined to trap when it accesses memory outside the sandbox (the embedder can decide how to handle that trap, say by shutting down that particular sandbox). With wasm2c the trapping can be implemented in a variety of ways, for examp
340.
by azakai 5y ago
For technical reasons adding compiler flags to do that is fairly hard. You'd need to handle a lot of things like compiling to the sandboxed format, system library support, the FFI to normal code, etc. It would be possible to do all tha
341.
by azakai 5y ago
You're right that this could be done on LLVM IR. The MinSFI project did exactly that basically, several years ago, but it did not see adoption sadly. The benefits of wasm over LLVM IR is that wasm has already done the work to define th
342.
by azakai 5y ago
Yes, browsers will not allow you to block on the main thread. Atomics.waitAsync is supposed to be used instead. This is a fairly difficult aspect of multithreading on the web, and it makes things more complicated than other platforms (like
343.
by azakai 5y ago
> prevent any use-after-free (by just zeroing out the freed memory) It's not quite that simple if you want to reuse that memory address. Not reusing memory addresses is a definite option, but it won't work well on 32-bit (you c
344.
by azakai 5y ago
Fair enough, but parallelism isn't just about cores since SIMD can also help. Also, immutability doesn't just help through parallelism, it also allows other things (as another example, avoiding redundant work like loads of an immu
345.
by azakai 5y ago
I'm not an expert on this, but one example is that immutability lets you operate safely on things in parallel. But JS VMs are not aware of objects that are immutable in Clojure's semantics, and in any case, do not operate on objec
346.
by azakai 5y ago
This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.
347.
by azakai 5y ago
I don't remember that game specifically, but I assume it used PyPy.js, https://github.com/pypyjs/pypyjs
348.
by azakai 5y ago
> and is also buggy If you've found any bugs in Asyncify please file them! There are no open issues atm about any general bugs, aside from some corner cases with features like dynamic linking.
349.
by azakai 5y ago
It takes some work (mostly due to LLVM building code to run later in its build system as it goes), but it's very feasible. LLVM has been ported to Wasm (and before that to JS) many times, for example: https://github.com&#x2F
350.
by azakai 5y ago
Well, Pyodide does port CPython directly to wasm. You're basically running CPython on wasm instead of on x86 - it's just another architecture. That's the natural thing to do I think. But I see what you're saying, one cou
351.
by azakai 5y ago
> It is theoretically possible, given enough work, run Python directly in Wasm. To be fair that's not just theoretical, the Pyodide project does exactly that: https://pyodide.org/en/stable/ There have been
352.
by azakai 5y ago
As others already mentioned, funding is just one factor here. Mozilla decided to stop focusing on porting such applications to the Web before 2020's layoffs, when Mozilla was still growing. The decision came after some management chang
353.
by azakai 5y ago
That's not ideal, of course - the point of the Web is that you can visit a website from anywhere - but in practice, when this type of cutting-edge application arrives on the Web, often at least initially it doesn't run optimally i
354.
by azakai 5y ago
I think an interesting advantage of Grain is that it not only compiles to wasm but is wasm-first. Bringing existing languages to wasm is incredibly important, and probably that is 99% of wasm today. But a new wasm-first language that is des
355.
by azakai 5y ago
Oh right, good point. Other types of memory safety are more relevant here then.
356.
by azakai 5y ago
That would not have helped with use-after-free, though, which Swift does solve.
357.
by azakai 5y ago
That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in
358.
by azakai 5y ago
Ah, I think we disagree on the goals of wasm. Yes, if you want to write a client-side webapp you run into limitations. That wasn't one of our main goals when we created wasm, though! It would be great if that materializes - more option
359.
by azakai 5y ago
Generally true, but just to add to that, in languages like Rust and C++ you often end up including stuff you don't need due to toolchain limitations. For example, indirect calls (from Rust traits or C++ virtual methods) are hard to get
360.
by azakai 5y ago
Small note on this: > What this article is highlighting is that Wasm is still an immature technology. I assume you meant on the server, where wasm is fairly new, that's true. On the browser, wasm is a mature and stable part of the W

More ›