The document discusses WebAssembly (Wasm), a new binary format that allows for running compiled programs in browsers more efficiently than JavaScript. It illustrates the implementation of John Conway's Game of Life using both Wasm and JavaScript, comparing their performance metrics and highlighting challenges with JIT compilation. Future improvements for WebAssembly, including enhanced browser support and features such as SIMD and exception handling, are also mentioned.

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. JIT handover

58. Web Workers

59. Parallel threads
Promise.all()

60. Results

61. Web workers results
Next state calculation between 3ms and 2ms
Shared Array Buffer?

62. The future of
WebAssembly

63. Browser support
SHIPPED 11 SOON

64. 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

65. 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

66. Takeaways

67. “Learn one, do one, teach
one”

68. Obrigado!
Grazie!
Thank you!

69. WE’RE HIRING!!