> An important point here is that the native code does use SIMD instructions[...]. Whereas the WebAssembly backend doesn’t support these.
I understand the reasoning of the author, still it would have been nice to have a comparison with non-SIMD native code for those of us who don't keep track of how much the SIMD buys you these day for crypto.
> On a surprising number of tests, Cranelift’s optimizations produced slightly slower code than with optimizations disabled.
So how much of this result is WASM and how much is Cranelift? By the sound of it, Cranelift doesn't produce very optimal output yet, so should still be potential for significant gains, no?
> The original, native code is extremely fast. Way faster than most applications need.
Faster than any one application needs. But virtually anything I do nowadays uses crypto on some level, and wasm isn't only proposed to be used for crypto either. Suddenly, my CPU has to do 2x to 7x the work for the same code, because we collectively decided that using electron and web stuff if the way to go for nearly every mainstream application? I don't think so, really.
WASM seems to me like some people are simply longing for the old days of flash. I don't see why I'd want it.
WASM makes some sense in the browser, but what horrifies me about it is that it is going the way of Electron.
The usual pattern:
1. Instead of figuring out how to do things well in the native space, developers hack something together from web technologies, because it's "simpler".
2. They realize it doesn't work all that well and reinvent some aspect of native environment to fill the gaps.
3. They backport all the complexity back to the web, because they want to run one codebase everywhere.
This is incredibly backwards. We get bloated faux-native apps that use abstractions that make zero sense outside of the web context. We get web technologies that are bad approximations of what has been done reasonably well in the native space. Finally, we get more and more complexity with each iteration.
---
BTW, does anyone remember how Alan Kay said[1] browsers should be designed to be like mini operating systems? Does anyone remember how many people said he is wrong and doesn't understand the web? Well, browsers increasingly are used as an operating system, except it's a system formed by accretion, not by deliberate design. So maybe, just maybe, people should pause, listen to Kay and read up on how similar problems were solved by very smart people before us, instead of just adding more and more web-ducktape to everything.
OK, but wasm is a pretty "boring" VM; it's a reasonable design you could easily arrive at by only considering native code. People are acting like this result indicates that wasm is fundamentally misdesigned, rather than that it simply doesn't yet support SIMD and has a relatively immature compiler compared to GCC and Clang.
I don't think it's fair to quote "2x to 7x slower". What's exciting about WASM is that is has a lot of potential to get close to native performance, a lot of the tricks just haven't been applied yet.
It definitely has a lot of potential for gaming, look at the unreal engine port. Even if that's all it really ends up being, that is still a pretty big deal.
I've been wanting to use it for some b2b applications, or maybe for some reports/charts. Just in places where it makes sense to need that power, but you'd want it in a browser.
Actually I'm really excited about wasm and WebGL inside of the browser. One build target to rule them all. But we're still far, far away from utopia.
Unreal and Unity web builds are not production-ready yet. The cross compilation can be brittle, compile time is huge, the resulting assemblies are large and memory consumption is just too high.
This leads to many, many problems, which are hard to diagnose. Getting games to work on mobile browsers consistently is nearly impossible. For example, last time I checked, Chrome on Android disables WebGL by default and limits memory to 64mb.
Unity is working on "Unity Tiny", but it's in alpha state. Frameworks like Three.js are better suited, but more barebones. Still a long way to go...
It lets web devs use languages other than JS on the frontend. That's primarily why I'm excited about it.
As for why electron, the only real explanation I've heard from people that makes sense is the ease with which you can put together custom UI controls and style them. All of the desktop UI systems are great at the simple things, like putting default OS controls in an app, but complex things like creating custom controls, animations and complex styling appear extremely difficult to accomplish. At least, that's the way it seems to me.
I’m launching this as part of an app platform soon-ish. If you’d like to beta test get in touch. Virtual tables and lists, with keyboard and shift/command selection modifiers, click and drag to select, edge scrolling, sorting, etc. All with a couple lines of code!
I'm having a hard time finding a good, comprehensive comparison between Qt and Electron. My current understanding (which is probably wrong) is that Qt isn't much smaller than Electron itself and I would need to use C++. The animations do not look simple or easy to understand at all, but that's just a first glance.
QtQuick, at first glance, is weird. It uses JS and the animation transitions look pretty close to css transitions.
I guess what I'm looking for here is: how is it a clear win over electron other than just raw speed?
Maybe I'll make a non-simple app in both electron and QtQuick and see how they compare in terms of ease of development, development speed, app size, ram usage and "speed".
1) increases the attack-surface[0] of the browser (arbitrary code execution in victims browser)
2) wasm shares some of the same vulnerability classes from native applications (thanks to code generation frameworks that allows you to spit out wasm in addition to say C - see Nim & others offering generation via llvm backend)
3) cryptographic verification of payloads is still not possible (afaik)
4) binary blobs from untrusted sources which isn't auditable in the way javascript is (raises the bar for security researchers to identify malicious payload, or really just anyone who want's to audit / poke around)
5) thanks to 1+2 wasm shares the same pitfalls as JavaScript when doing crypto in the browser.
6) all of the above works over plain HTTP links (hurray)
7) assumes that security/integrity can be derived from language subsets and a few rules to prevent specific type of behavior[1]
Yeah. Like... Markup languages meant to describe things, then leave rendering to the client. It's gonna be fun once our adblockers become useless because the "Web" apps are essentially blobs that do all the presentation for us. Oh and good luck making that barrier free
most adblockers work by blocking network requests to ad domains, there is nothing wasm can do here. Regarding a canvas site the difference is purely in performance.
1. Perhaps, but we already have JavaScript, and WASM has much less access than JavaScript at the moment. It's definitely something to watch as WASM gets more integrated.
2. Sure, it is intended for native-type development in the browser. In fact, the easiest languages to get started with are C, Rust, and Go IMO.
3. If it's being sent over TLS, you know that it hasn't been tampered with in flight, no? So it is functionally equivalent in this regard to JavaScript.
4. Have you tried to audit obfuscated JavaScript? If that's acceptable, you can do the same with the tools provided for WASM.
5. Yup. However, as I mentioned earlier, TLS removes the ability for things to be tampered with in flight, which means you'll need to trust the server (and the browser). Since that's always the case, I'm not sure what you want to see different here.
6. So don't use HTTP and only use HTTPS? Browsers are moving toward making that look more scary to the user, so it's a browser problem, not a WASM one.
7. No, it assumes the sandbox can prevent security issues. The language subset stuff is to help developers write more reliable code. It won't eliminate crashes from faulty code, it'll just make those easier to spot.
Those CVEs mostly look like problems in the sandbox, which will mature as WASM gets used more. Those types of things point to immaturity in implementation, not design AFAICT.
I think perhaps you and the GP are defining auditable slightly differently. There's being able to look into and figure out what the code you wrote is doing because you have source maps or pre-compilation source, and then there's being able to see what third party code that your browser is downloading and running is doing. Given how hard that can be with JavaScript and obfuscation, I imagine an obfuscating compiler for WASM can do quite a bit if you're willing to take a performance hit on the running code. And something tells me that the entities most interested in obfuscating what their code is doing are more often than not likely to not care too much about the CPU and battery life ramifications of making their code less performant.
The title of the submission is wrong it should be "Benchmarking WebAssembly using libsodium". This isn't about the overhead, it's about comparing native vs. WASM using a concrete example.
Oh boy do I have news for you! Xamarin [1] does exactly this. You write your app logic in C#, which is then AOT compiled to native code. You the write the UI for each platform using native APIs (although you can use Xamarin.Forms if you truly want the same UI across platforms). Xamarin supports Windows, macOS, Linux, Android, and iOS.
They do not translate to a fully native experience. At least on macOS, they stick out like a sore thumb.
And honestly, I think in the end, virtually any such tool will, because to really get the fine nuances and details right, the programmer simply must be aware of them, no automation will do this for you. On macOS, even Apple's own attempt on this ("Marzipan", which allows to generate iOS and macOS apps from a single codebase) suffers from this, although admittedly one may hope that at least in principle this framework could eventually really provide a 100% native experience, provided the people using it are aware if the idiosyncrasies of macOS (and conversely, iOS).
And that's for a tool trying to provide a common API for two UIs, with all three products developed by the same company. It gets much tougher once you also try to get Linux and Windows supported...
I've tried many frameworks that promised to this in the past 20 years, both as developer and user. All overpromised and underdelivered. Qt and wxWindows included. I actually prefer Atom (electron based) over any wxWindows or Qt software I ever tried - though this probably is primarily because somebody tried hard to polish its UI. While (I am guessing) most people who are content with what Qt and Wx deliver won't even notice the need to polish (those who do care eventually realize it is hopeless, and move on).
There's libui, which is pretty good for traditional desktop widget apps.
But that's not what app developers are looking for. They want to be able to throw something together and have it just work and look as intended on any platform.
Ease of getting started is in my opinion among the 3 most important factors for developer adoption of a technology.
What is disappointing here is that they did not run on Firefox or Chrome. The independent WASM runtimes are not as mature as the browser based ones, so it would be great to see the difference.
I would like to see the same results with, say, 1,000 trials and 10,000 trials as well—how much of the slowdown is a fixed overhead, and how much of it is that the code runs X-times slower?
Is libsoduim written in a low level language like c or did they compile javascript down to webassembly somehow? It wasn't clear from the article. At least my reading of it.
libsodium is written in c. "Pure javascript" is a supported compilation target[0] of the project. Emscripten is used to compile the c to javascript. There's also now a wasm compilation target, again via emscripten.
The c source code is really excellent[1]. It's worth browsing!
I understand the reasoning of the author, still it would have been nice to have a comparison with non-SIMD native code for those of us who don't keep track of how much the SIMD buys you these day for crypto.
> On a surprising number of tests, Cranelift’s optimizations produced slightly slower code than with optimizations disabled.
So how much of this result is WASM and how much is Cranelift? By the sound of it, Cranelift doesn't produce very optimal output yet, so should still be potential for significant gains, no?