The Rusty Web: Targeting the Web with Rust

https://davidmcneil.github.io/the-rusty-web/

by 314testing • 9 years ago

312 106 9 years ago

davidmcneil.github.io

Interesting how when you read the articles about WASM and ASMJS you see stuff like "1.5-2x peformance loss over native code" but here it's 35-3x.

And this is a computation benchmark, it's not even hitting sand-boxed API overheads.

moron4hire2• 9 years ago

It's a pretty bad benchmark. I don't think there are any conclusions about WASM, ASM.js, or JavaScript that we can glean from this. All we can get is "this person's translation process is not very good."

stupidcar• 9 years ago

All "this person's translation process" seems to be is selecting different compile targets in the official Rust compiler and then comparing the performance of each. Maybe some of those targets' optimisation is less mature than others, but the basic benchmark doesn't seem unreasonable to me.

steveklabnik6• 9 years ago

They didn't document what version of Rust they used, but our support is still fairly preliminary. For example, it wasn't until very recently that we even passed in flags to optimize the output at all. My understanding is that there's still a lot of low-hanging fruit with the integration generally.

TurboHaskal• 9 years ago

If it's a blog post, it's probably nightly.

bluejekyll4• 9 years ago

I didn't see a link to the source. It would be really cool to see the source code so that other people could validate the work and help point out better implementation options. It's like a scientific paper not disclosing its methods.

floatboth• 9 years ago

"Native WebAssembly support is not available in this browser" Firefox Nightly. Something's wrong with the detection

markdog122• 9 years ago

Same with Chrome Canary. I suspect the toolchain he's using is a little bit behind the wasm spec.

callahad• 9 years ago

The binary has version 0xD, the last pre-release version of WebAssembly. Firefox and Chrome are now looking for version 0x1.

CorySimmons• 9 years ago

A few comments are mentioning the implementation is probably dated.

Does anyone have benchmarks that tell a different story?

flohofwoe3• 9 years ago

Not a benchmark, but my 8-bit emulator let's you compare asm.js and wasm performance between browsers and platforms somewhat, and (if compiled natively) also for native x64 or ARM performance:

http://floooh.github.io/virtualkc/

It's implemented in a C-with-classes style C++ though, not Rust.

When you press the 'UI' button, there's a little millisecond timer in the top-right corner which tells you how much time is spent in the 'emulator frame', which is pure asm.js/wasm code which doesn't call out into JS APIs.

You can switch between the asm.js and wasm version through the hamburger-menu-icon at the top-left corner.

I'm seeing the "1.2..1.5x slower than native" performance there.

Some of my other demos are also fairly CPU heavy, for instance the two Bullet-Physics demos here:

http://floooh.github.io/oryol-samples/

These demos have asm.js, wasm and pnacl versions and also have fairly detailed timing information which makes it possible to compare performance to the natively compiled versions.

I do currently see some mysterious performance differences between Mac and Windows though, not sure what's up with that (e.g. my mid-2014 MBP with a 2.8 GHz i5 is giving better performance than the 3.5 GHz i7-4770K in my work PC).

hansjorg• 9 years ago

Great demos! What is the UI you're using in the mod and sid players?

dingdingdang• 9 years ago

I do currently see some mysterious performance differences between Mac and Windows though, not sure what's up with that (e.g. my mid-2014 MBP with a 2.8 GHz i5 is giving better performance than the 3.5 GHz i7-4770K in my work PC).

It's worth checking the single thread performance of both your CPU models (see www.cpubenchmark.net), sometimes the higher end models actually have slower single thread performance.

sunfish2• 9 years ago

It looks like the slowdown on wasm is related to the powi call in the distance function (which the benchmark page mentions as a likely suspect). Emscripten currently compiles @llvm.powi into a JS Math.pow call, however this powi call is just being used to multiply a number by itself. I filed this issue:

  https://github.com/kripken/emscripten-fastcomp/issues/171

to track this issue in Emscripten.

In JS, the assumption is that code may be written by humans, so engines are expected to optimize things like Math.pow calls with small integer exponents implicitly, which is likely why this code is faster in JS. And in the asm.js case, the page mentions that it's using "almost asm", which is not actually asm.js, so it's using the JS optimizations.

This is one of the characteristic differences between JS and WebAssembly: in WebAssembly, the compiler producing the code has a much bigger optimization role to play.

shurcooL2• 9 years ago

For some reason, Math.pow implementation in JavaScript is really optimized for special cases of multiplying numbers. I ran into this too when I found this surprising case of faster performance of Go when transpired into JS [1].

[1] https://medium.com/gopherjs/surprises-in-gopherjs-performanc...

pcwalton7• 9 years ago

For some reason, Math.pow implementation in JavaScript is really optimized for special cases of multiplying numbers.

It's used for multiplying integers in SunSpider: https://github.com/adobe/chromium/blob/master/chrome/test/da...

