Go to bottom

WebAssembly: The new platform the scene needs?

category: code [glöplog]

It's now supported on Firefox and Chrome stable...
added on the 2017-03-11 00:45:30 by analogue analogue
but the scene stopped coding in assembly in 1993
Someone will certainly hack a prod for it, and I look forward to the result!
added on the 2017-03-11 03:29:49 by cxw cxw
PS topic 24...err...11000! :)
added on the 2017-03-11 03:30:40 by cxw cxw
PS topic 24...err...11000

OMG, something must be going on...
added on the 2017-03-11 06:46:15 by analogue analogue
The idea of WebAssembly seems to be to provide a compilation target for C and C++ for the web.
added on the 2017-03-11 09:42:27 by Adok Adok
WebAssembly is in its core just a binary representation of asm.js - so the trend of web demos will probably just continue :)

It seems way better to compress though so I'm curious what it will do to the 4K and 64K area...
added on the 2017-03-11 13:57:56 by kb_ kb_
..OK, I went to that site and I'm thoroughly confused - I don't *care* about the rest of it (what this thing IS), I just wanna know - can I write .js and have it end up running native on the chip?
quick test i threw together last week.
added on the 2017-03-11 15:59:23 by visy visy
..OK, I went to that site and I'm thoroughly confused - I don't *care* about the rest of it (what this thing IS), I just wanna know - can I write .js and have it end up running native on the chip?

As I understand, it has nothing to do with JS. It's bytecode to let you run C++ or whatever in the browser, but not natively.
added on the 2017-03-12 02:09:41 by absence absence
Basically NaCL reloaded and a new dumping ground for Unity prods. ;)

A Shadertoy-ish wasm online IDE would be neat though.
added on the 2017-03-12 09:10:33 by tomaes tomaes
absence: so you can make bytecode out of C++, but not Javascript, the language of the browser, itself??!!!

bitnaughty: The point of the wasm bytecode is that it runs in a way more restricted environment (limited memory, no GC, way less APIs) than the usual JS VM so it can directly be compiled to native code without having to check every little detail all the time.

This, and JS being a dynamic language with a pretty terse syntax, bytecode for "full" JS wouldn't even be that much smaller.
added on the 2017-03-12 17:53:44 by kb_ kb_
kb_ : OK, you just said a lot of stuff I didn't understand :), but......all I wanted to say was - I just wanna program in Javascript and have it run fast - any guy who makes it run as fast as native, has MY vote! :)

Are you in fact, knowledgable about anyone in the world making a Javascript *compiler*, ie. some way to make a executable out of it? Is such a thing even POSSIBLE (without there being a browser there??)

What's a "dynamic language" btw?

....and how do you know that stuff about wasm etc? Are you writing a browser??!! Are you knowledgable about compiler theory and stuff?
For the purpose of this discussion, a dynamic language is one that can't be compiled directly to native code. There's much more to it than that, but the bottom line is that it's generally impossible to make Javascript or other dynamic languages run as fast as native code. If you want to compile to fast native code, use C++ or other static languages.
added on the 2017-03-12 20:47:44 by absence absence
Do I really want to get into this? You can probably read the details on the webassembly site posted at the top.

> I just wanna program in Javascript and have it run fast

There's a limit to how fast a dynamic language like JavaScript can run. Anytime you access a property of an object the language has to check what type it is. That checking is what makes it dynamic. It's also one of the things that makes it slow. static languages remove all that checking.

Similarly dynamic languages usually usually have dynamic objects (objects you can add/remove properties to at runtime) as a core part of the language (JS and Python are 2 good examples that do this). Because properties can be added and removed at anytime, you you access a property it has to be looked up (searched for) on the object. Then back to the previous example, once it's looked up it's type has to be checked.

It's those 2 things that make dynamic languages easy to use but hard to make fast.

C/C++ as examples of static languages the compilers know at compile time all the types and all the properties so those lookups and checks disappear.

JavaScript already gets translated to assembly (JITed) in most browsers. It's those dynamic checks and dynamic lookups that kill perf.

WebAssembly is generic (not machine specific) assembly language. This means you can use languages other than JavaScript and they can skip the checks mentioned above.
added on the 2017-03-12 21:40:39 by greggman greggman
Remember that quote about trying to solve a problem with regex?
added on the 2017-03-13 00:47:49 by Gargaj Gargaj
..OK, I went to that site and I'm thoroughly confused - I don't *care* about the rest of it (what this thing IS), I just wanna know - can I write .js and have it end up running native on the chip?

it's ok to be confused since the webassembly site seems not to give a clear explanation about what this technology is or how exactly can a developer benefit from it...

