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

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.

With the current developments in modern web browsers, WebAssembly has been a rising trend over the last four years. Aimed at replacing bits of JavaScript functionality, it attempts to bring extra features to achieve portability and sandboxing through virtualisation. After the release of the WebAssembly System Interface, more and more projects have been working on using it outside web pages and browsers, in scenarios such as embedded, serverless, or distributed computing. This is thus not only relevant to the web and its clients, but also to applications in distributed systems. Considering the novelty of the topic, there is currently very little related scientific literature. With constant changes in development, proposals and goals, there is a large gap in relevant research. We aim to help bridge this gap by focusing on Rust and Arc-Lang, a domain-specific language for data analytics, in order to provide an overview of how far the technology has progressed, in addition to what runtimes there are and how they work. We investigate what kind of use case WebAssembly could have in the context of distributed systems, as well as how it can benefit data processing pipelines. Even though the technology is still immature at first glance, it is worth checking whether its proposals have been implemented, and how its performance compared to that of native Rust can affect data processing in a pipeline. We show this by benchmarking a filter program as part of a distributed container environment, while looking at different WebAssembly compilers such as Cranelift and LLVM. Then, we compare the resulting statistics to native Rust and present a synopsis of the state of WebAssembly in a distributed context. / I takt med den nuvarande utvecklingen av moderna webbläsare har WebAssembly stigit i trend under de senaste fyra åren. WebAssembly har som syfte att ersätta och utöka JavaScript med funktionalitet som är portabel och isolerad från omvärlden genom virtualisering. Efter lanseringen av WebAssembly System Interface har fler och fler projekt börjat applicera WebAssembly utanför webbsidor och webbläsare, i scenarier som inbäddade, serverlösa eller distribuerade beräkningar. Detta har gjort WebAssembly till ett språk som inte bara är relevant för webben och dess användare, utan även för applikationer i distribuerade system. Med tanke på ämnets framkant finns det för närvarande väldigt lite relaterad vetenskaplig litteratur. Ständiga förändringar i utveckling, förslag och mål har resulterat i stort gap i relevant forskning. Vi strävar efter att hjälpa till att överbrygga denna klyfta genom att studera WebAssembly i perspektivet av Rust och Arc-Lang, ett domänspecifikt språk för dataanalys, för att ge en översikt över hur långt tekniken har kommit, och samt utreda vilka exekveringssystem som finns och hur de fungerar. Vi undersöker vilken typ av användning WebAssembly kan ha i samband med distribuerade system, samt hur det kan gynna databehandlingspipelines. Även om tekniken fortfarande är ny vid första anblicken, är det värt att kontrollera om dess förslag har implementerats och hur dess prestanda gentemot Rust kan påverka databehandling i en pipeline. Vi visar detta genom att benchmarka ett filtreringsprogram som en del av en distribuerad containermiljö, samtidigt som vi tittar på olika WebAssembly-kompilatorer som exempelvis Cranelift och LLVM. Vi jämför resultaten med Rust och presenterar en sammanfattning av WebAssemblys tillstånd i sammanhanget av distribuerade system.

Today more and more advanced and demanding applications are finding their way to the web. These are applications like video editing, games, and mathematical calculations. Up until a few years ago, JavaScript was the only language present on the web. That was until Mozilla, Google, Microsoft, and Apple decided to develop WebAssembly. WebAssembly is a low-level language, similar to assembly, but running in the browser. WebAssembly was not created to replace JavaScript, but to be used alongside it and complement JavaScript’s weaknesses. WebAssembly is still a relatively new language (2017) and is in continuous development. This work is presented as a guideline, and to give a general direction of how WebAssembly is performing (in 2022) when operating on GIS data. When comparing the execution speed of WebAssembly running in different environments (NodeJS, Google Chrome, and Mozilla Firefox), NodeJS was the fastest. The second fastest was Mozilla Firefox, and the slowest was Google Chrome. However, when compared to the native implementation in C++, no environment came close to the developers’ promised 10% slowdown compared to the native code. The average slowdowns found in this study were: The benchmark with small input files ran 63% slower than native. The benchmark with medium input files ran 62% slower than native, and the benchmarks with large input files ran 68% slower than native. The results are comparable to the study [6], which found that the slowdown was around 45% when running WebAssembly on Mozilla Firefox and 55% on Google Chrome with a peak of 2.5 times slowdown compared to native. This study aimed to measure memory usage in the different environments for operations on GIS data. However, the methods used in this study to measure memory proved to be too unsophisticated when dealing with JIT and garbage collection. For future work, a more detailed "memory allocated over time" graph should probably be used to be able to measure the peaks of memory currently allocated to the process instead of looking at the difference in memory before and after.

For many years it has only been HTML, CSS, and JavaScript that have been native to the Web. In December 2019, WebAssembly joined them as the fourth language to run natively on the Web. This thesis compared WebAssembly to the technologies ActiveX, Java applets, Asm.js, and Portable Native Client (PNaCl) in terms of their performance, security, and browser support. The reason why this was an interesting topic to investigate was to determine in what areas WebAssembly is an improvement over previous similar technologies. Another goal was to provide companies that still use older technologies with an indication as to whether or not it is worth upgrading their system with newer technology. To answer the problem, the thesis mainly focused on comparing the performance of the technologies through a controlled experiment. The thesis also aimed at getting a glimpse of the security differences between the technologies by the use of a literature study. The thesis showed that PNaCl was the technology with the best performance. However, WebAssembly had better browser support. Also, PNaCl is deprecated while WebAssembly is heavily supported and could potentially be further optimized.