Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
usenix.org
usenix.org
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.
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.
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.
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.
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.
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.
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...
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 ;-))
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!
> [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.
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.
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.
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.
That was java's claim (but not the reality), what's the slowdown there?
That is except startup time.
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.