Compiling Rust to your Browser

class: center, middle, less-space, dark-bg, title

# Compiling Rust to your Browser

### [Rust Cologne/Bonn](https://www.meetup.com/Rust-Cologne-Bonn/events/233139845/) — 2016-09-05
### Jan-Erik Rediger — [@badboy_](https://twitter.com/badboy_)

---
class: center, middle

# **Warning**: there will be gifs, there will be tweets.

???

Zu allererst: Meine Slides enthalten animierte gifs. Ich hoffe damit hat keiner ein Problem.

---
class: gif
background-image: url(media/js.jpg)

???

Am Anfang waren Webseiten ziemlich statisch.
Bis 1995 dann JavaScript dazu kam.
Damit war es möglich dynamisch Benutzerinteraktionen auszuwerten,
Inhalte zu ändern oder zu erweitern.

Am Anfang war das alles noch recht simpel und zumeist langsam. JavaScript war eine rein interpretierte Sprache.
Dann nutzten mehr und mehr Leute JavaScript in immer größerem Umfang und die JavaScript Engines mussten nachziehen.
Daher haben wir nun hoch-optimierte Engines wie v8 und SpiderMonkey, mit JIT oder sogar AOT-Compilation.

Irgendwann fingen Leute an andere Sprachen zu JavaScript zu kompilieren.
Google mit GWT: Java (2006)

2008/2009 v8/TraceMonkey

---
class: center, middle, imgnormal

![Emscripten](media/emscripten-logo.png)

## LLVM to JavaScript compiler

## Run C on the web at near-native speed

???

2010: Emscripten
Nimm C oder C++, schmeiß es durch LLVM, kompiliere LLVM Output zu (low-level) JavaScript
Most code: libraries + toolchain + tests
Optimizer auf JavaScript

near-native speed

---
class: gif
background-image: url(media/why.gif)

???

ihr fragt warum?

---
class: center, middle

# Compile to the web

### JS is standards-based, runs everywhere
### Avoid high cost of porting code
### Reuse existing native libraries

???

JavaScript ist ein Standard, es läuft überall. Vom Smartphone bis zum Server

Große Projekte brauchen nicht zwangsläufig portiert werden, recompile them!

1000e native libraries → reuse

---
class: center, middle

# [asm.js](http://asmjs.org/)

## a subset of JavaScript

???

Emscripten kompiliert zu normalem JavaScript. Jede Engine kann es ausführen.
Aber: es ist vorab optimiert. Engines können Code noch besser optimieren.

asm.js: Spezifikation eines Subsets von JavaScript, basierend auf dem was Emscripten schon auswirft
Engines optimieren das schon. Mit expliziten Annotationen: Parsing Overhead sparen, AoT Compilation

---
class: center, middle, twitter

<blockquote class="twitter-tweet" data-lang="en">asm.js code is very simple and low-level, and as a result easy— Horse JS (@horse_js) <a href="https://twitter.com/horse_js/status/575000441177550848">March 9, 2015</a></blockquote>

???

asm.js als Subset ist simepl und damit easy, right?

---
class: middle, code, big

# (Implicitely) typed

```javascript
function add(x, y) {
  x = x|0;
  y = y|0;
  return (x + y)|0;
}
```

???

JavaScript kann implizit typisiert sein
asm.js spezifiziert das genauer.

Simple Funktion. Binäres Oder mit 0 ändert Wert nicht.
Addition von zwei unveränderten Werten und dann Binäres Oder ändert auch nix.

---
class: middle, code, big

# (Implicitely) typed

```javascript
function add(x, y) {
* x = x|0; // 32-bit value
  y = y|0;
  return (x + y)|0;
}
```

???

Was impliziert passiert: x wird als 32-bit integer interpretiert.
Addition wird zu 32-bit integer addition in modernen JS VMs
JIT compilation zu simplem ADD statement.

Engines erkennen das, können das optimieren.
Firefox kann asm.js Code sogar AOT kompilieren.

---
class: middle, code, big

# Emulated heap