this mdn article explains in detail what this is all about (basically what kb, absence, greggman said).
added on the 2017-03-13 01:31:53 by Defiance Defiance
Most programs people write for the Web are inefficient at algorithmic level, not language.

Take for example the very sample the MDN link above gives for a Sobel filter. Double loop, wrong average computation (lose of bits), writing out 3 components rather than 1, conditional branching for pixel fetches, per pixel function calls, sqrt? It's all super amateur, if you wrote code like that you wouldn't be hired in any game company for example. And that was an example code they chose to share...

So in a way WebAssembly at first will help bad code feel a little bit less bad. Maybe in the long term there are higher level benefits though. For example, WebAssembly opens the door to C++ developers who want to write for the Web. So over time perhaps true programmers take over it finally?
added on the 2017-03-13 20:25:26 by iq iq
So over time perhaps true programmers take over it finally?
True programmers... really !?

Did it occur to you that the purpose of that Sobel example was not to show how to write an efficient Sobel filter but to introduce people to wasm and that implementation was easy to read, worked well as an introduction and shows the impact of wasm/js ? Maybe it was not super amateur after all. Maybe not.
added on the 2017-03-13 22:17:59 by p01 p01
Most programs people write for the Web are inefficient at algorithmic level, not language.

No, they're inefficient because everyone has to reimplement the same ~50 functions (like, you know, efficient array or object or date/time manipulation or number formatting) that somehow never made it into JavaScript's standard library and now instead it's polyfill upon polyfill upon polyfill.
added on the 2017-03-14 00:09:40 by Gargaj Gargaj
When you need a library that's 20k compressed to have sane date formatting in an ecosystem that encourages de-standardizing, you can officially call the whole web fucked and throwing another language at it isn't going to fix it, in fact it'll prolly remain yet another source for random bugs for a while, which in turn will generate - you guessed it - more polyfill.
added on the 2017-03-14 00:13:16 by Gargaj Gargaj
This sobel implementation is truly suspicious. It's like somebody is ruining the performance on purpose (not to mention writing bad code on purpose), and strangely on both ends (C and JS). Trivia: this "great" code is licensed from some dude and used under permission, so yeah, it's like big wtf

I especially love how they mix constant WIDTH with local "width" passed as an argument to a function - way to go!
added on the 2017-03-14 00:25:05 by tomkh tomkh
As for WebAssembly/asm.js: it would be nice if done right + if it is compatible on all browsers. So, I hope this "example" is just an accident and does not reflect the quality of the rest ;)
added on the 2017-03-14 01:04:11 by tomkh tomkh
Here's what excites me about WebAssembly, from a demoscene perspective. I know my way around JS and web APIs, I'm a relative n00b at anything involving GPUs, and I want to get into writing WebGL demos. The sensible thing would be to pick up three.js, but as a demoscener I want to fully grok the low-level details, and I'm prepared to reinvent as many wheels and shave as many yaks as I damn well need to.

The 64K intro world has taught us all the importance of a decent workflow for iterating on ideas quickly, minimising the code-writing drudgery required to go from idea in your head into something on screen. Which means that if I've written a shader, and I want to throw some uniforms and polygons at it, my Javascript-writing brain wants to be able to write something like:
Code: shader.camera = [0, 0, 0]; shader.draw(duck_3ds);

But because WebGL is actually just a C API transplanted into the browser using chewing gum and string, rather than an actual web technology, I have to write:
Code: var cameraUniform = gl.getUniformLocation(shader, 'camera'); gl.uniform3fv(cameraUniform, new Float32Array([0, 0, 0])); gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, duck_3ds.bufferAddress); gl.drawElements(gl.TRIANGLES, duck_3ds.bufferLength, gl.UNSIGNED_SHORT, 0);

With a bit of work, I could write a load of wrapper functions to hide the low-level GL calls, keep track of all the types and pointers, and let me write code that looks like the first example - but then the Javascript interpreter has to fight through that wrapper code on every frame we render... and that wrapper code is full of Stuff That Javascript Can't Do Efficiently, like hash table lookups and function calls that have no idea what sort of objects you're passing. So it seems like what I really want is a compilation step that takes my friendly OOP-ish code (which in my ideal world is idiomatic Javascript, but it presumably needs static type-checking, and JS-plus-types is basically back to C again, so who knows) and converts it to a big long unreadable sequence of GL calls.

And that's basically as far as I've got on the WebGL-demotool-world-domination path at the moment. WebAssembly will mean that my notional "high-level language to GL gunk" compiler can target WebAsm directly, and cut out the Javascript middle-man.

I think that might have been a TL;DR way of saying "WebAssembly is great because Javascript is shitty at interfacing with OpenGL". Oh well.
added on the 2017-03-14 04:02:54 by gasman gasman


Go to top