Arbetet har undersökt hur predikatbaserad exekvering, i form av ARM-arkitekturens stöd för villkorlig exekvering, fungerar som optimering av specifika implementationer av if- och if-else-satser i ARM-maskinkod. Som en del av arbetet implementerades en för ändamålet konstruerad optimeringsalgoritm som optimerar if- och if-else-satser med hjälp av predikatbaserad exekvering, vilken användes för att kunna utföra de mätningar som ligger till grund för resultatet. Fokus låg på den skillnad i kodstorlek och/eller tidseffektivitet som optimeringen gav upphov till. Resultatet tyder på att predikatbaserad exekvering använd som optimering kan leda till vissa vinster i kodstorlek (direkt beroende på antalet if-/if-else-satser) och lite större vinster i tidseffektivitet (beroende på hur stora if-/if-else-satserna är, samt hur ofta de exekveras).

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.