```c
size_t strlen(char *ptr) {
  char *curr = ptr;
  while (*curr != 0) {
    curr++;
  }
  return (curr - ptr);
}
```

???

Memory Model von Sprachen wie C und C++: memory buffer & pointer
Wild im Speicher rumzeigen
Pointer Arithmetik

strlen: Zähle einfach Abstand von Zeiger auf Nul von ursprünglichem Zeiger

---
class: middle, code, big

# Emulated heap

```javascript
function strlen(ptr) {
  ptr = ptr|0;
  var curr = 0;
  curr = ptr;
  while (HEAP8[curr]|0 != 0) {
    curr = (curr + 1)|0;
  }
  return (curr - ptr)|0;
}
```

???

In JavaScript: Heap als Typed Array. Pointer = Offsets im Array. Byte-Access mit expliziten Integers.
Vorteil: gleiches Memorymodel wie C/LLVM → keine aufwendige Portierung nötig
Nachteil: Overhead für kleine, kurzlaufende Programme, da Array immer allokiert

dynamisch wachsender Heap möglich, aber komplexer

Läuft heute, wird benutzt!
Emscripten wirft (wenn möglich) korrekt annotiertes asm.js aus → Spiele/Grafikanwendungen, etc. möglich

---
class: center, middle

# [WebAssembly](https://webassembly.github.io/)

## a new portable, size- and load-time-efficient format suitable for compilation to the web.

???

Neues Target: WebAssembly.

a new portable, size- and load-time-efficient format suitable for compilation to the web.

bisschen viel, also noch mal

---
class: center, middle

# [WebAssembly](https://webassembly.github.io/)

## a new portable, size- and load-time-efficient format suitable for compilation to the web.

???

a new format suitable for compilation to the web.

ein neues Format also, was ebenfalls jeder Browser verstehen soll.
Hatten wir das nicht schon mal? Ja, Flash und Java-Applets und sonstige Plugins.

Was ist dieses Mal besser?
Browser-Vendors sitzen zusammen, wollen JavaScript nicht ersetzen, wollen es erweitern.

---
class: center, middle, twitter

<blockquote class="twitter-tweet" data-lang="en">I ❤️ some hypothetical future WebAssembly— Horse WebAssembly (@horse_wasm) <a href="https://twitter.com/horse_wasm/status/753362742115835904">July 13, 2016</a></blockquote>

???

Die Arbeitsgruppe hinter WebAssembly ist erst letztes Jahr gegründet worden.
Ergeizige Ziele, PoC bereits in Chrome und Firefox, ihr müsst es nur aktivieren

wie zeige ich später noch

---
class: gif,
background-image: url(media/bojack-laugh.gif)

???

horsing around
(sorry, ich fand das gif einfach gut)

---
class: middle, code, increased

# Abstract Syntax Tree

```lisp
(module
  (epxort $add "add" $add)
  (func $add (param $x i32) (param $y i32)
             (result i32)
    (i32.add
      (get_local $x)
      (get_local $y)
    )
  )
)
```

???

WebAssembly definiert sein Format als AST mit Textrepräsentation als S-Expressions.

---
class: center, middle, twitter

<blockquote class="twitter-tweet" data-lang="en">Soon everyone will write Lisp like it's assembly. Well, webassembly, but still. (from <a href="https://t.co/J4k2KJEZTp">https://t.co/J4k2KJEZTp</a>) <a href="https://t.co/TFoCLYuE3G">pic.twitter.com/TFoCLYuE3G</a>— intish|0 (@badboy_) <a href="https://twitter.com/badboy_/status/661172038514704388">November 2, 2015</a></blockquote>

???

Generic Lisp joke necessary here.

---
class: center, middle

# Wasm

## a binary format (of the AST)
## fast to parse
## native support in Chrome & Firefox *

.footnote[\* experimental]

???

Aber als Textformat ist es nicht unbedingt viel besser als JavaScript, benötigt immer noch mehr oder weniger aufwendiges Parsing.
Daher: binäres Format, aber 1:1 Translation zu Textformat möglich

