Earlier quoted context omitted.
And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?
Yes. Presentation matters.
I would disagree
Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
151–160 of 212 posts
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#152I didn't watch the video, does it say how much of the perf gap is due to the unix API's they tried to replicate and how much is due to wasm actually being 'slower'?
50% the speed of native is really not bad, it's not like wasm is done being worked on. That's a very promising start.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#153Earlier quoted context omitted.
Except you can run wasm on an iPhone. I like Java but it's not like they didn't try Java applets. They really screwed the security model. I guess in that sense what the parent is asking for is actually not nearly as feasible as using the current web security model.
> Except you can run wasm on an iPhone. An arbitrary decision made by the manufacturer. If Apple decided they didn't want to support web assembly tomorrow, do you think that would kill the iPhone or WASM?
If Apple decided they didn't want to support web assembly tomorrow, do you think that would kill the iPhone or WASM?
That's a good question, and it's certainly not one I'd want to bet on as Apple.
When they managed to kill off Flash and Java applets, they were getting rid of the two awkward technologies that almost everyone in web development disliked. There were useful replacements coming down the line with HTML5, ES6, and so on. It still took several years for the plugins to die out completely, during which time the browsing experience on Apple devices was noticeably inferior to everyone else's. Arguably it was only Chrome pulling support that finally put an end to the matter.
Today, Apple's reputation isn't what it used to be, with its normally loyal and enthusiastic fan base increasingly questioning the price of new devices, web developers increasingly questioning the lack of support for modern technologies in mobile Safari, native developers wary of Apple's policies around the App Store and how much of the money it's taking for its cut, and the walled garden ecosystem looking increasingly isolated in a world full of connected devices and data sharing. It's hard to see any of these trends changing in Apple's favour any time soon.
Right now, WASM is in its infancy, but if you stop and look at what is being attempted, it is arguably the most important new technology in web development. It's already reasonably well supported across almost every browser that matters, but not yet widely used. But give it a little time to establish it as a target for better languages than JS and to develop supporting tools and libraries, and it's not hard to imagine that in a decade's time we'll all be wondering what we were thinking using JS for so long.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#154Earlier quoted context omitted.
The thing I'm most excited about right now is WASI. It provides abstractions for system calls like fs, sockets, graphics, etc. But the best part is that the entire API is being designed with security and capabilities in mind. WASM binaries have to explicitly declare resources they want access to, or risk not being allowed to access them. (The application could also choose to further prompt the user, but i think in mo…
(I'm one of the authors of Not So Fast) In the paper we build on previous work from our group, Browsix ( https://browsix.org ) to provide a similar level of abstractions to WASI (the syscall layer). We've talked about having Browsix support running programs targeting WASI in the browser. One of the great things about supporting "Unix" in the browser is that it makes bringing a whole class of already written applicati…
Just so I understand, is Browsix running on top of WASI... or are you saying that Browsix will have an option to target WASI? Browsix looks pretty cool, although it's hard to wrap my mind around use-cases outside porting common C libs (like pdf editing).
I'm thinking that decentralized apps would be an interesting Browsix use-case where users can run the full app platform stack in their browser... or connect to dedicated self-hosting servers that are running the same exact code but as native Go/C/Node services.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#155Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#156Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…
Why do we - developers fall into this trap?
The models for installation, security, privacy and updates on the desktop platforms have barely improved in twenty years, and they really needed some improvement.
The models for installation, updates, payment, portability and development tools on the mobile native platforms all have major downsides as well.
If you build and distribute your software as a web app, you can still do everything that matters for many purposes, you retain complete control of your own software, infrastructure and business model, and your app can work well with relatively little effort on a much wider variety of target platforms.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#157So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installa…
> So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. But we've accomplished that by effectively turning web browsers into VM's that have a complexity on par with a full operating system. I have a sneaking suspicion that we're going to end up deciding that was a huge mistake.
You'd have to go back farther than the intro of WASM to see a time that wasn't the case.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#158Earlier quoted context omitted.
You're going to have a hard time convincing me that the browser as a runtime is a better solution than a runtime actually designed for running applications.
The problem lays in the UI. Most of what a modern application does is provide a decent UI to interact with data on a remote server. Swing was a terrible UI library. I never saw a java applet that wasn't ugly and clunky.
IntelliJ?
But I agree: HTML/CSS/JS is far easier (eg: threading) and generally results in a more polished experience.
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#159Earlier quoted context omitted.
(I'm one of the authors of Not So Fast) In the paper we build on previous work from our group, Browsix ( https://browsix.org ) to provide a similar level of abstractions to WASI (the syscall layer). We've talked about having Browsix support running programs targeting WASI in the browser. One of the great things about supporting "Unix" in the browser is that it makes bringing a whole class of already written applicati…
Just so I understand, is Browsix running on top of WASI... or are you saying that Browsix will have an option to target WASI? Browsix looks pretty cool, although it's hard to wrap my mind around use-cases outside porting common C libs (like pdf editing). I'm thinking that decentralized apps would be an interesting Browsix use-case where users can run the full app platform stack in their browser... or connect to dedic…
WASI provides a cross platform definition of "system calls" ( https://github.com/WebAssembly/WASI/blob/master/design/WASI-... ), so that you could write a program, compile it for wasm+wasi, and run the program on any implementation that provides those system calls, like cranelift on Linux, something on Windows, Browsix in the browser.
Browsix and Browsix-Wasm were developed before Wasm and WASI respectively were available, so they have their own definition of syscalls that are conceptually similar but not exactly binary compatible. We hope to modify Browsix to support running programs targeting WASI in the browser, which would free us from having to maintain our own fork of Emscripten.
Do you have specific decentalized apps or usecases in mind? We would love to hear more about the use cases of running things like that in the browser (and have done some work to make socket connections between programs in different browser tabs work over WebRTC)
Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
#160It looks like there's another issue that is not quite mentioned: the Chrome code generator is using %rbx to point to the start of the WebAssembly memory, which means that the available addressing modes are severely reduced and a register is used up. It seems like that it could use a %fs or %gs segment override instead (one of which can be programmed arbitrarily at least on Linux), which should be cost-free on all x86…
> the Chrome code generator is using %rbx The memory base is actually loaded from the instance pointer, and neither of these are pinned to specific registers. They're both allocatable by the register allocator. > %fs or %gs segment override instead This is tricky to do for all platforms that V8 supports. I'm not sure it's free; it's still at the very least another prefix.
> This is tricky to do for all platforms that V8 supports
It can be done only where supported. Ivy Bridge and later have instructions to set them in user space (WRFSBASE/WRGSBASE), and although it needs the OS to enable it, I would expect it can be done on all significant x86-64 OSes.
> I'm not sure it's free; it's still at the very least another prefix.
There are benchmarks that show TLS is as fast as global variable, so it's probably free (aside from the impact on the I-cache due to increased code size, but using a general purpose register is probably much worse due to additional instructions and extra SIB bytes).