So... don't completely discard native desktop apps just yet? That said, I suspect we'll soon see something akin to Eelctron for WebAssembly: a toolkit for making UIs that acts as a permissions context/bridge to making calls into the host operating system's API. Or maybe WebAssembly won't be the revolutionary tidal wave of change that many of its proponents hope it will be?
Tl;dr: 2x slower in FF, 2.5x slower in chrome. Depending on the application, that doesn't seem to be a huge tradeoff. Certainly many developers are comfortable writing things in python, which is likely hundreds of times slower than C++ in many problem spaces.
TBH though my big hope for web assembly has nothing to do with the web at all, but as a distribution format for drivers that can be installed on any cpu arch/kernel. Finally, my dream of BSD on risc-v is achieved! ....or more likely, just running linux on arm.
You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute? Why? How is that beneficial to anyone except the person packaging the driver?
The browser is a really good sandbox. The security of browsers is also what makes web apps easy to distribute.
That said I don't see the point of writing drivers in webassembly. If you want better security for drivers, there are better endeavors like microkernel architectures which Linux still isn't using.
> You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute?
A different way of phrasing this would be "would you prefer a driver that uses 2% of your cpu vs no driver at all? Note that if the hypothetical non-existent driver was written in c, it would only take 1% of your cpu"
> Why?
Because the alternative for many alternative OSes is no driver at all.
> How is that beneficial to anyone except the person packaging the driver?
Because if it's more convenient for the packager, then there's a better chance that they'll package a driver that way, which means I'm more likely to actually get the driver in the first place.
Are drivers actually being written in WASM? In Windows, drivers often require kernel-space code, which require a higher level interrupt request level (IRQL). Incorrect dependencies in IRQL are the leading cause of BSOD[0]. If WASM got this right, it would be impressive. It also might mean that compromising the sandbox is Very Dangerous.
[0] IRQL exception was at least the leading cause when I was a Core OS developer for Windows.
Yeah, I'd say that it's actually pretty good result. Too bad that the benchmark doesn't include any non-browser WASM runtimes, like Wasmtime or Wasmer.
"Certainly many developers are comfortable writing things in python,"
But python is a high level script language with gc. WebAssembly is very lowlevel, so the people who could and would write in python will not write in wasm and also not in C.
Wasm is still awesome, it is just not, what many hope it will be. And a distribution format for drivers? Well, I am not a low level expert, but that seems very unlikely to work out, from what I understand.
The point is that people are clearly willing to leave magnitudes of performance on the table just so that they can use their language of choice.
That's what Webassembly enables today: You can use C/C++, Rust, Go and several others. Of course the ecosystem is not as mature. Languages with a big runtimes aren't good candidates for lean web apps. Performance isn't the dealbreaker though.
Globally compatible drivers is a pipedream, because the problem is not that the machine architecture is different but that the API they interact with is fundamentally different. Unless everyone agrees on some sort of standard like NDIS, but Linux has more or less promised never to have a stable API.
well sure, but in this hypothetical future, someone has added the ability to load wasm files as drivers, and the API that that functionality exposes _could_ be stable.
A difference to Python is that Python has the escape hatch with native modules. A PyQt application as arbitrary example relies on native code for doing most of the handling and only some small parts of business logic have to be done in Python. With WebAssembly the Qt stuff is compiled to WebAssembly as well and therefore suffers from the slowdown as well. Only the actual rendering can be offloaded to WebGL and hardware. (Still we were able to write snappy UIs more than a decade ago, where systems were a lot slower so for many cases that should be fine)
The reserved registers may always be a problem. It reminds me of the people who complained about massive slowdown in games when Vista released. The games were so optimized to fit in a single page that the few new pieces of state in the window manager caused page thrashing.
For single-instance scenarios with a single memory, I think using a 0-based memory will be a lot more efficient than reserving a register for the memory base. That doesn't fly when a Wasm engine is embedded into an arbitrary C++ program, but for standalone scenarios this may be feasible.
> an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online
> [security] checks are necessary for WebAssembly’s safety
> current JavaScript implementations reserve a few registers for their own use, which increases register pressure on WebAssembly
Runtime security checks are not necessary for WebAssembly to be safe. You could compile from a memory-safe source language to start with and add support in the WASM format for proof-carrying code. Then all that's needed in the WASM runtime is a static check of the added proof information, which could be very quick. Runtime checks could still be used to run WASM that doesn't carry proofs of safety, keeping the same performance cost.
(Some occasional runtime checks would nonetheless be needed, since safety against e.g. excessive stack use could depend on what the program is doing at runtime; but they would be quite rare and come with very little overhead.)
> > an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online
> One of these speedups is streaming compilation, where the browser compiles the code while the code is still being downloaded. Up until now, this was just a potential future speedup. But with the release of Firefox 58 next week, it becomes a reality.
> Firefox 58 also includes a new 2-tiered compiler. The new baseline compiler compiles code 10–15 times faster than the optimizing compiler.
Seems to deal with the "whereas WebAssembly compilers must be fast enough to run online"
Streaming and tiering do help, and I believe all browsers do that. Still, the article's point is valid that offline compilers can spend more time compiling, because even if you have a faster tier before you, running a slower compiler eats up battery and increases the time before the code runs at full speed.
> an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online
This echoes the arguments for / against java. The compiler in this context mustn’t be “fast enough to be online” - it must be fast enough to keep up and able to smart enough to know what’s important. It also benefits from watching the actual program execution. Presuming you can “warm up” the application, it might just do fine.
I vaguely think that a lot of people are considering the compilation as a one time deal. It could be a phased thing. Java’s a great example of that.
Ok. 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 quite a few times already, with cross platform standards. No matter what vendors will fsck'em up with proprietary things.
Regardless of is this a trap or not, it's obvious to me that developers want simplicity and consistency. WA provides both so don't wonder why it's taking off.
> So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas
Yeah, right. Compilers do not deal with the difference in presence / absence and different implementations of various features on different platforms, be it native OS or Browser OS.
Is that so? Worst case I can imagine is to have the same compiler emit app-firefox.wasm and app-chrome.wasm binaries from the same codebase, but I think this is highly unlikely.
But there probably always will be a safe flag that generates everywhere running binaries.
Yes, declaring the hard parts to be someone else's problem always works out in the end, doesn't it?
Hopefully in 20 years, when people are talking about MetaWebAssembly to abstract away the platforms that run on WASM, you'll have a different perspective on what you've said here.
Oh come on. If you are doing any kind of development, you too, are relying on abstractions and someone elses machinery. That doesn't make you lazy or amoral or something.
Yes, but I'm not under the delusion that adding more abstractions will solve the problem. And actually, I really wish there were fewer abstractions because they often just get in the way.
Timing, probably. Java was too slow in downloading and running on the commodity networks and hardware available at the time. Now that both of those are fast enough, we're seeing another implementation of the same idea.
I was involved with Java applets when Java was in beta and one of the most annoying things was that JDK 1.0 did not come with serialization.
I would build applets that displayed content generated on the server and serialization-deserialization code could be 2/3 of the program. Most people had a slow net back then, so the download performance was a big deal.
JDK 1.1 put serialization in right away, but Netscape had already introduced it's own incompatible serializer, and there were delays in getting JDK 1.1, plus people didn't like Java serialization -- practically there was a year or two where you couldn't use it.
Applets had enough teething pains that people quickly came to the conclusion that they weren't worth the trouble, then Flash came along which came closer to what people wanted at the time.
I'd really like to see Flash reborn on WASM. WASM is a standard, so there will be no problems known to software produced and distributed by a private business (Macromedia/Adobe), problems like closed format, resources access control etc.
WASM + Canvas or WASM + OpenGL should give a significant part of that... but what made flash really special was the tooling around it. I wouldn't be surprised to see Adobe make some strides there, but the output may be less than optimal.
Java applets came about in the days of 486s. They had huge startup time, were usually in a tiny little window, and everyone was starting from scratch with few libraries and drawing primitives. There was no webgl or compiling of existing UI programs into webasm with emscripten.
Webassembly is not magic. You still have to download and possibly cache code and assests. Call it install or not.
I think win is having free software or at least opensource apps that are trusted by distributors and easy to analyze/modify, and actually own (meaning have on your harddrive and fully control). And we already have that win.
WebAssembly doesn’t support all the things that require installation. There is no integration, the apps can’t register for extensions, they can’t hook other programs. Most of this integration is only marginally useful anyway but people did need iOS, a popular OS that just does not support that kind of thing, to see it.
[Former developer on the Windows Component and Applications team, renamed Developer Experience team]
There's a big difference between an imperative (e.g. arbitrary code) and declarative installation process. Imperative installation is most common on Windows due to the initial decisions made by the registry designers + the Windows Installer originating from Office and starting with imperative. Declarative installs are common on the Mac where "installation" usually means dragging a binary from the DMG to your Applications folder. OS X then manages OS integrations declared in an app manifiest.
Declarative installations delegate to a system which has a broader view and standard mechanisms to handle state transitions required for installs, upgrades, and uninstalls. Imperative installations frequently leave residue and are hard for even Windows to fix. I spent years of research and have several patents on trying to figure out how to distinguish between "extension points" of the OS and private state to create a sandbox with the necessary pinholes. Even with those tools handy, many software shops see no reason to upgrade because the Windows end user accepts a life of installers.
I see logic in starting from scratch. This time we can create an end user expectation of declarative and (laterally + vertically) sandboxed apps. Hell, that's what we tried to do with Windows 8, but it was unfortunately restricted to the "modern" (aka full screen) apps that never caught on.
Why? I've had that clean painless install on Windows like forever. My installs are always a single executable that copies itself to a proper place, gets any data if needed from company website and when uninstalled leaves no trace on a system. Never touched registry. There is nothing here that calls for "starting from scratch"
In practice, installation in web browser would use a service worker and some hand written caching logic. Neither is declarative. In fact, declarative (https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5) variant of this functionality was deprecated because devs wanted more programatic way to "install" offline web apps.
It's still sandboxed, and limited, so what's cached this way is perhaps easy to totally remove by the browser. But that's not because of the declarativeness, but because of sandboxing.
Makes sense, but if there’s any OS integration (e.g. file type registration, desktop links, etc) then the app isn’t truly sandboxed by these means alone.
but download and run is the point. with webassembly in the browser i don't have to worry that the installation tool will mess up something on my system. if i want to get rid of the application, i only need to clear the cache.
sure, linux is doing that much better, but until we get linux (homebrew for windows?) installers for windows, i'll prefer webassembly, at least for casual use.
There is no free lunch in this universe. For big applications like CAD there will be nothing "instant" for in case of deployment as web apps. Downloading native packed archive and running install may actually be faster.
Sure, there are exceptions. Cinemas also still receive movies as physical harddrives for a number of reasons, but for most people and situations, streaming is fine.
I am not sure about "most people" but I use fair number of applications (not including software development tools here as they do not pass"most people" criteria ) and none of those are streamed. Every time I try anything web based, online Tetris excepted ;) it sucks one or the other way
But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box.
Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-technical curating mechanism which has all sorts of conflicts-of-interests of what's morally acceptable and what's not, WASM is the next best thing to an open, yet secure, platform.
Desktop Linux aside, the web is currently the only open platform for distributing software outside of the interests of a single "platform owner". Google may close this "loop hole" soon, so I'm not too optimistic for the future, but today, that's what it is.
I am partially an ISV and we provide pure native application for Windows at the moment. No UWP/.NET/APP_STORE/WHATEVER . It is digitally signed and distributed by downloading from our web site. So far no problem. Since we've been in business a number of years there are no any browser/OS/Antivirus level warning boxed during downloading and installation.
> Can you distribute a native application on macOS without Apple's blessing? No, you can't.
I've been running the Catalina betas, and running non-notarized apps only requires right clicking instead of double clicking. If that's too much of an obstacle for you, you probably shouldn't run the app.
Gatekeeper on macOS is a technology designed to protect careless users. It makes it slightly harder to shoot yourself in the foot. It doesn't prevent you from doing it, though.
> Until OS vendors are willing to provide a safe sandbox to run untrusted code in
Thing is, "safe" OS-sandboxes are not safe; "local" privilege escalation vulnerabilities are still pervasive. Until OS's are safe enough that I can run `sudo -u nobody untrusted_binary` and not even think about the possibility of it taking over my system, something like the WASM sandbox (perhaps extended with WASI and other optional mechanisms) will always be needed.
The Web of hyperlinked documents would still work. But webapps would not be able to run arbitrary code the moment they were navigated to. Perhaps there should be a clear user-visible distinction between an HTML document with some styling and a full-blown application (that happens to use DOM for layout).
But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway).
WASM is the next best thing to an open, yet secure, platform.
So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)
Desktop Linux aside
Maybe we should make Linux an acceptable platform for more people rather than optimizing for proprietary web applications that you don't even own a copy of anymore.
> Maybe we should make Linux an acceptable platform for more people rather than optimizing for proprietary web applications that you don't even own a copy of anymore.
Won't ever happen for two reasons: 1) The Linux Desktop community would have to admit that there are better ways to do things, and 2) They'd have to agree on what those things are. 20 years of Linux Desktop history show these things to be impossible.
Theoretically, a new community could spring up and put a new userland on top of the Linux kernel, like Android did, but it would seem like the people who have the interest in doing such a thing (like myself) lack enough time, talent, and/or ability to organize sufficiently to pull it off. Not to mention that we'd all have to agree too.
Have you taken a look around Casey Muratori's handmade.network? Or interacted much with the guys who watch Jonathan Blow's livestreams? They make much the same point you do about taking the linux kernel and creating a new userland around it.
Anyone who's interested in working on something like this, email walkinginalinuxuserland@lj3.me. The least we could all do is keep in touch, right?
Yes, I've hung out on Johns and Casey's streams. I don't bother much with handmade.network because very little there interests me. Essence is kinda neat, but it is a long way from practicality and I'm not sure how much my ideals and Nakst's align.
I also think a forum or IRC channel would be more appropriate, but email is a start and I appreciate you taking the initiative.
See also Probono's Hello[0], but I'm not sure he hasn't decided that Haiku already fits for him.
This is it. Let's be honest - the things that make linux difficult are wireless and graphics drivers because the kernel api's keep changing (to prevent vendors from making non-open-source drivers). Why can't we write a unix compatible desktop os whose only difference is running the drivers in userspace?
Something like Redox(1). It's even MIT licensed, so you could include it in a commercial distribution with your own changes if you so chose when you made your gui.
Well the alternative is exchanging data, not code. Actually this was the initial idea on the web, hyperlinked data. Look where that brought us. Maybe we could devise a better model with a client (code) that is simple enough and universal enough, and the server providing/receiving only data and not code? That is, instead of me running the publisher's code on my terminal, i run my code on the publisher's data, exchanging data with them. I am not aware of anything to that effect that is universal enough to replace the web. Thus, sandoxing untrusted code as being the way forward.
I think the way forward is to stop worry too much. Like you really gonna be worrying running "flight simulator". I think it is a FUD designed mostly to support big and cloudy providers. Those are the real entities one should worry about. They spy 24x7 .
> We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)
I don't think that is the case. Simply because a WASM application will have to request the permissions it needs up front (assuming a sane runtime) and you don't have to give anything run in background permissions... also, it won't have access to other apps, so it can't really track you.
The bigger issue with Desktop linux is very few people run it, and targeting a specific subset for linux as separate from other platforms is difficult and costly, to say the least.
I recently switched to desktop GNU/Linux full time outside of work, and I have to say it's really damn good now.
Mind you, I'm using a Lenovo laptop, so it's among the best supported hardware you can buy for the purpose. But the fact that there aren't more boutique computer makers selling GNU/Linux systems installed by default is an interesting statement on the industry.
I'm sure ultimately it comes down to the availability of software like Microsoft Word, but ironically having so much stuff move to the cloud is a boon in this case. With so many web-based apps available, nontechnical people can switch from Windows to a well-configured GNU/Linux system and not notice much of a difference.
With that problem out of the way, a hypothetical hardware vendor can focus on building sane defaults, a good user experience, and good documentation (good for users, not developers). Then if and when it works out and marketshare ends up in double digits, more non-web software will start to become available anyway, and/or a lot more corporate money could start flowing into established projects like LibreOffice.
Obviously the Chromebook was a thing, and you can buy System76 machines today, but the former was too extreme and the latter is probably too expensive for grandma just checking her email.
I assume the reason it doesn't exist it is because the logistics and economics of the hardware don't work out. But I wonder if it will become feasible some time in the near future.
Beyond that, with flatpak and wasm application sandboxes, it will only get better. Wasm, provided some UI primitives and OS-like primitives get baked in, will give a common runtime for UI apps everywhere without a full browser. WASM+Canvas or WASM+WebGL can/will go a LONG way.
I would say, that enough OS primitives should be present so that as an example SQLite3 can compile and run, and you can get a compatible file out the other end.
> Can you distribute a native application on macOS without Apple's blessing? No, you can't
Yes, you can. You have always been able to.
> (not when Catalina will be out anyway).
Yes, you will be able to.
I just downloaded a music tracker/MOD player from the Mesozoic (well, not quite) and it runs fine on Catalina Developer Preview 4.
I can understand the confusion – I had the same concerns while watching this year's WWDC's Platforms State of the Union – but please do not spread FUD, or accept it as true without credible sources.
Apple does require developers to update their old apps now and then, and that may not be convenient for some devs, but I feel it's overall good for users, and they don't force anyone to distribute via the App Store only or give Apple a % of their sales.
In fact, a few companies have withdrawn their products from the Mac App Store, like Sketch and Coda and others.
I don't see it this way at all. Browser vendors have been very reluctant to accept that they're now supposed to provide a real application development platform.
It's businesses that demand web applications, because native deployment (in-house or for customers) is a tougher sell. A lot of it has to do with the bad security model of desktop operating systems combined with the overhead of administration.
Last but not least, web developers are the biggest pool to hire from. It all adds up to where the benefits outweigh the (significant!) drawbacks.
"...Last but not least, web developers are the biggest pool to hire from..."
For boiler plate business web apps sure. And while those are probably being prevalent the world does not stop there.
Companies are running webapps on embedded devices now, but I don't buy the ease of hiring excuse. Web devs demand higher salaries than embedded developers and they have more leverage in terms of where they can work (ie: they're flaky as pie crust). Embedded developers are also more likely to pass the hazing ritual known as the programming interview. Where's the upside to hiring web developers in that context?
"Companies are running webapps on embedded devices now" - sure my router and some of my own private hardware have web interfaces. It is however just a tiny bit of their functionality. The rest leaves happily as native code.
I think it's a mixed bag... a lot of developers think they know JavaScript or understand web applications. I've found that about 90% are not very good with it in practice. Often with job titles as Mid or Sr developers.
Actually understanding more about JS and the browser, and actual application development, and how it fits are good places to start. I find that the browser model actually fits a redux-like master state machine better than MV* that a lot of experienced developers, but inexperienced web app developers tend to focus on.
It just depends. I think there's room for most players, and IU do think WASM offers a LOT or will as runtimes and standard libraries shake out. I'm looking forward to seeing things develop more... IMHO there should be a focus to standardize interfaces for Canvas, WebGL, Audio and FS first. When you can run an application against canvas 2d or webgl with audio and sqlite, I think that's a large way there. Better input support (controllers as well as kb/mouse) is also pretty high. I know people are working on these things.
Getting something that runs almost everywhere will be very nice and although there's some overlap with the intent of the JVM, WASM has more primitive options (for the good) and can support a greater range of sources to a single target set of interfaces.
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.
Can someone explain a concrete use case for web assembly? Are there projects out there using web assembly in production? What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?
I think it's more a case of wasm being a more natural target for compilers, meaning you can write or port applications in other languages to the web without the much-worse performance (and size) implications of compiling to interpreted javascript.
Figma (https://www.figma.com/) is a design tool that runs in the browser and makes heavy use of WASM. It's definitely slower than using a native app like Sketch, but not slow enough to be completely impractical. A few design people I work with here in India have switched to Figma from Sketch, and they seem very pleased with the results.
I can see WASM becoming useful for enabling apps that do real-time audio/video/image processing in the browser. Games are another obvious use case.
Maybe one day I'll be able to run an Ableton-lite right in the browser.
In addition to the examples given, I offer the opinion that using the same language for front- and backend is nice. I currently achieve this with JS, but it would be nice to be able to do the same with, say, Rust.
> Are there projects out there using web assembly in production?
pspdfkit, unity, google earth, and figma spring to mind. Obviously more stuff is using it, but it isn't like there's a big index of sites using wasm.
> What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?
Wasm and JS can achieve equal performance in modern browser engines (and note that in engines like v8, there are operations that can be reduced such that they compete with output from gcc and clang). The thing that wasm is designed to do is make that performance predictable. Optimizing JS requires a lot of guesswork which can end up incorrect, while wasm doesn't require any guesswork because it is strongly typed and uses a regular bytecode. Right now what is holding wasm back is coming up with all the best ways to reduce it to the machine code of the specific platform, and ways to reduce the performance hits of security checks wasm has. For example, v8 recently sped up wasm memory access by ~30% by getting rid of bounds checks and using mmap + sigsegv to detect out of bounds access.
Slower at an average of 50% looks acceptable to me for many applications.
However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction.
Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary builds). So, this seems to be interesting to (primarily) web applications. However, I try to avoid web apps, because they are typically proprietary, a moving target, the owner can randomly decide to charge me for things, or (ab)use my data, and they feel non-native.
(I do see the benefit for people who use web apps, since WebAssembly is typically faster than Javascript and opens up web app programming to more languages.)
People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.
Lol. Well, I mean nothing is outside of the realm of possibility, but remember those native Java chips! Some thought those were going to be a big win. And then you had companies like Transmeta trying to do the exact opposite - interpretively optimize all the things....or something like that.
Ultimately the features involved in optimizing WebAssembly are even more variable than they are for Java, so a Jazelle approach is probably even less useful.
That was right before the Power Wall became an obstacle and CPUs were already burning up. Transmeta in a sense invented low power computing but then Intel said thank you very much; we'll take it from here. It wasn't that they didn't deliver. It's just that they were competing against Intel in the x86 space. A lot of the Transmeta team moved to nVidia and work on Denver but that's different and they got an architecture license from ARM to do that.
A long time ago they were talking about Java chips. That didn’t materialize and as far as I know there are no chips that run JavaScript natively so I wouldn’t hold my breath for WebAssembly chips.
The Java chips were for, well, they were for Java. If ARM had designed Jazelle to be more general, it would have been useful for Javascript and Python and .... But they designed it for Java bytecode. The licensing was too expensive and so it didn't catch on and Jazelle got dropped from ARMv8.
I don't know you are being downvoted. There are already instructions in ARM chips to help with JS floating-point conversion [1]. Yes, while the "Java chips" never got into the mass market[2], JS and it's ecosystem is eatting the world in a way Java never did and the trajectory is only increaing.
P.S. I know WASM isn't JS, but I'd still consider it in the JS ecosystem.
The point is obviously that web apps can be directly competitive with binaries, sans the same level of security, given they operate a lite version of the application. This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.
This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.
Yes. But my question is why would I want this? I won't own the software anymore. The web has shown over and over again to have far less privacy. The vendor could disappear, change their terms, change their fees any time. As a customer/user you become basically powerless.
And for non-cloud applications: what's the point. My distribution already compiles and provides most of the software that I need and my machine doesn't need to waste time/energy on JITing.
> The web has shown over and over again to have far less privacy
This may be inherent to the web but a native app would (given the current level of sandboxing) have more freedom to make http requests than a webapp. So there would be no win in forcing the bad actors to make native apps.
The argument about owning the software is a valid one, and I for one am not terribly excited about the continuous updates to everything which sometimes changes the UI of a tool that I use and know and cost me time out of the blue. However, I am using wallabyjs, a "native" app (plugin to vscode) and it updates itself practically every other day. I think that reality is hitting all kinds of software anyway.
As I understand it, WASM binaries have a well defined interface and can easily be sandboxed.
Perhaps there would then be a way to just download WASM binaries from the web and run them locally, with your own sandbox restrictions imposed on them.
I think the ability to sandbox these applications (even if they're not delivered over the web) might actually be the more valuable aspect of WASM.
> Slower at an average of 50% looks acceptable to me for many applications.
Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..
Native device platforms could do a system optimized AOT compile of WASM to Native as part of install. The distribution can be the same per platform, that doesn't stop a given platform from further optimization.
Also, the single biggest battery use for most people is the screen, the CPU time is minimal by comparison and that 50% is only for the narrow CPU time the app isn't just waiting for input, and for many apps, that's most of the time (idle).
sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows)
and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative.
in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that.
several apps run only on windows. some on mac and windows, some others on mac and linux. occasionally there is a mac or linux only application. and once in a while an application binary is available on all three.
this is not even an issue of portability. even if the application is easily portable, i still depend on the developers choice of which OS they support. and i can't blame them. unless i am going to make money off the application i am not going to bother with supporting windows or macos. and most others will continue to ignore linux because the smaller market is still not always worth the effort.
with webassembly we finally get a unified binary architecture.
if an application run on webassembly, then the OS no longer matters. as someone that prefers to use linux. webassembly is like the holy grail. because if it manages to take hold, then hopefully the days of needing windows or a mac will be gone.
> sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows)
Is that really a big deal, though? From what I understand (and I could be wrong, so correct me if I am), most of the headaches involved in multi-platform development is the OS specific UI. Video games, for example, don't find porting to multiple architectures all that challenging because 1) they design for it and 2) they're not expected to adhere to OS UI guidelines.
Games are also expected to be battery pigs, so doing 60+ FPS GPU rendering instead of however native UIs are rendered helps. Everyone certainly COULD just write their apps as 2d OpenGL but laptop battery life would suffer for it.
It really depends on how complex your code is and what you're targeting. For example, the V8 JavaScript engine has a ton of ifdefs depending on OS (Windows, Mac, Linux, Fushia), bitness (32 or 64), chipset (ARM, ARM64, PPC, x64, etc.) and combinations thereof. For example, see some of the defines in https://github.com/v8/v8/blob/master/src/common/globals.h#L1... and their uses throughout the codebase.
at this point it is mostly a problem of perception, and apparent complexity.
portability is not the problem, but you still need to learn how to package for each different system, you have to maintain at least 3 sets of build-to-package instructions and understand each ecosystem.
for example, i only develop on linux. yet, packaging for all linux distributions is still a hurdle. why can't i just compile and upload to my website?
i have never packaged for windows or mac, and the thought having to learn those alone makes me turn away in disgust. i am probably wrong, and packaging for both is way easier than i think. but that's exactly the point of the problem being based on perception and apparent complexity.
in order to package for all three systems, i need to first of all want to do that. and i find that i don't care enough to want it.
Exactly this... I use all three as well, and tend to favor apps that run everywhere. Even if that means browser/electron apps. It's just less hassle for me. My single biggest issue is windows-isms for bash on windows.
In the end, as long as it works, I'm very happy. Also, it doesn't preclude a given platform from AOT optimization/compile for WASM code to platform native code. I think getting common runtime interfaces is currently the paramount point... being able to use sqlite, and SDL/OpenGL adapters to canvas or webgl are also big. Not to mention audio, and various input devices (gamepads etc).
There is a lot of existing code that could be readily ported/shimmed out if we can get some common interfaces working.
FWIW: in my 8-bit emulators I'm closer to the 10% performance difference for code compiled in clang with -O3 (the native version uses latest Xcode's clang, the WASM the latest LLVM WASM backend via emscripten):
The time in the top-right is the time spent per frame in the emulator, in the WASM version that's somewhere around 2.5 to 2.8ms on my laptop.
The native version is somewhere between 2.0 and 2.2ms.
From my experiments, it's quite easy to accidentally hit a "slow path" on the WASM side, for instance registers are spilling earlier (AFAIK because WASM has one or two registers set aside). Things are getting better though. About a year ago, the same emulator code seemed to have triggered some specific slow-path and the WASM version was nearly 4x slower.
Of course it's always possible to put more time into optimizing the native version of a piece of code when targeting a specific compiler version, compiler-specific intrinsics and a specific CPU model. This is where WASM will always lag behind, with a portable ISA you'll always hit a wall where further optimization simply isn't possible.
So from my experience: somewhere between 10% slower and 3x slower is all within the "expected" range, the more important part is that performance is predictable for a given piece of code compiled with a given compiler version (e.g. you won't have the GC come in and do its thing for a few hundred milliseconds). And at least the emscripten team is very responsive and interested in such pathological cases.
Please actually read the paper. As usual, the mean is a poor approximation of a distribution. This paper states repeatedly that it was able to reproduce the experimental results from the 2017 PLDI paper, which primarily used PolyBenchC as the suite. My team wrote that paper. We didn't cherry pick.
The issue is mostly that we suck more on Spec2k6 than we realized. Since publishing that paper we do track Spec2k6 internally but we don't spend time tuning for it.
Thank you for the clarification. Some questions related to V8 perf:
1. WASM <--> JS/Host calls seem to have a higher cost on chrome than FF [1][2]. Is that in your optimization roadmap?
2. Wasmer tracks V8 perf against other backbends, and the LLVM backend consistently outperforms V8 [3]. Can anything be done to address this, especially for node, where the compile time cost of a super optimizing compiler might be beneficial in certain applications?
Are you looking into some of the issues raised in the paper? Better use of register-memory instructions seems like it might be a relatively big win for relatively little effort.
The code in lines 35-37 in Figure 7(c) looks like you should be able to fold the memory operand even in a simple peephole pass before register allocation, no? (I know, I know, patches are probably welcome ;-))
The article claims that this is a revelation, but I’ve been hearing for at least one year already that webassembly comes at best around half the speed of native.
10% slower is actually not that bad, when compared to the safety and portability not given by C/C++. Past 10% performance parity is the stuff of performance optimization challenges; we may have to accept that.
We're all putting up with regular 10% drops in our CPU performance because intel was stupid about alot of things; maybe we could give 10% up for common applications (let's face it, most aren't CPU-bound) having more safety.
Of course, I don't know if wasm is the answer. Jury's still out for whether it's great in native or not; honestly, GUI is still the issue.
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. 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 installation needed. No polluting your home directory. No registry entries. It's sandboxed, you're never giving the app permissions that you don't intend. A service worker can be used to make the app available offline. My dear grandmother could use this without confusion. My dad can use these apps and feel confident he's not not infesting himself with malware or bundled software.
The complaints about "the web doesn't feel native!" and "it's less secure!" and "it's just as easy to ship a native app [for my platform of choice]!" are tired arguments. We've finally got a simple way to distribute apps fully cross platform in a way that CAN respect privacy and guarantees a reasonable level of security. And, it's pretty darn fast.
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 most cases they will just be denied). Once resources are acquired, we use unforgable handles to refer to them. It is a super cool and declarative way to make sure people know exactly what a wasm bin will try to access before it's even run.
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 applications and library into the browser. I'm excited to see what people do with WASI, but its not clear to me what a program designed from the ground up around capabilities would look like!
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.
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)
> Literally everything you said except the part about using the language you want has been true of Java for at least a decade. Everything old is new again.
"Literally everything you said except the part about inflatable tires has been true of wooden wheels for at least 3000 years. Everything old is new again."
Sometimes, reinventing the wheel actually makes sense.
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.
ChromeOS and Android also have good looking interfaces.
> None of them have anything to do with lack of skill using Swing.
Can you name me 10 swing apps that look good? I can do the same for the web and MacOS. I'm not sure I'd be able to name 10 for windows, but I can name at least two.
> A random picked number to somehow win Internet discussion points I guess.
No need to be nasty. I chose 10 at random because it's a decent sample size without being too onerous for an online discussion. If I wanted to earn internet discussion points, I would have made it 10,000.
I'll take a look at those and get back to you. I'm very curious. Unlike some commenters (not a jab at any particular person or even a particular site, just a general observation of commenters online), I like it when I'm proven wrong about something. I'd rather know than live in ignorance.
Java... Are you kidding. The UI stack and distribution model is horrible compared to WebAssembly.
The resources available for HTML/CSS cannot be compared with JavaFX, Swing or whatever the other original stack was. And the Applets sandboxing was obviously so horrible everyone killed it. WA is amazing here copying the existing and already hardened JavaScript model.
But in that case we already have all that with Electron. Unless you want to program in C/C++ or Rust, compiling your language to JS would probably result in an image that's both smaller (because you won't need to bring your own GC) and faster (because you'll be enjoying JS's JIT) than WASM.
JS is a better compilation target (you don't have to use JS directly) than WASM for the vast majority of languages. WASM is great for when you have a bit of code you'd like to write in C and use as a library from JS (or a language compiled to JS).
Yeah valid point. I am quite comfortable with HTML but only tolerate JS with heavy use of TypeScript. For me C# and Blazor sound quite cool. The size is my biggest concern as well.
What a joke, where are the visual designers for HTML/CSS, with automatic binding generation for database backends?
Layout engines with customization capabilities?
Where is the hardware accelerated drawings that I can be fully sure it is hardware accelerated without doing tricks with z index and hoping for the best regarding mapping css drawings into textures?
> What a joke, where are the visual designers for HTML/CSS, with automatic binding generation for database backends?
Did you ever actually use a PowerBuilder (or similar RAD tool) application? The experience was horrible, slow, and basically a waste of titanic amounts of money.
I once saw half an accounting department quit after a switch to a RAD financials package.
There’s a reason all those 1990-2005 era vertical-market app companies got bought by PE firms and are just basically dead except for milking maintenance revenue. Building “data-model centric” apps with RAD tools optimizes for ease of the developer instead of the end user. Which is exactly backwards.
Yes, for Delphi, C++ Builder, Forms, WPF/UWP, QML, iOS, Android, Symbian.
Parallel to that I have been doing Web projects since 2000 as well.
HTML 5 / CSS 3 has nothing that compares, that is why Flash took off and is coming back in the form of WebAssembly, now with everyone racing to support it with their favourite runtime + WebGL.
I have used many. PowerBuilder is absolutely atrocious. Delphi is brilliant and there is a whole range in between. I do not mind creating GUI in code either for applications that work with GPU but would still prefer Delphi like environment,
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.
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?
It depends on when, and how much adoption it has. If the iPhone stopped supporting HTML, it would kill the iPhone, and your guess is as good as mine about how wide of adoption wasm needs before it hits that threshold.
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.
An arbitrary decision made by the manufacturer of the phones of customers with the largest discretionary spending budget.
I recall there being an article about how despite the fact that iPhones are 10% of the market, they represented 50% of the profits for application developers.
The difference is that the runtime lives in the browser, based on an open standard. Operating systems come with browsers. The success of WASM is that my mom doesn't need to know how to install Java (and maybe accidentally a Yahoo toolbar) to run an app to look at her DICOM images.
> The difference is that the runtime lives in the browser, based on an open standard.
Java is an open standard (I think, I didn't fact check this thuroughly) OpenJDK is the reference implementation of that standard. You can try to claim that in reality Oracle has a lot of control, but I'd come right back and say that Google basically controls the browser.
> The success of WASM is that my mom doesn't need to know how to install Java
If OSs had bundled a Java runtime she wouldn't need to install Java either.
I appreciate the arguments but they do still rely on _using_ a JVM language _and_ shipping an additional runtime (since browsers are already on all devices in question here). Those are two reasons (in addition to Oracle, which as much hate as Google gets I'd bet people would still take them over Oracle) people are excited about WASM.
Sure, list clicker apps can ve distributed in such a manner.
On the other hand, I still have no way of distributing my system services easily in a cross-platform way.
Say, I have a service that is triggered when RC45 is jacked in or when a passive scan on a wifi device is completed. I still have to package it for android, ios, osx, linux (rpm, deb, aur) and windows separately.
This is to the point. Adding one thing: the availability of a standardized UI stack. WebAssembly vs a docker container is not that different on a server, but the described client is the differentiator to all competitor. The only real contender QT with C++ is quite a tough and insecure (and ugly) package in comparison.
> 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.
No, you might be thinking about something like Electron. There are WASM VM’s for many platforms and they are very simple and do not involve a web browser. Whether they have a good common ui library is of course a different question, but one that will be resolved in due course.
Web browsers are where it starts but we're getting native WASM runtime/containers that can just start a program from the disk. The browser then just becomes a shell around it with the ability to find a binary over a URL rather than locally, along with some other web-related features.
It doesn't need to improve the security or privacy. It's the same. But it lets you write in any language that can compile to LLVM IR, and it's fast. Which means that many applications which were previously impractical in vanilla JavaScript are now possible.
Sandboxing is the most underrated browser feature ever. I prefer webapps before any native app just because of the sandboxing. A native app has uncontrolled access to everything on my system (in a usual end user install). Good luck to a browser app that tries to access My Documents or My Pictures.
If anything this paper is unfair to the native compiler; they compare V8 and SpiderMonkey from April 2019 to a clang release from March 2017, and they turn off autovectorization. That being said, most of the slowdowns they identify seem to be deficiencies in the WASM engines rather than fundamental problems with WASM itself.
How much of this performance gap is due to the inherent limitations of the WebAssembly technology, and how much is due to it being relatively new?
I.e., do we expect to see performance improvements similar to what we've seen in JavaScript over the last two decades? Or are we going to need better hardware to realize better performance?
> It is worth asking if the performance issues identified hereare fundamental. We believe that two of the identified issues are not: that is, they could be ameliorated by improved implementations. WebAssembly implementations today useregister allocators (§6.1.2) and code generators (§6.2.1) thatperform worse than Clang’s counterparts. However, an offlinecompiler like Clang can spend considerably more time togenerate better code, whereas WebAssembly compilers mustbe fast enough to run online. Therefore, solutions adoptedby other JITs, such as further optimizing hot code, are likely applicable here.
> The four other issues that we have identified appear to arise from the design constraints of WebAssembly: the stackoverflow checks (§6.2.2), indirect call checks (§6.2.3), andreserved registers (§6.1.1) have a runtime cost and lead to in-creased code size (§6.3). Unfortunately, these checks are nec-essary for WebAssembly’s safety guarantees. A redesigned WebAssembly, with richer types for memory and function pointers [23], might be able to perform some of these checksat compile time, but that could complicate the implementation of compilers that produce WebAssembly. Finally, a Web-Assembly implementation in a browser must interoperate witha high-performance JavaScript implementation, which mayimpose its own constraints. For example, current JavaScript implementations reserve a few registers for their own use,which increases register pressure on WebAssembly.
> A redesigned WebAssembly, with richer types for memory and function pointers [23], might be able to perform some of these checks at compile time, but that could complicate the implementation of compilers that produce WebAssembly.
Great info, thanks for sharing! So, to summarize:
Performance will get a bit better for WebAssembly 1.0, but we'll need a WebAssembly 2.0 (for lack of a better term) to realize major performance improvements. And/Or we'll need advancements in JIT technology.
Beyond that, there will always be some limitations because of the Javascript interop requirements.
And, as other threads here have pointed out... maybe who cares? It's still pretty fast!
It 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-64 processors and would solve the issue.
Once this is changed, the only remaining fundamental unfixable differences would be reduced cache efficiency from the extra bytes for the segment override, and the need to reserve an extra register for the wasm stack pointer.
However, running WebAssembly code in a separate address space would allow to run arbitrary code, although this would have the drawback of higher memory usage and IPC slowdown.
Is there any article discussing the rationale between Firefox and Chrome's current approach and whether they plan to use either segment overrides or process isolation?
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).
I 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.
211 comments
[ 0.13 ms ] story [ 132 ms ] threadhttps://github.com/martinjackson/electron-run-shell-example
https://github.com/anderejd/electron-wasm-rust-example
TBH though my big hope for web assembly has nothing to do with the web at all, but as a distribution format for drivers that can be installed on any cpu arch/kernel. Finally, my dream of BSD on risc-v is achieved! ....or more likely, just running linux on arm.
That said I don't see the point of writing drivers in webassembly. If you want better security for drivers, there are better endeavors like microkernel architectures which Linux still isn't using.
A different way of phrasing this would be "would you prefer a driver that uses 2% of your cpu vs no driver at all? Note that if the hypothetical non-existent driver was written in c, it would only take 1% of your cpu"
> Why?
Because the alternative for many alternative OSes is no driver at all.
> How is that beneficial to anyone except the person packaging the driver?
Because if it's more convenient for the packager, then there's a better chance that they'll package a driver that way, which means I'm more likely to actually get the driver in the first place.
[0] IRQL exception was at least the leading cause when I was a Core OS developer for Windows.
But python is a high level script language with gc. WebAssembly is very lowlevel, so the people who could and would write in python will not write in wasm and also not in C.
Wasm is still awesome, it is just not, what many hope it will be. And a distribution format for drivers? Well, I am not a low level expert, but that seems very unlikely to work out, from what I understand.
That's what Webassembly enables today: You can use C/C++, Rust, Go and several others. Of course the ecosystem is not as mature. Languages with a big runtimes aren't good candidates for lean web apps. Performance isn't the dealbreaker though.
Certainly. It also makes sense, as programmers time is usually worth much more than computing time.
> [security] checks are necessary for WebAssembly’s safety
> current JavaScript implementations reserve a few registers for their own use, which increases register pressure on WebAssembly
(Some occasional runtime checks would nonetheless be needed, since safety against e.g. excessive stack use could depend on what the program is doing at runtime; but they would be quite rare and come with very little overhead.)
https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
> One of these speedups is streaming compilation, where the browser compiles the code while the code is still being downloaded. Up until now, this was just a potential future speedup. But with the release of Firefox 58 next week, it becomes a reality.
> Firefox 58 also includes a new 2-tiered compiler. The new baseline compiler compiles code 10–15 times faster than the optimizing compiler.
Seems to deal with the "whereas WebAssembly compilers must be fast enough to run online"
This echoes the arguments for / against java. The compiler in this context mustn’t be “fast enough to be online” - it must be fast enough to keep up and able to smart enough to know what’s important. It also benefits from watching the actual program execution. Presuming you can “warm up” the application, it might just do fine.
I vaguely think that a lot of people are considering the compilation as a one time deal. It could be a phased thing. Java’s a great example of that.
Regardless of is this a trap or not, it's obvious to me that developers want simplicity and consistency. WA provides both so don't wonder why it's taking off.
> So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas
I let the compilers worry about this :)
But there probably always will be a safe flag that generates everywhere running binaries.
Hopefully in 20 years, when people are talking about MetaWebAssembly to abstract away the platforms that run on WASM, you'll have a different perspective on what you've said here.
But then, this is what humans have been doing since we figured out stone flints.
I was involved with Java applets when Java was in beta and one of the most annoying things was that JDK 1.0 did not come with serialization.
I would build applets that displayed content generated on the server and serialization-deserialization code could be 2/3 of the program. Most people had a slow net back then, so the download performance was a big deal.
JDK 1.1 put serialization in right away, but Netscape had already introduced it's own incompatible serializer, and there were delays in getting JDK 1.1, plus people didn't like Java serialization -- practically there was a year or two where you couldn't use it.
Applets had enough teething pains that people quickly came to the conclusion that they weren't worth the trouble, then Flash came along which came closer to what people wanted at the time.
Especially since so much of the internet was once on Flash and we're looking at the loss of historical archives.
I think win is having free software or at least opensource apps that are trusted by distributors and easy to analyze/modify, and actually own (meaning have on your harddrive and fully control). And we already have that win.
There's a big difference between an imperative (e.g. arbitrary code) and declarative installation process. Imperative installation is most common on Windows due to the initial decisions made by the registry designers + the Windows Installer originating from Office and starting with imperative. Declarative installs are common on the Mac where "installation" usually means dragging a binary from the DMG to your Applications folder. OS X then manages OS integrations declared in an app manifiest.
Declarative installations delegate to a system which has a broader view and standard mechanisms to handle state transitions required for installs, upgrades, and uninstalls. Imperative installations frequently leave residue and are hard for even Windows to fix. I spent years of research and have several patents on trying to figure out how to distinguish between "extension points" of the OS and private state to create a sandbox with the necessary pinholes. Even with those tools handy, many software shops see no reason to upgrade because the Windows end user accepts a life of installers.
I see logic in starting from scratch. This time we can create an end user expectation of declarative and (laterally + vertically) sandboxed apps. Hell, that's what we tried to do with Windows 8, but it was unfortunately restricted to the "modern" (aka full screen) apps that never caught on.
It's still sandboxed, and limited, so what's cached this way is perhaps easy to totally remove by the browser. But that's not because of the declarativeness, but because of sandboxing.
sure, linux is doing that much better, but until we get linux (homebrew for windows?) installers for windows, i'll prefer webassembly, at least for casual use.
Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-technical curating mechanism which has all sorts of conflicts-of-interests of what's morally acceptable and what's not, WASM is the next best thing to an open, yet secure, platform.
Desktop Linux aside, the web is currently the only open platform for distributing software outside of the interests of a single "platform owner". Google may close this "loop hole" soon, so I'm not too optimistic for the future, but today, that's what it is.
I've been running the Catalina betas, and running non-notarized apps only requires right clicking instead of double clicking. If that's too much of an obstacle for you, you probably shouldn't run the app.
Gatekeeper on macOS is a technology designed to protect careless users. It makes it slightly harder to shoot yourself in the foot. It doesn't prevent you from doing it, though.
Thing is, "safe" OS-sandboxes are not safe; "local" privilege escalation vulnerabilities are still pervasive. Until OS's are safe enough that I can run `sudo -u nobody untrusted_binary` and not even think about the possibility of it taking over my system, something like the WASM sandbox (perhaps extended with WASI and other optional mechanisms) will always be needed.
Why is everybody so insistent on running untrusted code?
Yes you can:
https://forums.macrumors.com/threads/unsigned-apps-catalyst-...
WASM is the next best thing to an open, yet secure, platform.
So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)
Desktop Linux aside
Maybe we should make Linux an acceptable platform for more people rather than optimizing for proprietary web applications that you don't even own a copy of anymore.
Won't ever happen for two reasons: 1) The Linux Desktop community would have to admit that there are better ways to do things, and 2) They'd have to agree on what those things are. 20 years of Linux Desktop history show these things to be impossible.
Theoretically, a new community could spring up and put a new userland on top of the Linux kernel, like Android did, but it would seem like the people who have the interest in doing such a thing (like myself) lack enough time, talent, and/or ability to organize sufficiently to pull it off. Not to mention that we'd all have to agree too.
Have you taken a look around Casey Muratori's handmade.network? Or interacted much with the guys who watch Jonathan Blow's livestreams? They make much the same point you do about taking the linux kernel and creating a new userland around it.
Anyone who's interested in working on something like this, email walkinginalinuxuserland@lj3.me. The least we could all do is keep in touch, right?
I also think a forum or IRC channel would be more appropriate, but email is a start and I appreciate you taking the initiative.
See also Probono's Hello[0], but I'm not sure he hasn't decided that Haiku already fits for him.
[0] https://github.com/probonopd/hello
Something like Redox(1). It's even MIT licensed, so you could include it in a commercial distribution with your own changes if you so chose when you made your gui.
1. https://www.redox-os.org
and sandboxed. yes, this is way forward.
I don't think that is the case. Simply because a WASM application will have to request the permissions it needs up front (assuming a sane runtime) and you don't have to give anything run in background permissions... also, it won't have access to other apps, so it can't really track you.
The bigger issue with Desktop linux is very few people run it, and targeting a specific subset for linux as separate from other platforms is difficult and costly, to say the least.
Mind you, I'm using a Lenovo laptop, so it's among the best supported hardware you can buy for the purpose. But the fact that there aren't more boutique computer makers selling GNU/Linux systems installed by default is an interesting statement on the industry.
I'm sure ultimately it comes down to the availability of software like Microsoft Word, but ironically having so much stuff move to the cloud is a boon in this case. With so many web-based apps available, nontechnical people can switch from Windows to a well-configured GNU/Linux system and not notice much of a difference.
With that problem out of the way, a hypothetical hardware vendor can focus on building sane defaults, a good user experience, and good documentation (good for users, not developers). Then if and when it works out and marketshare ends up in double digits, more non-web software will start to become available anyway, and/or a lot more corporate money could start flowing into established projects like LibreOffice.
Obviously the Chromebook was a thing, and you can buy System76 machines today, but the former was too extreme and the latter is probably too expensive for grandma just checking her email.
I assume the reason it doesn't exist it is because the logistics and economics of the hardware don't work out. But I wonder if it will become feasible some time in the near future.
I would say, that enough OS primitives should be present so that as an example SQLite3 can compile and run, and you can get a compatible file out the other end.
Yes, you can. You have always been able to.
> (not when Catalina will be out anyway).
Yes, you will be able to.
I just downloaded a music tracker/MOD player from the Mesozoic (well, not quite) and it runs fine on Catalina Developer Preview 4.
I can understand the confusion – I had the same concerns while watching this year's WWDC's Platforms State of the Union – but please do not spread FUD, or accept it as true without credible sources.
Apple does require developers to update their old apps now and then, and that may not be convenient for some devs, but I feel it's overall good for users, and they don't force anyone to distribute via the App Store only or give Apple a % of their sales.
In fact, a few companies have withdrawn their products from the Mac App Store, like Sketch and Coda and others.
It's businesses that demand web applications, because native deployment (in-house or for customers) is a tougher sell. A lot of it has to do with the bad security model of desktop operating systems combined with the overhead of administration.
Last but not least, web developers are the biggest pool to hire from. It all adds up to where the benefits outweigh the (significant!) drawbacks.
Actually understanding more about JS and the browser, and actual application development, and how it fits are good places to start. I find that the browser model actually fits a redux-like master state machine better than MV* that a lot of experienced developers, but inexperienced web app developers tend to focus on.
It just depends. I think there's room for most players, and IU do think WASM offers a LOT or will as runtimes and standard libraries shake out. I'm looking forward to seeing things develop more... IMHO there should be a focus to standardize interfaces for Canvas, WebGL, Audio and FS first. When you can run an application against canvas 2d or webgl with audio and sqlite, I think that's a large way there. Better input support (controllers as well as kb/mouse) is also pretty high. I know people are working on these things.
Getting something that runs almost everywhere will be very nice and although there's some overlap with the intent of the JVM, WASM has more primitive options (for the good) and can support a greater range of sources to a single target set of interfaces.
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.
That was java's claim (but not the reality), what's the slowdown there?
That is except startup time.
Not all of these will boot, but most will. https://archive.org/details/softwarelibrary & https://archive.org/details/internetarcade
I can see WASM becoming useful for enabling apps that do real-time audio/video/image processing in the browser. Games are another obvious use case.
Maybe one day I'll be able to run an Ableton-lite right in the browser.
pspdfkit, unity, google earth, and figma spring to mind. Obviously more stuff is using it, but it isn't like there's a big index of sites using wasm.
> What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?
Wasm and JS can achieve equal performance in modern browser engines (and note that in engines like v8, there are operations that can be reduced such that they compete with output from gcc and clang). The thing that wasm is designed to do is make that performance predictable. Optimizing JS requires a lot of guesswork which can end up incorrect, while wasm doesn't require any guesswork because it is strongly typed and uses a regular bytecode. Right now what is holding wasm back is coming up with all the best ways to reduce it to the machine code of the specific platform, and ways to reduce the performance hits of security checks wasm has. For example, v8 recently sped up wasm memory access by ~30% by getting rid of bounds checks and using mmap + sigsegv to detect out of bounds access.
However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction.
Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary builds). So, this seems to be interesting to (primarily) web applications. However, I try to avoid web apps, because they are typically proprietary, a moving target, the owner can randomly decide to charge me for things, or (ab)use my data, and they feel non-native.
(I do see the benefit for people who use web apps, since WebAssembly is typically faster than Javascript and opens up web app programming to more languages.)
That was right before the Power Wall became an obstacle and CPUs were already burning up. Transmeta in a sense invented low power computing but then Intel said thank you very much; we'll take it from here. It wasn't that they didn't deliver. It's just that they were competing against Intel in the x86 space. A lot of the Transmeta team moved to nVidia and work on Denver but that's different and they got an architecture license from ARM to do that.
P.S. I know WASM isn't JS, but I'd still consider it in the JS ecosystem.
[1]: https://stackoverflow.com/questions/50966676/why-do-arm-chip...
[2]: I did hear about some "Java Chips" for garbage collection back in the day.
Yes. But my question is why would I want this? I won't own the software anymore. The web has shown over and over again to have far less privacy. The vendor could disappear, change their terms, change their fees any time. As a customer/user you become basically powerless.
And for non-cloud applications: what's the point. My distribution already compiles and provides most of the software that I need and my machine doesn't need to waste time/energy on JITing.
This may be inherent to the web but a native app would (given the current level of sandboxing) have more freedom to make http requests than a webapp. So there would be no win in forcing the bad actors to make native apps.
The argument about owning the software is a valid one, and I for one am not terribly excited about the continuous updates to everything which sometimes changes the UI of a tool that I use and know and cost me time out of the blue. However, I am using wallabyjs, a "native" app (plugin to vscode) and it updates itself practically every other day. I think that reality is hitting all kinds of software anyway.
Perhaps there would then be a way to just download WASM binaries from the web and run them locally, with your own sandbox restrictions imposed on them.
I think the ability to sandbox these applications (even if they're not delivered over the web) might actually be the more valuable aspect of WASM.
Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..
Also, the single biggest battery use for most people is the screen, the CPU time is minimal by comparison and that 50% is only for the narrow CPU time the app isn't just waiting for input, and for many apps, that's most of the time (idle).
and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative.
in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that.
several apps run only on windows. some on mac and windows, some others on mac and linux. occasionally there is a mac or linux only application. and once in a while an application binary is available on all three.
this is not even an issue of portability. even if the application is easily portable, i still depend on the developers choice of which OS they support. and i can't blame them. unless i am going to make money off the application i am not going to bother with supporting windows or macos. and most others will continue to ignore linux because the smaller market is still not always worth the effort.
with webassembly we finally get a unified binary architecture.
if an application run on webassembly, then the OS no longer matters. as someone that prefers to use linux. webassembly is like the holy grail. because if it manages to take hold, then hopefully the days of needing windows or a mac will be gone.
that's the point.
Is that really a big deal, though? From what I understand (and I could be wrong, so correct me if I am), most of the headaches involved in multi-platform development is the OS specific UI. Video games, for example, don't find porting to multiple architectures all that challenging because 1) they design for it and 2) they're not expected to adhere to OS UI guidelines.
EDIT: I forgot Android, and all the compiler specific flags. (https://github.com/v8/v8/blob/master/include/v8config.h is probably a better reference).
portability is not the problem, but you still need to learn how to package for each different system, you have to maintain at least 3 sets of build-to-package instructions and understand each ecosystem.
for example, i only develop on linux. yet, packaging for all linux distributions is still a hurdle. why can't i just compile and upload to my website?
i have never packaged for windows or mac, and the thought having to learn those alone makes me turn away in disgust. i am probably wrong, and packaging for both is way easier than i think. but that's exactly the point of the problem being based on perception and apparent complexity.
in order to package for all three systems, i need to first of all want to do that. and i find that i don't care enough to want it.
In the end, as long as it works, I'm very happy. Also, it doesn't preclude a given platform from AOT optimization/compile for WASM code to platform native code. I think getting common runtime interfaces is currently the paramount point... being able to use sqlite, and SDL/OpenGL adapters to canvas or webgl are also big. Not to mention audio, and various input devices (gamepads etc).
There is a lot of existing code that could be readily ported/shimmed out if we can get some common interfaces working.
https://floooh.github.io/tiny8bit/cpc-ui.html
The time in the top-right is the time spent per frame in the emulator, in the WASM version that's somewhere around 2.5 to 2.8ms on my laptop.
The native version is somewhere between 2.0 and 2.2ms.
From my experiments, it's quite easy to accidentally hit a "slow path" on the WASM side, for instance registers are spilling earlier (AFAIK because WASM has one or two registers set aside). Things are getting better though. About a year ago, the same emulator code seemed to have triggered some specific slow-path and the WASM version was nearly 4x slower.
Of course it's always possible to put more time into optimizing the native version of a piece of code when targeting a specific compiler version, compiler-specific intrinsics and a specific CPU model. This is where WASM will always lag behind, with a portable ISA you'll always hit a wall where further optimization simply isn't possible.
So from my experience: somewhere between 10% slower and 3x slower is all within the "expected" range, the more important part is that performance is predictable for a given piece of code compiled with a given compiler version (e.g. you won't have the GC come in and do its thing for a few hundred milliseconds). And at least the emscripten team is very responsive and interested in such pathological cases.
If I'm getting work done faster, prioritizing a couple more perf stories is a reasonable tax to pay.
The issue is mostly that we suck more on Spec2k6 than we realized. Since publishing that paper we do track Spec2k6 internally but we don't spend time tuning for it.
/v8 wasm runtime TL
1. WASM <--> JS/Host calls seem to have a higher cost on chrome than FF [1][2]. Is that in your optimization roadmap?
2. Wasmer tracks V8 perf against other backbends, and the LLVM backend consistently outperforms V8 [3]. Can anything be done to address this, especially for node, where the compile time cost of a super optimizing compiler might be beneficial in certain applications?
[1]: https://bnjbvr.github.io/perf-wasm-calls/
[2]: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
[3]: http://speed.wasmer.io/comparison/
The code in lines 35-37 in Figure 7(c) looks like you should be able to fold the memory operand even in a simple peephole pass before register allocation, no? (I know, I know, patches are probably welcome ;-))
We're all putting up with regular 10% drops in our CPU performance because intel was stupid about alot of things; maybe we could give 10% up for common applications (let's face it, most aren't CPU-bound) having more safety.
Of course, I don't know if wasm is the answer. Jury's still out for whether it's great in native or not; honestly, GUI is still the issue.
And then, you can use my app by typing its address into your address bar. No installation needed. No polluting your home directory. No registry entries. It's sandboxed, you're never giving the app permissions that you don't intend. A service worker can be used to make the app available offline. My dear grandmother could use this without confusion. My dad can use these apps and feel confident he's not not infesting himself with malware or bundled software.
The complaints about "the web doesn't feel native!" and "it's less secure!" and "it's just as easy to ship a native app [for my platform of choice]!" are tired arguments. We've finally got a simple way to distribute apps fully cross platform in a way that CAN respect privacy and guarantees a reasonable level of security. And, it's pretty darn 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 applications and library into the browser. I'm excited to see what people do with WASI, but its not clear to me what a program designed from the ground up around capabilities would look like!
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.
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)
Everything old is new again.
"Literally everything you said except the part about inflatable tires has been true of wooden wheels for at least 3000 years. Everything old is new again."
Sometimes, reinventing the wheel actually makes sense.
But I agree: HTML/CSS/JS is far easier (eg: threading) and generally results in a more polished experience.
None of them have anything to do with lack of skill using Swing.
> None of them have anything to do with lack of skill using Swing.
Can you name me 10 swing apps that look good? I can do the same for the web and MacOS. I'm not sure I'd be able to name 10 for windows, but I can name at least two.
Anyway, InteliJ, SwingUI Weather app, any app using Substance, Alloy, JGoodies or Synthetica theme libraries.
No need to be nasty. I chose 10 at random because it's a decent sample size without being too onerous for an online discussion. If I wanted to earn internet discussion points, I would have made it 10,000.
I'll take a look at those and get back to you. I'm very curious. Unlike some commenters (not a jab at any particular person or even a particular site, just a general observation of commenters online), I like it when I'm proven wrong about something. I'd rather know than live in ignorance.
The resources available for HTML/CSS cannot be compared with JavaFX, Swing or whatever the other original stack was. And the Applets sandboxing was obviously so horrible everyone killed it. WA is amazing here copying the existing and already hardened JavaScript model.
JS is a better compilation target (you don't have to use JS directly) than WASM for the vast majority of languages. WASM is great for when you have a bit of code you'd like to write in C and use as a library from JS (or a language compiled to JS).
Layout engines with customization capabilities?
Where is the hardware accelerated drawings that I can be fully sure it is hardware accelerated without doing tricks with z index and hoping for the best regarding mapping css drawings into textures?
Did you ever actually use a PowerBuilder (or similar RAD tool) application? The experience was horrible, slow, and basically a waste of titanic amounts of money.
I once saw half an accounting department quit after a switch to a RAD financials package.
There’s a reason all those 1990-2005 era vertical-market app companies got bought by PE firms and are just basically dead except for milking maintenance revenue. Building “data-model centric” apps with RAD tools optimizes for ease of the developer instead of the end user. Which is exactly backwards.
Parallel to that I have been doing Web projects since 2000 as well.
HTML 5 / CSS 3 has nothing that compares, that is why Flash took off and is coming back in the form of WebAssembly, now with everyone racing to support it with their favourite runtime + WebGL.
Either the developers are able to use the tooling at their disposal to deliver awesome products or not.
Skype was originally coded in Delphi, so yeah.
Anything written with Electron is pretty much bad.
I only put up with Slack and VSCode due to job requirements.
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.
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?
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.
Does wasm strategically impact the dominance of the App Store?
I recall there being an article about how despite the fact that iPhones are 10% of the market, they represented 50% of the profits for application developers.
GluonVM, RoboVM and CodenameOne are three AOT compilers for Java targeting iOS.
Also OpenJDK has reactivated the project to provide an AOT compiler for iOS via SubstractVM.
Java is an open standard (I think, I didn't fact check this thuroughly) OpenJDK is the reference implementation of that standard. You can try to claim that in reality Oracle has a lot of control, but I'd come right back and say that Google basically controls the browser.
> The success of WASM is that my mom doesn't need to know how to install Java
If OSs had bundled a Java runtime she wouldn't need to install Java either.
On the other hand, I still have no way of distributing my system services easily in a cross-platform way.
Say, I have a service that is triggered when RC45 is jacked in or when a passive scan on a wifi device is completed. I still have to package it for android, ios, osx, linux (rpm, deb, aur) and windows separately.
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.
I.e., do we expect to see performance improvements similar to what we've seen in JavaScript over the last two decades? Or are we going to need better hardware to realize better performance?
> It is worth asking if the performance issues identified hereare fundamental. We believe that two of the identified issues are not: that is, they could be ameliorated by improved implementations. WebAssembly implementations today useregister allocators (§6.1.2) and code generators (§6.2.1) thatperform worse than Clang’s counterparts. However, an offlinecompiler like Clang can spend considerably more time togenerate better code, whereas WebAssembly compilers mustbe fast enough to run online. Therefore, solutions adoptedby other JITs, such as further optimizing hot code, are likely applicable here.
> The four other issues that we have identified appear to arise from the design constraints of WebAssembly: the stackoverflow checks (§6.2.2), indirect call checks (§6.2.3), andreserved registers (§6.1.1) have a runtime cost and lead to in-creased code size (§6.3). Unfortunately, these checks are nec-essary for WebAssembly’s safety guarantees. A redesigned WebAssembly, with richer types for memory and function pointers [23], might be able to perform some of these checksat compile time, but that could complicate the implementation of compilers that produce WebAssembly. Finally, a Web-Assembly implementation in a browser must interoperate witha high-performance JavaScript implementation, which mayimpose its own constraints. For example, current JavaScript implementations reserve a few registers for their own use,which increases register pressure on WebAssembly.
Great info, thanks for sharing! So, to summarize:
Performance will get a bit better for WebAssembly 1.0, but we'll need a WebAssembly 2.0 (for lack of a better term) to realize major performance improvements. And/Or we'll need advancements in JIT technology.
Beyond that, there will always be some limitations because of the Javascript interop requirements.
And, as other threads here have pointed out... maybe who cares? It's still pretty fast!
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-64 processors and would solve the issue.
Once this is changed, the only remaining fundamental unfixable differences would be reduced cache efficiency from the extra bytes for the segment override, and the need to reserve an extra register for the wasm stack pointer.
However, running WebAssembly code in a separate address space would allow to run arbitrary code, although this would have the drawback of higher memory usage and IPC slowdown.
Is there any article discussing the rationale between Firefox and Chrome's current approach and whether they plan to use either segment overrides or process isolation?
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.
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).
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.
https://dotnet.microsoft.com/apps/aspnet/web-apps/client
https://www.youtube.com/watch?v=uW-Kk7Qpv5U
It packages the entire .NET framework into a single wasm app, so it's a little bloated, but it works.