With an ever-increasing percentage of the human population connected to the internet, the amount of data produced and processed is at an all-time high. Edge Computing has emerged as a paradigm to handle this growth and, combined with 5G, enables complex time-sensitive applications running on resource-restricted devices. This master thesis investigates the use of WebAssembly in the context of computa¬tional offloading at the Edge. The focus is on utilizing WebAssembly to move computa¬tional heavy parts of a system from an end device to an Edge Server. An objective is to improve program performance by reducing the execution time and energy consumption on the end device. A proof-of-concept offloading system is developed to research this. The system is evaluated on three different use cases; calculating Fibonacci numbers, matrix multipli¬cation, and image recognition. Each use case is tested on a Raspberry Pi 3 and Pi 4 comparing execution of the WebAssembly module both locally and offloaded. Each test will also run natively on both the server and the end device to provide some baseline for comparison.

JavaScript has been the de-facto standard programming language for Web browsers for some time. Although it has enabled the interactive and complex web pages we have today, it has long been characterized by performance issues. A promising new technology, WebAssembly, aims to enable near-native performance on the Web. WebAssembly is a binary instruction format designed as a compilation target for programming languages like C/C++. This allows developers to deploy their applications for execution in a Web browser environment.  Previous benchmarks have examined the performance of WebAssembly and observed a varying performance slowdown of 10% to around 55% slower than native. Recent additions to the WebAssembly standard, such as the support for SIMD instructions and multithreading, enables even greater performance and new benchmarks need to be constructed.  This thesis explores the performance implications of these new features by applying them in the domain of digital image processing, which is particularly suited for such optimizations. The OpenCV library was used to construct two benchmark suites, one running natively and one running in two different Web browsers using WebAssembly. The results of the benchmarks indicate that, although in some cases performance approached native performance, the mean slowdown was approximately double compared to native code.

WebAssembly als Kompilierungsziel bietet die Möglichkeit, nativen Code im Browser auszuführen. JavaScript ist seither nicht mehr die alleinige Programmiersprache im Web. Darüber hinaus wird WebAssembly zunehmend auch im Serverbereich eingesetzt. Diese Arbeit gibt einen Überblick über die Grundlagen und stellt den praktischen Nutzen der Technologie in der Webentwicklung dar. Dazu wurde eine Beispielanwendung entwickelt, die WebAssembly zur Bildverarbeitung einsetzt. Im Vergleich zu einer serverseitig umgesetzten Alternativanwendung wird das Potential von WebAssembly aufgezeigt. Die Ausführungsgeschwindigkeit wird zudem mit einer nativen Anwendung verglichen. Die durchgeführten Tests zeigen, dass der Einsatz von WebAssembly eine sinnvolle Alternative zur Bewältigung serverseitiger Aufgaben traditioneller Anwendungen darstellt. Bei der Verwendung von WebAssembly ergeben sich in den Untersuchungen signifikant schnellere Laufzeiten von bis zu 8-facher Geschwindigkeit. WebAssembly birgt ein enormes Zukunftspotenzial, die Internetlandschaft grundlegend zu transformieren und Entwicklern eine Vielzahl neuer Möglichkeiten zu eröffnen.:Abstract Abkürzungsverzeichnis 1. Einleitung 2. Geschichte 2.1. Vorgänger-Technologien 2.1.1. Plug-in Basierte Systeme 2.1.2. Browserintegrierte Systeme 2.2. Evolution von WebAssembly 3. Anwendungsbereiche 3.1. Im Browser-Kontext 3.2. Außerhalb des Browser-Kontexts 4. Konzeptionelle Hintergründe 4.1. Grundlagen von JavaScript 4.1.1. Merkmale und Prinzipien 4.1.2. Funktionsweise von JavaScript im Browser 4.2. Just-In-Time Kompilierung (JIT) 5. Grundlagen von WebAssembly 5.1. Funktionsweise 5.1.1. Erstellung der WebAssembly-Module in der Entwicklungsumgebung 5.1.2. Laden der WebAssembly-Module im Browser 5.1.3. Ausführung der WebAssembly-Module in der Zielumgebung 5.1.4. Geschwindigkeitsvergleich von WebAssembly und JavaScript im Browser 5.2. Vor- und Nachteile 5.3. Momentaner Entwicklungsstand 6. Konzeption einer Beispielanwendung 6.1. Anforderungen und Voraussetzungen 6.2. Entwicklungsvorgang 6.2.1. Beispielanwendung in WebAssembly 6.2.2. Vergleichsanwendung in Node.js 6.3. Durchführung der Messreihen 6.3.1. Voraussetzungen 6.3.2. Testumgebungen 6.3.3. Vorgehensweise 7. Ergebnisanalyse nach Einflussfaktoren 7.1. Implementierung 7.2. Umgebung 7.3. Hardware 8. Diskussion 8.1. Methodenkritik 8.2. Verbesserungsvorschläge 9. Zusammenfassung und Ausblick 9.1. Erkenntnisse und Fazit 9.2. Vorschläge für zukünftige Arbeiten 9.3. Ausblick in die Zukunft Literaturverzeichnis Selbstständigkeitserklärung Danksagung

