
Measuring the overhead of WebAssembly using libsodium - jedisct1
https://00f.net/2019/04/09/benchmarking-webassembly-using-libsodium/
======
magicalhippo
> An important point here is that the native code does use SIMD
> instructions[...]. Whereas the WebAssembly backend doesn’t support these.

I understand the reasoning of the author, still it would have been nice to
have a comparison with non-SIMD native code for those of us who don't keep
track of how much the SIMD buys you these day for crypto.

> On a surprising number of tests, Cranelift’s optimizations produced slightly
> slower code than with optimizations disabled.

So how much of this result is WASM and how much is Cranelift? By the sound of
it, Cranelift doesn't produce very optimal output yet, so should still be
potential for significant gains, no?

~~~
sunfish
Right now, a lot of it is Cranelift. We haven't yet done much optimization
work on Cranelift yet, so there's a lot of room for improvement.

~~~
magicalhippo
Thanks. A factor 2-4x slower than pure native is totally acceptable for many
workloads, and it sounds like that's a realistic goal. Exciting times.

------
black_puppydog
> The original, native code is extremely fast. Way faster than most
> applications need.

Faster than any _one_ application needs. But virtually anything I do nowadays
uses crypto on some level, and wasm isn't only proposed to be used for crypto
either. Suddenly, my CPU has to do 2x to 7x the work for the same code,
because we collectively decided that using electron and web stuff if the way
to go for nearly every mainstream application? I don't think so, really.

WASM seems to me like some people are simply longing for the old days of
flash. I don't see why I'd want it.

~~~
ScottFree
> I don't see why I'd want it.

It lets web devs use languages other than JS on the frontend. That's primarily
why I'm excited about it.

As for why electron, the only real explanation I've heard from people that
makes sense is the ease with which you can put together custom UI controls and
style them. All of the desktop UI systems are great at the simple things, like
putting default OS controls in an app, but complex things like creating custom
controls, animations and complex styling appear extremely difficult to
accomplish. At least, that's the way it seems to me.

~~~
CoolGuySteve
And here I am just wishing for table cells and list views on the web that have
functional mouse selection.

~~~
nwienert
I’m launching this as part of an app platform soon-ish. If you’d like to beta
test get in touch. Virtual tables and lists, with keyboard and shift/command
selection modifiers, click and drag to select, edge scrolling, sorting, etc.
All with a couple lines of code!

------
speps
The title of the submission is wrong it should be "Benchmarking WebAssembly
using libsodium". This isn't about the overhead, it's about comparing native
vs. WASM using a concrete example.

------
Razengan
Every time an article which invites arguments between "native" vs. "web" is
posted, this needs to be said:

What we really need to settle this, is a cross-platform UI framework that
compiles to native UI and code on each OS/hardware.

~~~
acemarke
Sooo... wxWidgets and Qt? :)

[https://www.wxwidgets.org/](https://www.wxwidgets.org/)

[https://www.qt.io/](https://www.qt.io/)

~~~
Razengan
If they really do translate to a fully native experience/look-and-feel on each
OS, what's keeping them from being more commonly used?

Not a rhetoric question, because the answer is what needs to be fixed.

~~~
orthecreedence
> what's keeping them from being more commonly used?

One of the reasons is the fact that they're written in C++ and not C, therefor
difficult to wrap natively by host languages.

At least, that's my main gripe as someone who doesn't want to touch C++.

~~~
Razengan
So if they were C, then one would be able to bridge almost "toll-free" with
Swift/Objective-C on the Mac, for example.

------
Game_Ender
What is disappointing here is that they did not run on Firefox or Chrome. The
independent WASM runtimes are not as mature as the browser based ones, so it
would be great to see the difference.

------
pier25
Would have been nice to include JS benchmarks to get a better perspective.

------
mcphage
I would like to see the same results with, say, 1,000 trials and 10,000 trials
as well—how much of the slowdown is a fixed overhead, and how much of it is
that the code runs X-times slower?

------
davidhyde
Is libsoduim written in a low level language like c or did they compile
javascript down to webassembly somehow? It wasn't clear from the article. At
least my reading of it.

~~~
kwindla
libsodium is written in c. "Pure javascript" is a supported compilation
target[0] of the project. Emscripten is used to compile the c to javascript.
There's also now a wasm compilation target, again via emscripten.

The c source code is really excellent[1]. It's worth browsing!

[0]-[https://github.com/jedisct1/libsodium.js](https://github.com/jedisct1/libsodium.js)
[1]-[https://github.com/jedisct1/libsodium/tree/master/src/libsod...](https://github.com/jedisct1/libsodium/tree/master/src/libsodium)

