Upgrade to Pro — share decks privately, control downloads, hide ads and more …

WebAssembly the Journey

WebAssembly the Journey

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

E807477655ad7125c8731065178030e2?s=128

Willian Martins

September 02, 2017
Tweet

More Decks by Willian Martins

Other Decks in Technology

Transcript

  1. WebAssembly The journey Elia Maino - Willian Silva BrazilJS Conf

    2017
  2. Who are we?

  3. Willian Elia @wmsbill @eliamain Senior Junior

  4. None
  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

  11. None
  12. +

  13. JSConfEU 2017 +

  14. None
  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!!