WebAssembly is Assembly-like code that is created by compiling other languages into Wasm. The Wasm file can then be run on the web at near native speed. The objective of this study is to find how WebAssemblys runtime compares to JavaScript and native. The study will also see if different browsers impact WebAssembly runtime. To get the information two different methods were used. Firstly literature and articles were used to gather data on JavaScript and native runtime compared to WebAssembly. Secondly an empirical study was conducted to compare four different browsers WebAssembly runtime.  When comparing WebAssembly and JavaScript it was found that WebAssembly isn't always the fastest alternative due to many reasons but some major ones were how they were compiled and optimised.  When looking at WebAssembly compared to native we could clearly see that WebAssembly was slower. These slowdowns came primarily from the increase in code size but the virtual environment and security checks also contributed to this.  After the empirical study we could see some differences between browsers both in compilation speed and execution time. Between the chromium browsers the difference in execution time was very small and Firefox was always faster. But when looking at compilation time Chrome was faster with the other browsers having varying results. The research could conclude that WebAssembly can provide a useful boost to runtime on websites when used correctly. It is not something that is going to replace JavaScript but can be used together with it. We could also conclude that the user's choice of browser has a small impact on WebAssembly and can cause differences in runtime.

Fully autonomous cars are on the horizon. Knightec wants to enable passengers of the future car to be more productive and entertained with a new web platform. With this platform, Knightec wants to explore different input methods one of which being a voice assistant. A key component in a voice assistant is Automatic Speech Recognition (ASR) and for this task, Knightec had planned to use the new Web Speech API. Their target platform (Oculus Quest 2) does not yet support the Web Speech API and a future implementation could be limited. This thesis conducts a comparative study to find alternatives for running ASR in a web application. The study aimed to compare browser-implemented ASR methods to server implemented methods with Web Speech API as a baseline. The study first conducted a document study to find methods for running ASR tasks inside a web application and then create requirements for method selection. With the requirements, two suitable implementations were found for a browser implementation of ASR. During the final implementation, one of these failed, leaving only one method implemented in the browser. Three ASR methods were chosen for the server implementation, following requirements also set by the document study. To compare the ASR methods a dataset was created with the help of Knightec. The dataset consists of 10 commands, utilizing the voices of six individual employees at Knightec including separate versions, one with and one without background noise for each voice totaling 120 recordings. The dataset was used as a benchmark for each implementation where Word Error Rate (WER) and response time were measured. Due to the structure of the Web Speech API, it was not possible to measure response time for this implementation. The result of the benchmark shows that Web Speech API consistently outperforms the other methods in terms of WER. The response times of the browser implementation could not keep up with the other methods implemented and is not in the range of acceptable results. The recommended implementation for Knightec is to use a server-based implementation while for the general case Web Speech API is the best alternative.