galacticpony12• 9 years ago

The whole code is horribly over-engineered, at least for a performance benchmark.

Anybody who uses a pow call to square a number must believe compilers are magic. Worse yet, some compilers might actually optimize for that case, reinforcing that belief.

Compilers should be dumb, fast and predictable instead. That way, everyone gets what they deserve.

pcwalton7• 9 years ago

Compilers should be dumb, fast and predictable instead. That way, everyone gets what they deserve.

That's a good way to get pummeled in benchmarks. Benchmark scores matter a lot to perception: just look at any HN thread about programming language or browser performance, or any review of browsers in the tech press.

We may not like it, but the benchmark-dominated world is the world we live in.

sqeaky6• 9 years ago

I disagree that compilers should be dumb. A smart compiler can do impressive things like take types into account to add optimizations or it can also take use patterns into account to make Javascript nearly as fast as C++.

With dumb compilers we are putting the need to understand every machine on every developer. Isolating what knowledge is required in different locations is exactly why we have abstractions. The compiler is just one more abstraction to help this kind of specialization and basic division of labor.

jbclements• 9 years ago

Wow; I really disagree with this viewpoint. I want clever compilers that produce good code from high-level specifications. I fully accept the lack of predictability.

Also, your comment that "everyone gets what they deserve" suggests that those who write high-level code (e.g. using pow() to square a number) "deserve" to have slow code. That's a strange moral outlook.

username2232• 9 years ago

Anybody who uses a pow call to square a number must believe compilers are magic.

I'm guessing he thought using a temporary variable would look less pretty, and had no idea of the relative costs of imul and ipow.

Compilers should be dumb, fast and predictable instead.

I don't care too much about dumb or fast, but they definitely need to be predictable. Even with something as low-level as C++ or Fortran, you often have to profile and disassemble to see if the compiler is doing the optimizations you want (e.g. unrolling loops, inlining functions, propagating constants, using SSE), or if you have to hold its hand. Trying to predict whether something as high-level as GHC will do what you want, or to figure out how to make it do so, is an absolute nightmare.

pjmlp3• 9 years ago

Compilers should be dumb, fast and predictable instead. That way, everyone gets what they deserve.

This is what gave us C, while the rest of the mainframe world was busy using Algol, PL/I, Fortran and Lisp dialects. Where many of the compilers already were capable of doing bounds checking elision.

markdog122• 9 years ago

Unreal Engine's Zen Garden using WebAssembly: https://news.ycombinator.com/item?id=13820633

spectaclepiece• 9 years ago

That is pretty neat, any other such examples, perhaps with better graphics?

dmix• 9 years ago

Couldn't get this to work with Firefox 52, or google-chrome-unstable or chromium on Linux. Even with the various about://flags turned on for webgl 2.0 and wasm

calcifer• 9 years ago

Works fine for me with Firefox 52 on Linux, using nVidia 378.13 drivers.

On Chrome 56 with default flags, the tab immediately crashes upon page load. I've tried enabling the "Experimental WebAssembly" flag, which prevents the crash but the demo fails to load with:

WebAssembly instantiation failed: TypeError: WebAssembly.instantiate is not a function

pjmlp3• 9 years ago

It works for me on Windows 10, NVidia GPU.

loppers926• 9 years ago

That sounds so good. I don't like javascript at all because it's a one of the worst programming language on our tiny world!

Almost every programming languages is better than javascript. The roots of javascript are for tiny special effects and not for huge well running applications. Typescript and all other frameworks for javascript are just workarounds for a buggy language.

In my opinion the final step is to replace completely javascript with something else!

Meegul3• 9 years ago

I disagree. JavaScript is far, far from a perfect language, but if you think it's the worst one out there, you must've not payed attention to it in the past few years. I - as well as most non-self loathing JS hackers - use the ECMAScript 2015 (or later) standard, where the language is relatively feature complete. This allows JS to become a relatively complete OO language should you desire, and it also allows it to act (mostly) functionally. `const` and `let` alone fix many of the ambiguous gripes that people had with JS, and if you truly believe it's still the worst language out there, I encourage you to look at these new developments.

loppers926• 9 years ago

The Important stuff is still unfixed

For instance:

- javascript has just one datatype for numbers, HOW CAN YOU WIRTE A NUMBERS APP WHITH PURE JAVASCRIPT SHIT, WTF?. - Debugging is a hell - No generic language - Slow as hell - Double meaning of many this like undefiend - etc - etc

All what you describe above is syntax sugar.

I have learning 6 programming languages (c, go, javascript, python, java and php)

nilved• 9 years ago

He said it's "one of the worst." And even people who write JavaScript admit that.

galacticpony12• 9 years ago

These new features fix nothing, they just add more things that weren't technically needed in the first place.