das macht es schnell und effizient zu parsen, klein und darüber hinaus noch kompressierbar.

Nativen Support gibt es wie gesagt in Chrome & Firefox

---
class: gif
background-image: url(media/why2.gif)

???

Ihr fragt sicherlich wieder: wieso?

---
class: center, middle

# Why WebAssembly

## faster decoding than JavaScript (up to 20×)
## less restrictions than asm.js
## thread & SIMD support *

.footnote[\* planned]

???

Es ist sehr viel schneller, Experimente zeigen bis zu 20x schneller

Es hat weniger restriktion als asm.js, es ist eben kein JavaScript mehr

Es ist leichter thread & SIMD Support zu integrieren
Beides ist geplant für Stage 2, aber nicht für den derzeitigen MVP.

---
class: center, middle

# The story with Rust

## It worked once *

.footnote[\* It was hacky]

???

Nun wo wir wissen was emscripten, asm.js und WebAssembly sind, kommen wir endlich zu Rust.

Wie schaut's da aus? Naja, es ging mal, aber es war sehr hacky. Meist musste man Upstream zurecht patchen, das richtige LLVM von Emscripten kompilieren und der resultiernde Compiler konnte dann Emscripten, aber den Rest nicht mehr.
Das reichte für Beispiele, aber das reicht nicht um als ernste Alternative angesehen zu werden.

Die Sache ist: Emscripten benutzt einen eigenen Fork von LLVM.
Einige Upstream-Patches sind integriert, aber die gemeinsame Basis fehlt.
Good for us: Emscripten arbeitet daran kompatibler zu Upstream-LLVM zu sein.

---
class: center, middle, huge, gif
background-image: url(media/yes-finally2.gif)

# [#34743](https://github.com/rust-lang/rust/pull/34743)

???

Also war die Aufgabe Nr 1 dem von rustc benutzten LLVM ein Update zu verpassen.
Bislang unterstützte rustc LLVM 3.7 und 3.8.

Nach nur 167 comments, 33 commits, 22 changed files, dutzenden unabhängigen Buildbot-Runs und 5 bors retries
hatten wir das Upgrade dann endlich durch.

Warum das ganze? Emscripten selbst ist auch nah an 3.9 dran
Einfacher Emscripten's Patches auf 3.9 anzuwenden.

---
class: center, middle, gif, white-text
background-image: url(media/doh.gif)

# [Only 10 more steps](https://gist.github.com/badboy/5b905e71cf41a83724da9f96ee14b5fe)

???

Mit dem LLVM-Upgrade sind es nun nur noch 10 weitere Schritte bis zu einem Compiler der zu JavaScript kompiliert.
Davon nur 2 minimale Änderungen an rustc selbst, welche hoffentlich auch bald Upstream sind
Nicht optimal, aber immerhin sehr viel besser als die Hacks zuvor.

---
class:

# [Next plans (#33205)](https://github.com/rust-lang/rust/issues/33205)

## Ignore failing tests
## Merge Emscripten's LLVM
## Add build machines
## Add Wasm target
## Create compelling Rust-on-Wasm demos

???

Natürlich ist die arbeit damit nicht abgeschlossen.
Es gibt schon Pläne wie wir fortfahren.
Zuerst einmal: der aktuelle Build kann nicht alle Tests laufen lassen.
Ein Großteil der Tests basiert auf dem Ausführen von Threads oder externen Programmen, was nicht möglich ist im Esmcripten-Build. Diese müssen alle ignoriert werden.

Danach müssen wir die Emscripten Patches in den LLVM-Fork von Rust integrieren.

Sobald das geschehen ist, können wir automatisierte Builds für das emscripten-Target laufen lassen.
Danach werden wir uns dann drum kümmern auch ein WebAssembly Target zu bekommen.
Emscripten selbst hat dafür ein Backend, was wir benutzen wollen.

Und zu guter letzt brauchen wir Demos oder Applikationen die WebAssembly oder auch asm.js ausnutzen.

