WebAssembly the Journey

This is the slides of our presentation on BrazilJS 2017 (Porto Alegre and Fortaleza). Presented by @wmsbill and @eliamain

Transcript

1. WebAssembly The journey Elia Maino - Willian Silva BrazilJS Conf 2017
2. Who are we?
3. Willian Elia @wmsbill @eliamain Senior Junior
5. WE’RE HIRING!!
6. What is WebAssembly?
7. What’s WebAssembly? New binary format Run compiled programs (C, C++, Rust) on a browser Works alongside Javascript Performance and flexibility API
8. Looks interesting, right?
9. The Journey
10. BrazilJS 2015
12. +
13. JSConfEU 2017 +
15. +
16. The journey begun
17. Our POC: John Conway’s game of life
18. Game of life ZERO PLAYER game Matrix, each cell can be either DEAD or ALIVE The only external input is the INITIAL STATE Alive Dead
19. Game of life CURRENT STATUS NEIGHBOURS COUNT NEXT STATUS < ( ) >
20. A good example if we use big matrix
21. Our algorithm 1.Create a big matrix randomly filled with 0 and 1 2.Render the initial state and send it to the environment component 3.Generate and render the next state (loop)
22. Three approaches }Same algorithm O(n*m) complexity Render part in common VANILLA JS WEBASSEMBLY WEB WORKERS
23. Vanilla JS
24. A lot of functions function getNextState(currentState, width, height) { … } function getLineCount(currentState, column, bounds) { … } function createBounds(width, height) { … } …
25. Results
26. Vanilla JS results Next state calculation between 9ms and 4ms
27. Why so many variations in the results? JIT
28. JIT: just in time compiler Cold code -> Interpreter Warm code -> baseline compiler Hot code -> optimising compiler
29. JIT: just in time compiler Cold code -> Interpreter Warm code -> baseline compiler Hot code -> optimising compiler
30. JIT: just in time compiler Cold code -> Interpreter Warm code -> baseline compiler Hot code -> optimising compiler
31. JIT: Code life cycle 1. Parse 2. Compile 3. Optimize (de-optimize) 4. Execute 5. Garbage Collector
32. WebAssembly
33. WebAssembly is fast Parse Compile Optimize Execute GC Decode Compile + Optimize Execute JS WASM
34. WebAssembly is fast WASM is more compact -> Faster FETCH of the source WASM is closer to machine code -> Faster DECODING, COMPILING and OPTIMISING No need to RE-OPTIMISE No garbage collection
35. So WebAssembly sounds fast, let’s see how to use it
36. How to run WASM modules Current situation: not possible to run WASM modules on their own Need for some Javascript glue
37. WebAssembly JS API 1. Fetch the module binary 2. Instantiate it 3. Access exported functionalities
38. fetch('module.wasm').then(response => response.arrayBuffer() ).then(bytes => WebAssembly.instantiate(bytes, importObject) ).then(results => { // Do something with the compiled results! });
39. How to generate a WASM file
40. Compile C to WASM + JS WASM v 1.37 emcc environment.c -o environment.js -s WASM=1
41. Then we can simply import the generated JS code as a module
42. Export functions to JS Keyword EMSCRIPTEN_KEEPALIVE EMSCRIPTEN_KEEPALIVE void getNextState(int width, int height) { … } Expose only the interface of the WASM module to JS
43. What about WebAssembly memory? How can we access it?
44. We want to reproduce the same logic of our Vanilla JS implementation in C
45. The C environment has to be initialised with the first state of the game
46. Memory management Emscripten provide three useful functions to manage WebAssembly memory _malloc(memoryNeeded) getValue(ptr, type) setValue(ptr, value, type)
47. Our JS code has a reference to the C memory containing the next state Write Allocate Read Write
48. Too many memory access from JS
49. Reduce memory access One memory allocation on loading One memory write on loading One memory read on each iteration
50. We measured the performance again…
51. The WASM implementation was still slower
52. WebAssembly performance Still slightly slower than Vanilla JS
53. Why??
54. Why was WASM slower? Further investigation Simple counter test Results confirmed
55. JIT handover
56. “Currently, calling a WebAssembly function in JS code is slower than it needs to be. The JIT doesn’t know how to deal directly with WebAssembly, so it has to route the WebAssembly to something that does. … This can be up to 100x slower than it would be if the JIT knew how to handle it directly. ” Lin Clark
57. Web Workers
58. Parallel threads Promise.all()
59. Results
60. Web workers results Next state calculation between 3ms and 2ms Shared Array Buffer?
61. The future of WebAssembly
62. Browser support SHIPPED 11 SOON
63. Future features Formal Specification
 Threads supports
 SIMD acronym to Single Instruction Multiple Data (back to Stage 3 on TC39) 
 Exception handling
 Garbage collection
 Direct DOM access
 ES6 Module integration

64. Learn more https://github.com/eliamaino-fp/webassembly-js https://braziljs.org/blog/iniciando-com-webassembly-parte-1/ http://devnaestrada.com.br/2017/07/07/web-assembly.html https://github.com/mbasso/awesome-wasm/ twitter.com/wmsbill twitter.com/eliamain
65. Takeaways
66. “Learn one, do one, teach one”
67. Obrigado! Grazie! Thank you!
68. WE’RE HIRING!!