One problem that has been plaguing software development is the multitude of platforms that are available to users. Consequentially, a company needs to provide its service on multiple devices, running different operating systems, in order to reach as many end-users as possible. This leads to increased development complexity and costs. To solve this issue, multiple cross-platform solutions have been proposed throughout the years. One such solution is Progressive Web Application, a set of techniques that aim to create web applications with features that have traditionally only been available to native applications. In recent years WebAssembly, a compilation target that allows languages other than JavaScript to run on the browser, has been introduced. With its compact binary format and compiled nature, its goal is to bring speed and performance enhancement to web applications. This thesis analyzes WebAssembly in the context of building a Progressive Web Application, particularly the impacts it has on the performance and memory usage. A comparison is made with the JavaScript library ReactJS. The results indicate that a Progressive Web Application built with WebAssembly achieves similar performance results as one built using ReactJS when it comes to computers, but performs worse on mobile platforms. The results also indicate that using a programming language such as Rust, although still introducing memory overhead, minimizes the bundle size and runtime memory consumption of the application. / Ett problem som har plågat mjukvaruutveckling är mängdenplattformar som är tillgängliga för användare. Följaktligen måste ett företagtillhandahålla sin tjänst på flera enheter, som kör olika operativsystem,för att nå så många slutanvändare som möjligt. Detta leder till ökadutvecklingskomplexitet och kostnad. För att lösa detta problem har flera plattformsoberoendelösningar föreslagits genom åren. En sådan lösning är Progressiva Webapplikationer, en samling tekniker som syftar till att skapa webbapplikationer med funktioner som traditionellt bara varit tillgängliga förmobilapplikationer. Under de senaste åren har ett verktyg som ger andra språk än JavaScript möjligheten att köras i webbläsaren introducerats. Detta verktyg är WebAssembly. Med sitt kompakta format och kompilerade natur, har den som mål att förbättra prestanda för webbapplikationer. Detta arbete analyserar WebAssembly i samband med utvecklingen av en Progressiv Webapplikation, specifikt inverkan den har på prestanda och minnesanvändning. En jämförelse görs med JavaScriptbiblioteket ReactJS. Resultaten tyder på att en Progressiv Webapplikation byggd med WebAssembly uppnår liknanderesultat som en byggd med ReactJS när det kommer till datorer, men presterar sämre på mobila plattformar. Resultaten visar också att användningen av ett programmeringsspråk som Rust minimerar paketstorleken och minnesanvändningen av applikationer även om det fortfarande introducerar minneskostnader.

WebAssembly (Wasm) has emerged as a new technology for the web that enables complex and interactive web applications, while utilizing a compact and platform-independent bytecode format. Due to its flexibility, portability, and built-in security, it has since evolved to be used in many other embeddings, such as internet-of-things, server applications, and even mobile applications. While a goal of Wasm is near-native performance, research has found that its performance is not as great as initially expected. Due to this, projects like The WebAssembly Pre-Initializer (Wizer) have emerged as potential solutions to this problem. Wizer is a tool developed by the coalition Bytecode Alliance with the purpose of speeding up the startup time, or Critical Path to Interactive (CPTI), of a Wasm module by pre-initializing it and saving a snapshot of the Wasm instance state into a new Wasm module. Wizer has been evaluated using two benchmark programs. However, no larger-scale investigation into the CPTI improvement brought by its pre-initialization has been conducted. Furthermore, saving a snapshot of the module is likely to result in a larger module in terms of file size, leading to increased compile time or, for use cases where it is relevant, network latency. This project investigates, mainly within the field of Wasm in non-web environments, the extent to which Wizer is able to improve CPTI for a Wasm module. The purpose of this is to allow both Wasm maintainers and developers to form an opinion whether pre-initialization could be standardized for use in Wasm compilers and toolchains, or whether pre-initialization should be applied to their Wasm module based on its CPTI before pre-initialization. Results are obtained by compiling a number of sample software down to Wasm, measuring their CPTI in terms of elapsed CPU cycles both without and with pre-initialization using Wizer, and comparing them. This is made possible through an extension to the Sightglass benchmarking framework also developed by Bytecode Alliance. The results show that pre-initialization using Wizer increases the CPTI if the Wasm module cannot be compiled to native CPU instructions in advance. However, if compilation can be done in advance, Wizer is able to reduce the CPTI of a Wasm module by a factor of between two to six times, depending on how it is initialized. / WebAssembly (Wasm) har framträtt som en ny teknik för webben som möjligör komplexa och interaktiva webbapplikationer, genom ett kompakt och platformsoberoende bytekodformat. Tack vare teknikens flexibilitet, portabilitet och inbyggd säkerhet, har den även utvecklats till att användas i andra samanhang, exampelvis i sakernas internet, serverapplikationer, och även mobilapplikationer. Trots att ett mål med Wasm är prestanda jämförbar med native applikationer, har forskning funnit att den inte presterat så väl som man tidigare trott. Därför har project som The WebAssembly Pre-Initializer (Wizer) framträtt som möjliga lösningar till detta problem. Wizer är ett verktyg utvecklat av koalitionen Bytecode Alliance med syftet att snabba upp uppstartstider, även kallat Critical Path to Interactive (CPTI), av en Wasm modul genom att förinitialisera den och spara en ögonblicksbild av Wasm instansens tillstånd som en ny Wasm modul. Wizer har evaluerats genom två testprogram. Dock har inte någon storskalig undersökning utförts inom CPTI-förbättringen som dess förinitialisering kan medföra. Dessutom är det sannorlikt att sparandet av en ögonblicksbild av en modul leder till en filstorleksmässigt större modul, vilket gör att kompileringstiden, och även nätverkslatensen i användningsfall där det förekommer, kan öka. Det här projektet undersöker, huvudsakligen inom Wasm utanför webbläsaren, omfattningen av Wizers förbättring av CPTI för en Wasm modul. Syftet med detta är att möjliggöra för Wasm designers och utvecklare att förstå hurvida förinitialisering skulle kunna bli standardiserat i Wasm kompilerare eller verktyg, eller om förinitialisering borde tillämpas på en Wasm modul under utveckling baserat på dens CPTI innan förinitialisering. Resultat samlas genom att kompilera flera exempelprogram ner till Wasm, mäta deras CPTI genom passerade CPU cykler både med och utan förinitialisering med Wizer, och jämföra mätningarna. Detta möjligörs genom en utökning av testramverket Sightglass som också utvecklats av Bytecode Alliance. Resultaten visar att förinitialisering med Wizer ökar CPTI om Wasm modulen inte kan i förväg kompileras till instruktioner som kan köras på CPU:n. Om kompilering i förväg dock är möjlig kan Wizer minska CPTI för en given Wasm modul med en faktor av två upp till sex gånger, beroende på den typ av förinitialisering som den gör.

