[HN Gopher] Is WebAssembly magic performance pixie dust? (2021)
___________________________________________________________________
Is WebAssembly magic performance pixie dust? (2021)
Author : simonebrunozzi
Score : 79 points
Date : 2022-07-14 16:18 UTC (6 hours ago)
(HTM) web link (surma.dev)
(TXT) w3m dump (surma.dev)
| andsoitis wrote:
| > custom compiler for a TypeScript-like language targeting
| WebAssembly. The reason I like AssemblyScript (or ASC for short)
| is because it allows the average web developer to make use of
| WebAssembly without having to learn a potentially new language
| like C++ or Rust. It's important to note that the language is
| TypeScript-like. Don't expect your existing TypeScript code to
| just compile out of the box. That being said, the language is
| intentionally mirroring the behaviors and semantics of TypeScript
| (and therefore JavaScript), which means that the act of "porting"
| TypeScript to AssemblyScript are often mostly cosmetic, usually
| just adding type annotations.
|
| I haven't had the time to read more, but I'd be curious to learn
| why they didn't just target full TypeScript compatibility. That
| would reduce the barrier to entry materially.
| pohl wrote:
| With TypeScript being a strict superset of JavaScript, wouldn't
| that entail dragging all of JavaScript semantics along?
| RobbieGM wrote:
| He makes a point of showing how hard it is to achieve the same
| performance as JS with wasm, but the majority of the problems he
| runs into are AssemblyScript-related. Also he doesn't mention
| that wasm is faster to parse than JS. I'd be interested in a
| comparison of JS and wasm from the POV of a UI-heavy, compute-
| light app.
| game-of-throws wrote:
| js-framework-benchmark is the standard benchmark for UI-heavy,
| compute-light JS. https://krausest.github.io/js-framework-
| benchmark/current.ht...
|
| To see results, show "vanillajs-1" and "wasm-bindgen", then
| hide everything else. WASM is about 6% slower, 18% longer
| startup, and 66% more memory usage.
|
| Note this is a UI benchmark so the results are overwhelmingly
| dominated by DOM interop. Things should improve if the WASM
| interface types proposal ever lands.
| RobbieGM wrote:
| I get that it would have a startup cost but I'm shocked that
| it uses more memory. Everyone complains about what a memory
| hog electron apps are and I assumed it was because of JS. But
| maybe we need something other than micro benchmarks to
| compare.
| game-of-throws wrote:
| The absolute numbers aren't that different. You need 100s
| of MB just to display an empty Chrome window. Then the 66%
| is the difference excluding that baseline, e.g. it might be
| 300MB to load Chrome, then you measure 301MB vs 301.66MB. I
| guess that might be a bit misleading.
|
| I think the electron memory usage comes down to the massive
| HTML spec and bloated old browser codebases. It's not JS.
| Node+V8 doesn't have nearly the memory usage of Chrome+V8.
| RobbieGM wrote:
| That difference is what I'd be interested in anyway as a
| developer who focuses on PWAs (where the cost of chrome
| is paid for already). I'm trying to work out whether a
| WASM stack would help runtime performance, memory usage,
| and startup time, but based on these numbers it doesn't
| look so inspiring.
| pornel wrote:
| While just the parsing step may be faster indeed, I don't think
| that aspect alone is enough to make a difference for an
| application.
|
| Browsers are often able to defer parsing of JS functions until
| they're called, so dead JS code doesn't cost much in parsing
| time.
|
| In JS first run goes through an interpreter (without a delay
| for compilation/optimization), so JS has a pretty low latency
| for initial execution.
|
| JS is relatively easy to split into pieces and lazy load (there
| are various bundlers that support "chunking"), and not loading
| code is faster than fastest parsers. WASM could theoretically
| do that too, but current languages and tooling are more geared
| towards monolithic executables. For UI, where time to
| interactive matters most, JS will likely do a better than a big
| blob of WASM.
|
| WASM still needs to call out to JS for DOM interactions, so if
| your UI is DOM-based, you'll need a bunch of JS anyway, and
| have JS<>WASM communication overhead.
| jagged-chisel wrote:
| Does wasm support anything other than monolithic executables?
| The last I used it, multiple wasm bundles had to be loaded up
| by JavaScript and glued together with JavaScript.
| moralestapia wrote:
| Very nice and well researched article.
|
| I'm all in on Wasm on the medium-to-long term as I think it will
| eventually dominate everything (embedded, mobile and web). The
| comparison with JS is a bit unfair as the former has had a 20+
| year head start plus billions of dollars (yes, billions) in R&D
| to make it as performant as possible.
|
| I think JS is a great language/platform and I consider V8 an
| amazing piece of engineering, it would be on my list for the
| seven wonders of the digital world. Wasm will get there someday
| and will take the place of JS, IMO.
| dcow wrote:
| We use WASM today and it's not for any performance reasons.
| Hopefully, like you say that will become an advantage too down
| the road as WASM matures. But, simply, there are parts of our
| application which we feel much more comfortable with and we
| find much more manageable being implemented in Rust and
| compiled to WASM. So for us WASM grants portability and
| language choice in a first class manner (as opposed to
| transpiling to and from JS and all the glue that entails). It's
| a real shot at dismantling the browser JS hegemony.
| thebeastie wrote:
| It sounds more like Rust gave you that choice, because it
| would have been just as good if the rust code transpiled to
| JS. I'm not knocking WASM just pointing out that you're not
| praising any particular qualities of WASM, but of Rust.
| moralestapia wrote:
| >It sounds more like Rust gave you that choice
|
| Yes, but there's also a reason why the Rust -> JS route
| never took off.
|
| Wasm is positioning itself as the common runtime for a lot
| of frontends (term borrowed from LLVM). You could see it as
| some sort of spiritual successor to the JVM, and it may
| actually accomplish the goal of "Write once, run anywhere"
| to a much greater extent.
|
| (Btw, I am not criticizing Java here, I've worked with it
| and the JVM and other derivative languages for almost a
| decade and they all are quite valuable tools!)
| andsoitis wrote:
| > dominate everything (embedded, mobile and web)
|
| Do you also think it will displace runtimes on the server? I'm
| thinking about the JVM and CLR.
| chrisweekly wrote:
| IMHO it will have to, if it's ever going to dominate "web".
| moralestapia wrote:
| I do, and it has already creeped into some platforms that
| provide, at least, compatibility with these runtimes, see:
| https://www.graalvm.org/22.1/reference-manual/wasm/
|
| Btw, I think the GraalVM project is another amazing piece of
| tech with a bright future.
| psyc wrote:
| Performance is important, but the point of WebAsm was to have an
| asm for other languages to compile to in the first place, so we
| could finally stop making embarrassing utterances like
| "JavaScript is the assembly language of the Web."
| Georgelemental wrote:
| I think this is the first interrobang (!?) I've seen in the wild
| syrusakbary wrote:
| I loved reading this article, I think it showcases pretty well
| that any optimization is about tradeoffs and there are hardly any
| absolutes.
|
| The article was also posted in HN about a year ago:
| https://news.ycombinator.com/item?id=26803155
| dvh wrote:
| How does it compare with canvas' blur filter, or boxblur canvas
| library?
| svnpenn wrote:
| Personally Ive never cared about the performance aspect. If you
| care about that, you probably shouldn't be targetting the browser
| in the first place, but instead a native app. What has always
| turned me off about WASM, is that all the tutorials Ive read say
| you need some kind of JavaScript shim to get it working. That
| doesn't feel like a first class solution to me. If I can do WASM
| without any JavaScript, then I am interested.
| mden wrote:
| There are good use cases for WASM in the browser where the js
| shim is transparently provided for you, e.g. for game engines
| that export to web. As for non-web use, I believe the wasm
| runtimes that exist generally don't require js shims.
|
| Also even if you don't care about performance, WASM can
| arguably provide a sizable security benefit for a number of use
| cases such as not-fully trusted plugins.
| Animats wrote:
| Everything has to be in the browser now. People don't download
| and run programs any more.
|
| Even if they want to, the programs have to be approved by
| Master Control. Apple [1] and Microsoft [2] are gradually
| tightening the restrictions for installing an executable on
| their platform. Downloading a program and installing it is now
| called "sideloading". Even for desktops.
|
| [1] https://developer.apple.com/app-store/review/guidelines/
|
| [2] https://docs.microsoft.com/en-
| us/windows/uwp/publish/store-p...
| svnpenn wrote:
| > Everything has to be in the browser now
|
| I have about 20 exe in a folder that say you're wrong. I also
| have about 9 other folders with unzipped programs that say
| you're wrong. Nothing is stopping anyone from downloading an
| executable file and running it on a desktop computer. Nor
| should it.
|
| How do you think people do software development? Or do you
| just think new programs come from magic pixie dust?
| r_hoods_ghost wrote:
| "Nothing is stopping anyone from downloading an executable
| file and running it on a desktop computer." Have you ever
| had a job? If you're in a workplace you probably don't have
| admin rights to install software on your desktop unless you
| are a dev, and even then it's not exactly guaranteed.
| svnpenn wrote:
| > If you're in a workplace you probably don't have admin
| rights to install software on your desktop unless you are
| a dev, and even then it's not exactly guaranteed.
|
| OK then, ask the admin to install it, I don't see the
| problem. If its appropriate work software, then it
| shouldn't be an issue. Web browser should be for...
| browsing the web. If you're simply using a browser to
| bypass admin restrictions, it seems like you're doing
| something wrong.
| antihipocrat wrote:
| An admin won't just install it. Any software installed on
| a system connected to the corporate network is a security
| risk and would need to be vetted.
|
| This takes weeks and can often take months. If the choice
| is between writing the business case, getting management
| sign off and waiting weeks for deployment vs running it
| immediately in the browser, I'm choosing the browser.
| ciupicri wrote:
| Not to mention the fact the website hosting the
| application might be blocked by the same admin.
| Animats wrote:
| For home computers, there's now "Windows S".[1] This is
| totally locked down. "To increase security and
| performance, Windows 11 in S mode runs only apps from
| Microsoft Store."
|
| It's possible, for now, to turn off Windows S mode. For
| now. Usually. The Windows Store server has to approve
| turning it off. In an enterprise configuration, some in-
| house server has to approve.
|
| [1] https://support.microsoft.com/en-
| us/windows/windows-10-and-w...
| svnpenn wrote:
| > It's possible, for now, to turn off Windows S mode. For
| now. Usually.
|
| As much as I enjoy seeing someone trash Microsoft, this
| is just a dumb take. Like I said to the other user, how
| do you think software development happens? Microsoft
| wants people to develop using Windows [1][2][3]. You can
| only do that by installing additional software. This is
| not, and never will go away. Yes, some corporate setting
| will have locked down computers, but thats how its
| already been for several decades.
|
| 1. https://wikipedia.org/wiki/.NET
|
| 2.
| https://wikipedia.org/wiki/C_Sharp_(programming_language)
|
| 3.
| https://wikipedia.org/wiki/F_Sharp_(programming_language)
| dktoao wrote:
| Looking to get the perspective of some HN'ers here. I am
| primarily an embedded engineer working with C. Our (small)
| software team also has a few web people that work on the web UI
| of our embedded Linux product. Obviously, there is a ton of
| potential for shared code between the two products utilizing
| WASM. I recently ported one of our C libraries to WASM as an
| experiment with emscripten and was blown away by how easy it was.
| I can't run the unit tests in the browser yet but it seems to
| have worked perfectly. However, the JS "glue" code that is
| produced by the emscripten compiler is really scary looking, and
| as I understand is basically an abridged C runtime that needs to
| run in the browser. My questions are therefore:
|
| 1) Is it too early to adopt WASM for production use in a small
| company with limited resources?
|
| 2) If we did decide to go all in on WASM, what sort of gotchas
| might we be dealing with?
|
| Thanks everyone!
| modeless wrote:
| I think WASM is ready for production use. Emscripten does
| produce big blobs of JavaScript. If it bothers you it's
| possible to do WASM without Emscripten. If your embedded code
| doesn't use a lot of libc then it might actually work for you.
| https://surma.dev/things/c-to-webassembly/
|
| The big gotcha used to be debugging but Chrome dev tools
| actually has DWARF support now. Of course as an embedded
| developer you're probably already used to poor debugging
| support.
| dktoao wrote:
| Heavy use of libc for file io and dynamic memory allocation,
| but not much else. Some of our code could be converted to
| using static memory buffers, but we also use some third party
| libraries that are not so easily changed. Thanks for the
| link, I will have a look!
| cogman10 wrote:
| > Is it too early to adopt WASM for production use in a small
| company with limited resources?
|
| It really depends on what you are doing with it.
|
| For things like "I've got this C lib that I want to be able to
| call from the web" it's probably fine. For things like "I want
| to write my whole webpage in wasm" it's not ready for that
| (and, frankly, likely never will be).
|
| It's a matter of finding the right fit.
|
| > If we did decide to go all in on WASM, what sort of gotchas
| might we be dealing with?
|
| Depends on what you mean by "all in" if you mean, "I want ALL
| my webapp logic to live in wasm" then the biggest gotcha you'll
| face is shipping stuff into and out of the VM (including DOM
| elements) is really painful. IMO, UX continues to best be done
| with Javascript or compile to javascript langauges (typescript,
| for example). Using a language like C, C++, or Rust to do UX
| work will simply not be pleasant, will be hard to hire for, and
| will complicate a lot of your build system.
|
| Now, if by all in you mean "This logic only lives in this
| library and we are shipping that out as a WASM module" then I
| think wasm will work well there. Better, in fact, than other
| options like kotlin to native or J2CL (IMO).
|
| That said, there are fledgling UX frameworks written entirely
| for WASM. However, they are all relatively young and AFAIK, not
| exactly well established.
|
| This becomes an engineering decision and balancing act that I
| don't think can be 100% answered for your company.
| humanwhosits wrote:
| Will there be a DOM api for wasm?
| cogman10 wrote:
| Probably never an official one. That'd sort of defeat some
| of the point of WASM.
|
| What already exists is multiple bridge libraries to make
| porting stuff from JS -> WASM and back again easier.
|
| For example: https://rustwasm.github.io/wasm-
| bindgen/examples/dom.html
| NohatCoder wrote:
| Never say never, but the DOM and JavaScript environment
| relies pretty heavily on garbage collection. WASM is
| inherently not garbage collected, and that makes it really
| hard to share data between the environments, so I'd say
| that it is unlikely.
| wffurr wrote:
| There's nothing about WebAssembly that's "inherently" not
| garbage collected. There is a "Host GC" proposal [0]
| along with a "reference type" proposal that would allow
| holding handles to DOM or JS objects from WebAssembly and
| using the JS GC for WebAssembly objects.
|
| [0]: https://github.com/WebAssembly/gc/blob/main/proposal
| s/gc/Ove...
| dktoao wrote:
| Thanks for asking for those clarifications,
|
| I don't expect any of the UI work will ever be done in WASM
| (because it doesn't need to be shared with the embedded side
| of things). It is more porting standalone libraries that
| would be useful for both like file parsing and networking
| libraries. (In particular, the library I ported was a file
| parser).
| cogman10 wrote:
| In that case, yeah, it will work. You just have to realize
| that WASM has a REALLY tight sandbox around it, so getting
| a file/network stream into it will be somewhat of a pain.
|
| WASM works best in cases of strict CPU and limited GPU
| processing (through webgl).
| modeless wrote:
| It's hard to beat JavaScript because the VMs are amazing. If you
| know a few tricks, like how to let the VM know you want integer
| math [1], you can get performance that's not too far off from
| native C in many cases. If you have a JavaScript application with
| a few hot functions that are slow, optimizing the JavaScript
| usually makes more sense than reaching for WASM.
|
| [1] https://james.darpinian.com/blog/integer-math-in-javascript
| solardev wrote:
| > If you know a few tricks, like how to let the VM know you
| want integer math [1]
|
| > [1] Add | 0 after every math operation to get a 32-bit signed
| integer result, and >>> 0 for a 32-bit unsigned integer result.
|
| That's definitely gonna cause a few "wtf?" moments for everyone
| else on your team, lol
| modeless wrote:
| Yeah, you shouldn't do it all over the place
| prophylactically. It's a technique for optimizing functions
| that are performance critical. Although I find `| 0`
| surprisingly well known these days. I sometimes use it in
| places where I want a cast to integer.
| josephg wrote:
| In my experience the place wasm really shines is in
| implementing custom data structures.
|
| A wasm b-tree, skip list, rope, etc seems to outperform the
| equivalent javascript code by 10x-100x.
| modeless wrote:
| This makes sense to me; graphs made of JavaScript objects are
| not going to be as fast as C, although I think knowledge of
| how the JIT works can still help you get a lot closer than
| 10x (e.g. ensuring everything is monomorphic). Now if you
| implemented a b-tree completely inside of a typed array,
| instead of using JavaScript objects as the nodes, that would
| be how you would approach C speeds. But if you need a lot of
| custom data structures, WASM is probably a better choice at
| that point.
| zinekeller wrote:
| Most of those optimizations stems from Mozilla's asm.js
| (http://asmjs.org/), which specified those as an explicit
| signal. Note that if you're still supporting IE (commiserations
| and I wish you that you could decommission it ASAP) this will
| _slow down_ you code (only in IE of course) instead of speeding
| it up.
| dahfizz wrote:
| > you can get performance that's not too far off from native C
| in many cases.
|
| Source? Every benchmark I've seen that has JS comparable /
| faster than C uses an extremely suboptimal C implementation.
| wylie wrote:
| A group of smart WebAssembly experts tried to start a company
| around the idea of incrementally porting to WebAssembly, and
| wrote an excellent post-mortem of why that didn't work:
| https://zaplib.com/docs/blog_post_mortem.html
| tra3 wrote:
| That was interesting to read. Apart from wasm/rust experiment,
| they got real customers and validated their idea in the real
| world. Still an amazing result.
| labrador wrote:
| The way I understand it, WebAssembly is faster because you skip
| the parsing of JavaScript. If parsing JavaScript is not a
| bottleneck in your app, it's not going to be faster. I'm also
| under the impression that people want it because they can use a
| language other than JavaScript.
|
| I could be wrong, but that's my going by 60 mph, looking out the
| window view
| tines wrote:
| Not quite; if this were true then any javascript would be valid
| webassembly, which isn't the case.
| labrador wrote:
| I was excluding the parts of JavaScript that don't compile to
| WebAssembly, dom manipulation for example
| RL_Quine wrote:
| The combination of colors and fonts makes this nearly impossible
| to read.
| wizofaus wrote:
| Really? Aside from the dark red links on dark blue background,
| I couldn't disagree more - it's a rare example where picking
| custom colours for text & background really does work nicely.
___________________________________________________________________
(page generated 2022-07-14 23:01 UTC)