WebAssembly: The new platform the scene needs?
category: code [glöplog]
but the scene stopped coding in assembly in 1993
Someone will certainly hack a prod for it, and I look forward to the result!
PS topic 24...err...11000! :)
Quote:
PS topic 24...err...11000
OMG, something must be going on...
The idea of WebAssembly seems to be to provide a compilation target for C and C++ for the web.
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...
It seems way better to compress though so I'm curious what it will do to the 4K and 64K area...
..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?
http://quad.fi/wasmtest
quick test i threw together last week.
quick test i threw together last week.
Quote:
..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.
Basically NaCL reloaded and a new dumping ground for Unity prods. ;)
A Shadertoy-ish wasm online IDE would be neat though.
A Shadertoy-ish wasm online IDE would be neat though.
absence: so you can make bytecode out of C++, but not Javascript, the language of the browser, itself??!!!
Fucking BRILLIANT!
Fucking BRILLIANT!
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.
This, and JS being a dynamic language with a pretty terse syntax, bytecode for "full" JS wouldn't even be that much smaller.
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?
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.
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.
> 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.
Remember that quote about trying to solve a problem with regex?
Yeah.
Yeah.
Quote:
..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).
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?
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?
Quote:
True programmers... really !? So over time perhaps true programmers take over it finally?
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.
Quote:
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.
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.
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!
I especially love how they mix constant WIDTH with local "width" passed as an argument to a function - way to go!
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 ;)
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:
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:
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.
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.
