Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

Metadane

• Autorzy: Abhinav Jangda, Bobby Powers, Emery D. Berger, Arjun Guha (University of Massachusetts Amherst)
• Rok: 2019
• Źródło: 2019 USENIX Annual Technical Conference (ATC 2019), pp. 107–120
• DOI/Link: https://www.usenix.org/conference/atc19/presentation/jangda
• Status: reference
• Cytowania: ~200+
• Tagi: #reference #webassembly #performance #benchmarking #overhead-analysis

Streszczenie

Systematyczna analiza wydajności WebAssembly w porównaniu z kodem natywnym przy użyciu SPEC-CPU 2006. Wbrew oczekiwaniom, WASM jest średnio 1.55× wolniejszy od native C/C++. Autorzy identyfikują konkretne źródła tego overheadu i proponują optymalizacje.

Praca jest odpowiedzią na wcześniejsze roszczenia o “prawie natywnej” wydajności WASM — pokazuje, że rzeczywistość jest bardziej złożona i zależy od charakterystyki workloadu.

Kluczowe Wnioski

• WASM średnio 1.55× wolniejszy niż native (SPEC-CPU 2006, Emscripten → Chrome V8)
• Główne źródła overhead:
  1. Memory safety: brak rejestrów segmentów x86 → dodatkowe sprawdzenie boundów przy każdym dostępie
  2. Brak SIMD: WASM 1.0 nie wspiera instrukcji wektorowych (SSE/AVX)
  3. Brak link-time optimization: kompilator nie może optymalizować przez granicę Wasm module
  4. 64-bit pointers → 32-bit: WASM używa 32-bit linear memory (w 2019)
• Dla workloadów compute-intensive (matrix mult): overhead do 2.5×
• Dla workloadów memory-bound: overhead niższy (~1.3×)

Metodologia

Kompilacja SPEC-CPU 2006 przez Emscripten do WASM, uruchomienie w Chrome V8. Profilowanie z VTune i GDB. Analiza wygenerowanego kodu maszynowego. Platforma: Intel Xeon E5-2670 @ 2.6 GHz.

Główne Koncepcje

• Linear memory: WASM model pamięci — ciągły blok, dostęp przez 32-bit offset
• Bounds checking overhead: każdy dostęp do pamięci wymaga sprawdzenia granic (bez hardware support w 2019)
• Emscripten: kompilator C/C++ → WASM (używany do benchmarków)
• SPEC-CPU 2006: standardowy zestaw CPU-intensive benchmarków (C/C++/Fortran)

Wyniki

Średni overhead 1.55× (geometric mean). Benchmark najbardziej dotknięte to compute-intensive (h264ref: 2.5×). Autorzy proponują optymalizacje kompilatora redukujące overhead do ~1.2×.

Luka dla JE

Kluczowy gap badawczy dla projektu: praca analizuje czas wykonania, ale nie energię. Gap to:

• Czy 1.55× wolniejszy = 1.55× droższy energetycznie? NIE — DVFS, memory bandwidth, cache efficiency mają inny wpływ na energię niż czas
• WASM może być szybszy niż JS (V8 JIT) dla SPEC-CPU benchmarków, ale dla typowych serverless workloadów (I/O-bound, event-driven) relacja jest inna
• Brak porównania WASM vs JS (V8 JIT) — praca porównuje WASM vs native C, nie vs interpretowany/JIT kod

To jest podstawa dla JE-4 (Wasm vs JS energia) i JE-14 (koszt izolacji).

Powiązane Tematy

• De Macedo 2022 — bezpośredni follow-up: WebAssembly vs JavaScript energetycznie (ICT4S)
• Faasm (Shillaker 2020) — WASM jako mechanism izolacji (kontekst wydajnościowy)
• Sledge (Boucher 2020) — WASM edge runtime (podobne wnioski o overhead)
• V8 JIT — baseline JS performance (WASM vs V8 JIT to odrębne pytanie)

Notatki

Publikacja dodana jako referencja. Brak PDF — dostępna przez USENIX Open Access.