There is no way to "fix" Javascript without breaking compatibility. It will always suffer from its poor initial design decisions, or it will stop actually being Javascript.

makmanalp• 9 years ago

As a sidenote, does anyone know how this emscripten stuff works? I understand how you can compile down to a different language, but is there a shim layer that converts OS level API calls to browser APIs? Or is it lower level than that? Either way, that sounds like a massive undertaking and it blows my mind that any of this is even possible.

steveklabnik6• 9 years ago

Basically, yes. http://kripken.github.io/emscripten-site/docs/porting/emscri...

whatever_dude• 9 years ago

There's a bunch of maps or polyfills you can use to communicate with external features. Things like WebGL for example. So it just maps those calls to whatever functions you can provide. Or if your C code uses the file system, you can either pick a virtual file system (for web code) or a real file system (for node applications).

The opposite is also true - you have a html5.h header file you can reference to do DOM/browser manipulations from your native code.

It's pretty fascinating.

ndarilek• 9 years ago

Came here to ask exactly this question.

Further, and I don't even know if this question is a meaningful one, but are there any curated lists of libraries known to work with wasm, or do you just compile something and hope for the best? I'm curious if there are any gaming-oriented sound libraries known to work well, and with bindings to Rust? I'm a blind developer with a casual interest in building audio games, a niche gaming genre that's basically what it (har har) sounds like. Unfortunately, much of what is available is Windows-only, and I'm a Linux user. But increasingly over the past few years, the web has struck me as a great platform for building these sorts of games. You don't need a powerful CPU for one thing, and the browser's built-in TTS APIs abstract away one of the biggest platform hurdles. There really isn't a good cross-platform hook into text-to-speech systems, and often you need speech presented in ways that clash with how screen readers work.

Anyhow, I've been wanting to experiment with multi-player gaming, and Rust's new wasm support along with Firefox 52's inclusion seems like a nice bit of synchronicity. If only I could find a good audio library known to work, particularly something with spatialization.

And yes, I do know about the Web Audio API, but was disappointed to learn that its panner nodes don't support more than 2 speakers. That said, I don't know if there are any wasm-compatible libraries that'd work with Rust and support 5.1. I'm also looking for a fun project to use Rust with, and an audio game that uses the strengths of both the web and Rust might be just the thing.

Pardon the diversion, but I'm stupidly excited about using the browser as a cross-platform runtime via a language more sane than JavaScript. :)

steveklabnik6• 9 years ago

are there any curated lists of libraries known to work with wasm

I'm not aware of any specifically, but I do know at least one Rustacean who has been playing with this tweeted something like "I'm surprised but these 80 crates i've been using for advent of code work out of the box with wasm". So we'll see!

flohofwoe3• 9 years ago

I've written a blog post about some (C/C++) libraries I found working well in asm.js/wasm:

http://floooh.github.io/2016/04/09/oryol-3rd-party-code.html

All the C libraries in there should be trivial to integrate with Rust, the C++ libs might be a bit more complicated though.

For audio, I can recommend SoLoud, it's multiplatform and also works well in asm.js/wasm (and doesn't add much size):

http://sol.gfxile.net/soloud/

hackcasual• 9 years ago

Emscripten maintains a collection of ports specifically for using with asm.js/wasm: https://github.com/emscripten-ports

It's a bit spare, and certainly not comprehensive. I've personally gotten ICU and jsoncpp working with minimal effort. Basically if the library has good cross platform support it should work.

Animats• 9 years ago

This is accomplished by compiling Rust to asm.js or WebAssembly.

This seems an overly complex approach. Just because you can do it doesn't mean you should. Most of the advantages of Rust don't apply when you're targeting the Javascript engine of a browser.

Modern Javascript, as a language, isn't that bad. Use the right tool for the job.

castis• 9 years ago

If you can, but you don't, could you really?

Knowing nothing of rust development or this particular tool, could a potential benefit be that the outgoing javascript is structured ideologically similar to the rust code that went in? I'm not saying that this would be a primary reason to make this switch but surely this approach isn't without benefit or reason?

wtetzner2• 9 years ago

I can imaging cases where you'd want code to run in a browser without the unpredictability of garbage collection.

Also, modern Javascript has been the only available tool in browsers, but that doesn't mean it's a good one. asm.js and WebAssembly are making it easier to introduce new, and in many cases, better tools.

killin_dan2• 9 years ago

Why is rust still not standardized?

andrewflnr• 9 years ago

It's still growing and changing pretty quickly. Even if it was going to be standardized, it's too early now.

killin_dan2• 9 years ago

Well they've had several years already

bfrog• 9 years ago

How does rust deal with numbers in JS given that a u64 is unrepresentable in a native JS number type? Does it simply keep an array of byte values around instead?

steveklabnik6• 9 years ago

wasm != JS, basically.

The Rusty Web: Targeting the Web with Rust

Related Stories