from Hacker News

A Real-World WebAssembly Benchmark

by MartinMond on 7/5/18, 3:15 PM with 89 comments

  • by bjpirt on 7/5/18, 4:02 PM

    Personal WASM anecdote: I just implemented a WASM based 3d model boolean operation for three.js where I can intersect two models together. The pure js version ran in around 10s on a relatively simple model whereas the WASM version did the same thing in a little under 1s. I've been very impressed by the technology so far! Obviously this kind of CPU intensive work is where it can shine and it's a useful tool to have in your toolkit.

  • by MartinMond on 7/5/18, 3:22 PM

    PSPDFKit CTO here: We've been using WebAssembly since 2017 to render PDF documents directly in the browser and strongly believe in the future of the technology.

    We published this benchmark to have a public indicator of the performance gains WebAssembly promises in a real-world product.

  • by markdog12 on 7/5/18, 4:52 PM

    Firefox crushing the competition on this (all on iMac late 2015):

      Firefox Nightly: 2216  
  Chrome Canary: 5078  
  Safari Tech Preview 60: 7216
    Brand new iPad 2018: 16653

    Moto G4 phone Chrome: 37735

    Windows 10 Laptop:

      Firefox Nightly: 2278
  Chrome Canary: 4907
  Edge: 16332

  • by ebikelaw on 7/5/18, 4:34 PM

    OR I can just read and edit PDFs in the peak-optimized, ahead-of-time-compiled native PDF reader that comes on my computer.

  • by tokyodude on 7/6/18, 2:22 AM

    FYI: WebAssembly is effectively starting to get WebAssembly only APIs. Chrome is shipping the WebGL commit API which is designed to support spin loops in native apps (others are expected to ship it too)

    Most native OpenGL apps run in a spin loop as in

        while(true) {
      update();
      render();
      glSwapBuffers();
    }
    To support that model TPTB added a worker only `gl.commit` function that does effectively the same thing as `glSwapBuffers` so that native apps can keep their spin loops and don't have to refactor to be event based.

    Of course if you decide to use a `gl.commit` spin loop your worker can no longer receive events (no onmesagge, no XHR, no websockets, no fetch) so you're supposed to use SharedArrayBuffers to communicate with a spin loop worker.

    SharedArrayBuffers are being re-enabled once they are isolated to same domain only processes.

    AFAICT this is the first browser API that is really targeted exclusively at WebAssembly. I'm guessing more will come. Not entirely sure how I feel about that but I guess it's inevitable.

  • by KaoruAoiShiho on 7/5/18, 4:17 PM

    > The team was especially helpful in pointing out bottlenecks in our JavaScript implementation, and we’re already incorporating these changes into our next PSPDFKit for Web release.

    Any chance you can talk about those bottlenecks? Might be interesting.

  • by stcredzero on 7/5/18, 5:21 PM

    We should be at the point where network computers are practical for casual users. A full install of the BeOS operating system is just 45MB. A tricked-out one was barely more than a couple of hundred MB. We should now be able to have operating systems which are mostly cached from online connections, running in clients like Web Browsers, but purpose built for running such an OS.

  • by symboltoproc on 7/5/18, 3:43 PM

    What's the difference to benchmarks like https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...? The results seem vastly different.

  • by singularity2001 on 7/5/18, 6:13 PM

    the standalone version produces a dom tree?

    I expected canvas rendering, which would be MUCH faster. (?)

    <div style="top: 628.75px; left: 125px; position: absolute; transform-origin: 0px 0px 0px;"><label style="width: 38px; height: 38px;" class="PSPDFKit-43pb73xrbckjuggksebahxjw9 PSPDFKit-Annotation-Widget PSPDFKit-Annotation-Widget-CheckBox"><input name="Checkboxes 2" value="Checkboxes" type="checkbox"><span class="PSPDFKit-v4b9qprfhz2hybx1p43s4xgx6 PSPDFKit-8vpzte5r65p8pf9q4d61qcb34u" style="border-width: 1.25px;"></span></label></div>

  • by Matthias247 on 7/5/18, 5:31 PM

    > Browser vendors can reach out to us and obtain a more permissive license key so that the benchmark can run on different machines and even on their continuous integration servers.

    Sounds like a great idea for encouraging performance improvements and avoiding regressions!

  • by yandrypozo on 7/5/18, 7:10 PM

    wondering why those benchmarks weren't run on Linux distros like Ubuntu, Debian, etc.

  • by billybolton on 7/5/18, 9:33 PM

    Now all we need is to expose a graphics context to wasm. No need for DOM support.

  • by aioprisan on 7/5/18, 5:51 PM

    Great work, looks like a very useful PDF toolkit. I've been working on a side project implementing something similar for some time but has stalled due to life getting in the way. Can you share anything publicly in terms of pricing?

    I see everything is through a sales person now and I'd like to get a better high level understanding of high level costs for passion projects (<1000 users), small-medium (<100k), and enterprise (1M+). What metrics are you charging usage on?

  • by krzyzanowskim on 7/5/18, 3:38 PM

    Safari is so slow

  • by thosakwe on 7/5/18, 4:09 PM

    One thing that would be super nice, in theory, would be compiling WASM modules on-the-fly from the text format.

    In a sense, it would be like a JIT for the Web, and one possibility for bringing existing JIT-based languages to WASM.

  • by KaoruAoiShiho on 7/5/18, 4:29 PM

    What is the most performant compile to wasm language? Or are they all similar?

  • by bigato on 7/5/18, 4:02 PM

    > In the future, Microsoft wants to bring more features — which are currently not possible in asm.js (or JavaScript) — to WebAssembly.

    This is very vague, but already disturbing

  • by mrmondo on 7/6/18, 4:44 AM

    - Firefox 62b5: 1429

    - Chromium 68: 5722

    - Safari 11.1.1: 6500

    On 2017 Macbook pro running macOS 12.13.5 on battery power

  • by owaislone on 7/6/18, 10:14 AM

    I tried on Ubuntu 18.04. Firefox around 2k and Chrome around 10k