---
class: center, middle

# Rust to Wasm

## Remember MIR?

???

Bevor wir hier fertig sind, aber noch eins: Wir wollen jetzt schon Rust zu WebAssembly kompilieren.
Erinnert ihr euch noch an MIR?

Das ist die neue Intermediate Representation von Rust.

---
class: center, middle

# Rust to Wasm

## New backend for rustc
## In parallel to other efforts
## works today: [mir2wasm](https://github.com/brson/mir2wasm)

???

Die Idee ist folgende: Anstatt auf LLVM & Emscripten zu vertrauen, bauen wir einfach ein zweites Code Generation Backend für rustc.
Das ganze passiert schon unabhängig von der Arbeit an Emscripten.

mir2wasm, setzt auf dem MIR-Interpreter miri auf und benutzt die API eines bestehenden WebAssembly-Compiler.

---
class: middle, code, increased

## Rust

```rust
fn add(x: i32, y: i32) -> i32 {
    x + y
}
```

???

Wir wollen diesen simplen Rust-Code also zu WebAssembly kompilieren.

simple Addition zweiter Zahlen

---
class: middle, code

## MIR

```rust
fn add(arg0: i32, arg1: i32) -> i32 {
    scope 1 {
        let var0: i32;            // "x" in scope 1 at fact.rs:2:12: 2:13
        let var1: i32;            // "y" in scope 1 at fact.rs:2:20: 2:21
    }
    let mut tmp0: i32;
    let mut tmp1: i32;

bb0: {
        var0 = arg0;              // scope 0 at fact.rs:2:12: 2:13
        var1 = arg1;              // scope 0 at fact.rs:2:20: 2:21
        tmp0 = var0;              // scope 1 at fact.rs:3:5: 3:6
        tmp1 = var1;              // scope 1 at fact.rs:3:9: 3:10
        return = Add(tmp0, tmp1); // scope 1 at fact.rs:3:5: 3:10
        goto -> bb1;              // scope 1 at fact.rs:2:1: 4:2
    }

bb1: {
        return;                   // scope 1 at fact.rs:2:1: 4:2
    }
}
```

.footnote[rustc -Z unstable-options --unpretty mir -O add.rs]

???

Wenn wir das zu MIR kompilieren sieht das ganze schon etwas komplexer aus.

aber man erkennt noch die operationen: tmp0 + tmp1
return wert wird zurückgegeben

---
class: middle, code, increased

## Wast

```lisp
(func $add (type $rustfn-0-2)
           (param $0 i32) (param $1 i32)
           (result i32)
  (i32.store
    (i32.const 0)
    (i32.load
      (i32.const 0)
    )
  )
  (i32.add
    (get_local $0)
    (get_local $1)
  )
)
```

???

Zu Wast, der Text-Repräsentation von WebAssembly, kompiliert sieht das dann so aus.

Fragt mich nicht warum es da den store/load/store macht. In diesem Falle ist der glaub ich nicht zwangsläufig nötig.

---
class: center, middle, huge

# Demo time

???

Ok, genug erklärt und geredet. Zeit für ein paar Demos.

Ich hab einen fertigen Rust Compiler mit Emscripten Support rumliegen und mal rumgespielt.

---
class: center, middle

# [SHA1 Example](http://www.hellorust.com/emscripten/sha1/)

---
class: center, middle

# [Teapot Example](http://www.hellorust.com/emscripten/teapot/)

---
class: middle, center

# [Wasm Example](http://www.hellorust.com/emscripten/wasm-fact/)

---
class: middle, center

# Questions?

## [www.hellorust.com/emscripten](http://www.hellorust.com/emscripten/)

???

Jetzt ist noch Zeit für Fragen!

---
class: center, middle

# Hands-on time

---
class: center, middle

# [play.hellorust.com](http://play.hellorust.com/)

---
class: middle, increased

```shell
$ docker pull janerik/rust-emscripten:latest
$ docker run --rm -t -i janerik/rust-emscripten:latest
```

.footnote[~2GB download, on USB available]