Edge computing facilitates applications of cyber-physical systems that require low latencies by moving compute and storage resources closer to the end application. Whilst the edge network benefits such systems in terms of responsiveness, it increases the systems’ complexity due to edge devices’ often heterogeneous and resource-constrained nature. In this work, we evaluate whether WebAssembly can be used as a lightweight and portable abstraction layer for such applications. Through the implementation of an edge network robot control scenario, we benchmark and compare the performance of WebAssembly against its native equivalent. We measure WebAssembly’s overhead and assess the impact of different placement options in the network. We further compare the overall application responsiveness against the latency requirements of an industrial application to evaluate its performance. We find that WebAssembly satisfies the portability and performance requirements of the selected industrial use case. Our empirical results show that WebAssembly doubles the execution latency in a localized setting, but does not excessively impact the overall responsiveness of a cyber-physical system. / Edge computing underlättar tillämpningar av cyberfysiska system som kräver låga latenser genom att flytta beräknings- och lagringsresurser närmare slutapplikationen. Även om edge-nätverket gynnar sådana system när det gäller reaktionsförmåga, ökar det systemens komplexitet på grund av edge-enheternas ofta heterogena och resursbegränsade natur. I detta arbete utvärderar vi om WebAssembly kan användas som ett lättviktigt och portabelt abstraktionslager för sådana applikationer. Genom att implementera ett robotkontrollscenario för edge-nätverk benchmarkar och jämför vi prestandan hos WebAssembly med dess inbyggda motsvarighet. Vi mäter WebAssemblys overhead och utvärderar effekten av olika placeringsalternativ i nätverket. Vi jämför även den övergripande applikationsresponsen mot latenskraven i en industriell applikation för att utvärdera dess prestanda. Vi konstaterar att WebAssembly uppfyller portabilitets- och prestandakraven för det utvalda industriella användningsfallet. Våra empiriska resultat visar att WebAssembly fördubblar exekveringslatensen i en lokaliserad miljö, men att det inte påverkar den övergripande responsiviteten i ett cyberfysiskt system i alltför hög grad.

Collecting and deploying online games made by inexperienced developers can behard. This is something KTH (Royal Institute of Technology) has a problem withpertaining to a course involving SDL and SDL_Net programming. A good solutionto this problem is to host these games on a website. An easy-to-use way of compilingand deploying multiplayer games and game-servers written in C as web applicationsand web servers was needed. Specifically for games written in C using SDL andSDL_net libraries. The compiler toolchain Emscripten was used to compile gameand server code from C to WebAssembly, that could then be used through the generated JavaScript functions. Communication between the client and the server washandled by WebSockets. As much of the Emscripten specific functions were to behidden behind C libraries, emulating the format of SDL_Net. The finished solutionsthat emulated the format of SDL_Net, consisted of two new libraries, one for theserver and the other for the client. The libraries successfully emulated the TCP partsof SDL_Net library. The browsers event scheduler necessitates applications to beable to return control back to it. This meant that the game codes endlessly loopingfunctions had to be rewritten to enable rendering in the browser. / Det kan vara svårt att samla in och distribuera onlinespel gjorda av oerfarnautvecklare. Detta är något som KTH (Kungliga Tekniska Högskolan) har problemmed i en kurs som involverar SDL och SDL_Net programmering. En bra lösning pådetta problem är att köra dessa spel på en webbsida. Ett lättanvänt sätt att kompileraoch distribuera multiplayer-spel och spelservrar skrivna i C till webbapplikationeroch webbservrar behövdes. Specifikt för spel skrivna i C med SDL och SDL_netbiblioteken. Kompileringsverktyget Emscripten användes för att kompilera spel- ochserverkod från C till WebAssembly, som sedan kunde användas genom degenererade JavaScript-funktionerna. Kommunikationen mellan klienten ochservern sköttes av WebSockets. I största möjliga mån skulle Emscripten specifikafunktioner döljas bakom C-bibliotek som emulerade formatet av SDL_Net. Defärdiga lösningarna som emulerar formatet av SDL_Net bestod av två nya bibliotek,ett för servern och det andra för klienten. De emulerade framgångsrikt TCP-delarnaav SDL_Net biblioteket. Webbläsarens händelseschemaläggare kräver attapplikationer har möjligheten att återge kontroll till den. Detta gjorde att spelkodensoändligt loopande funktioner behövdes skrivas om för att kunna rendera i webbläsaren.

