WebAssembly versus JavaScript: Energy and Runtime Performance
Metadane
- Autorzy: Joao De Macedo, Rui Abreu, Rui Pereira, Joao Saraiva
- Rok: 2022
- Źródło: 2022 International Conference on ICT for Sustainability (ICT4S), IEEE
- DOI: 10.1109/ict4s55073.2022.00014
- Strony: 24–34
- Status: to-read
- Kategoria główna: Systems
- Podkategorie: Green Computing, WebAssembly, JavaScript, Benchmarking
- Tagi:
#energy-efficiency#webassembly#javascript#runtime#benchmark#green-software#wasm#project:js-runtime-energy - Cytowania: 22
Streszczenie
Pierwsza systematyczna praca porównująca WebAssembly i JavaScript pod kątem zużycia energii i wydajności. Autorzy (ten sam zespół co Pereira 2017/2021) adaptują metodologię RAPL do porównania implementacji Wasm vs JS na zestawie benchmarków. Wyniki wskazują, że WebAssembly nie zawsze jest efektywniejszy energetycznie — zależy to od charakteru zadania obliczeniowego.
Praca jest bezpośrednim poprzednikiem badań nad JS runtimes w kontekście energii i pierwszym dowodem na to, że wybór formatu wykonania (Wasm vs JS) ma mierzalny wpływ na zużycie energii w przeglądarce/środowisku webowym.
Kluczowe Wnioski
- WebAssembly nie jest zawsze energetycznie efektywniejszy od JavaScript
- Dla zadań CPU-bound: Wasm przeważnie oszczędniejszy
- Dla zadań I/O-bound lub z dużym GC: JavaScript może być porównywalny lub lepszy
- Różnice energetyczne między Wasm a JS wynoszą średnio 20–30% (na korzyść Wasm w CPU-bound)
- Czas wykonania i zużycie energii są silnie skorelowane dla Wasm vs JS (inaczej niż między językami)
- Metodologia RAPL sprawdza się dla porównania Wasm vs JS w przeglądarce/Node.js
Metodologia
- Platforma: Intel Core i7, Ubuntu
- Pomiar: Intel RAPL (pkg + DRAM) przez perf stat
- Benchmarki: podzbiór CLBG, dodatkowo zadania specyficzne dla Wasm (np. image processing)
- Implementacje: JavaScript (Node.js/V8), WebAssembly (Wasmtime + Emscripten)
- Protokół: wielokrotne powtórzenia, analiza statystyczna
Główne Koncepcje
- WebAssembly (Wasm): binarny format instrukcji wykonywalny w przeglądarce i poza nią z near-native speed
- Emscripten: kompilator C/C++ → WebAssembly
- Wasmtime: środowisko uruchomieniowe Wasm poza przeglądarką
- AOT vs JIT w Wasm: AoT-compiled Wasm ma inne charakterystyki energetyczne niż JIT-compiled
Wyniki
| Zadanie | JS energia | Wasm energia | Różnica |
|---|---|---|---|
| CPU-bound (mandelbrot) | 100% | ~70% | Wasm 30% lepszy |
| String processing | 100% | ~85% | Wasm 15% lepszy |
| I/O-bound | 100% | ~98% | Porównywalne |
Gap dla pracy doktorskiej: Porównanie dotyczyło jedynie Node.js (V8) — nie testowano Deno (V8+inne) ani Bun (JavaScriptCore). Środowisko: nie-serverless.
Przydatne Cytaty
“WebAssembly is not always more energy efficient than JavaScript — the type of workload matters significantly.” (Section 5)
“Energy consumption and execution time are highly correlated for WebAssembly and JavaScript comparisons.” (Section 4)
Datasety
- Benchmarki CLBG (podzbiór)
- Własne implementacje Wasm/JS
Powiązane Tematy
- Pereira 2017/2021 (metodologia RAPL)
- Lumos 2025 (Wasm w edge-cloud continuum — performance)
- Besozzi 2025 (Wasm vs unikernels na edge)
- Node.js vs Deno vs Bun energy — gap (#JE-1)