Today, companies are developing processor demanding applications on the web, for example, 3D visualization software and video and audio software. Some of these companies have a native desktop application written in for example C++. These C++ codebases can consist of several hundred thousand lines of code, and companies would therefore like to reuse their codebase in the web version of the software. This thesis makes a performance comparison between two different approaches that can be taken to reuse the C++ codebase. The first approach is to compile the C++ codebase to WebAssembly and run it on the client-side. The second approach is to compile the C++ codebase to native code and run it on the server-side. It is not clear which approach to take if the goal is to achieve low execution times. This thesis will therefore answer the question of whether a client-side solution inWebAssembly is faster than a server-side solution in native code. To answer this question, this project work looked at one use case namely image processing. Two different web applications were developed, one that did image processing on the server-side in native code, and another one that did image processing on the client-side in WebAssembly. Execution time measurements were collected from both web applications. The results showed that for most algorithms WebAssembly was a factor of 1.5 slower than native code, without considering the additional delay from the internet that will affect the web application that performs image processing on the server-side. If this delay is taken into account, the web application that performs image processing on the client-side inWebAssembly will be faster than the server-side solution in native code for most users in the world. If the Round-Trip Time (RTT) is 1 ms the required average throughput needed to make the two web applications equally fast is 249 Mbps (Google Chrome) or 226 Mbps (Firefox). Most users in the world do not have such a high average throughput. / Idag utvecklar företag processorkrävande applikationer på webben, till exempel 3D-visualiseringsprogramvara och video- och ljudprogramvara. Några av dessa företag har även skrivbordsprogram skrivna i exempelvis C++. Dessa C++ kodbaser kan bestå av flera hundra tusen rader kod, och företag vill därför återanvända sin kodbas i webbversionen. Detta projektarbete gör en jämförelse mellan två olika tillvägagångssätt för att återanvända C++ kodbasen. Det första tillvägagångssättet är att kompilera C++ kodbasen till WebAssembly och köra koden på klientsidan. Det andra tillvägagångssättet är att kompilera C++ kodbasen till maskinkod och köra koden på serversidan. Det är inte klart vilken metod man ska ta om målet är att uppnå optimal prestanda. Detta projektarbete kommer därför att besvara frågan om en klientsidslösning i WebAssembly är snabbare än en serversidslösning i maskinkod. För att svara på den här frågan tittade projektarbetet på ett användningsfall, nämligen bildbehandling. Två olika webbapplikationer utvecklades, en som gjorde bildbehandling på serversidan i maskinkod och en annan som gjorde bildbehandling på klientsidan i WebAssembly. Körtidsmätningar samlades in från båda webbapplikationerna. Resultaten visade att för de flesta algoritmer var WebAssembly en faktor 1,5 långsammare än maskin kod, utan att ta hänsyn till den extra fördröjningen från internet som kommer att påverka webbapplikationen som utför bildbehandling på serversidan. Om denna fördröjning tas med i beräkningen kommer webbapplikationen som utför bildbehandling på klientsidan i WebAssembly att vara snabbare än serversidslösningen i maskinkod för de flesta användare i världen. Om tur och retur tiden (RTT) är 1 ms är den genomsnittliga genomströmning som krävs för att göra de två webbapplikationerna lika snabba 249 Mbps (Google Chrome) eller 226 Mbps (Firefox). De flesta användare i världen har inte så hög genomsnittlig genomströmning.