Collecting WebAssembly thesis/research ideas

[carlopi]

From time to time I bump into students looking for topics for their thesis, and since I believe there are many worthy ideas WebAssembly-related it could be useful to collect them somewhere to have a list to point people to.

Not sure if there is any interest for this and what the right format / implementation should be, for now I am mainly looking for general feedback & meta-ideas.

[juj]

Heya, let me take a stab..

One thing that I think would be worthwhile pursuing would be to build a framework that compiles identical C/C++ code snippets natively (for x86-64 or for ARM), and then the same code into WebAssembly, and then runs through V8 or similar VM, and have the VM dump the native x86-64/ARM disassembly that it generates.

It is an interesting question to identify what types of categorical shortcomings there currently exists in the WebAssembly ISA. Do VMs generate code that is "tight" modulo only essential security related overhead that must exist, or do they have codegen inefficiencies that would be caused by a) "simply" missed optimization opportunities (missed/yet undone work), or b) WebAssembly spec limitation based issues that prevent VMs from generating as efficient code as native compilers would do.

I don't know of this type of "apples vs apples" comparisons done through the whole Wasm stack vs native code, and I think it could potentially highlight blind spots and future directions for the ISA to evolve to.

---

Another interesting domain would be to pursue investigating generated code size aspects. WebAssembly (like JS) is unique that the code is most often executed "online", so one must bring all the code with them, unlike practically all other code execution platforms where an offline installation step is allowed. This unique challenge brings a lot of attention towards aggressive code size optimizations techniques.

Two ideas:

• WebAssembly compiled code is generally sent through the wire using gzip or brotli compression. Would there be room to improve compression efficiency if one designed a WebAssembly domain specific compression algorithm to better exploit patterns that exist in WebAssembly module files?

• To reduce code size, duplicate function elimination is commonly done. In addition to duplicate functions, native compiled code often contains emitted functions that are very similar, but not quite identical. If approaching this issue from the wasm layer, would it be possible to implement efficient "similar function elimination" optimization approaches, where common blocks in functions could be either "outlined" to shared implementations? Or functions that are almost identical save for some parameters, would be "templatized" to a common archetype and the specific paths controlled via parameterization techniques?

---

WebAssembly viability on mobile devices:

The majority of benchmarks of WebAssembly dedicate themselves to desktop platforms. Graphics applications like to measure FPS, and non-graphics applications typically bench the workload duration.

Those metrics are of course important, but on mobile devices, it is also the battery power efficiency, e.g. Joules consumption that is critical. Given the complex pipelined nature of CPUs today, the same workload can be executed with the same performance (speed), while still having quite a different power efficiency profile.

There haven't been many studies done on the general power efficiency of WebAssembly. Some recent studies have looked into Wasm efficiency vs JavaScript, e.g. https://ieeexplore.ieee.org/document/9680302 and sol.sbc.org.br. However comparing WebAssembly against native code execution, focusing on mobile devices, would be a particularly relevant to understand the overhead of WebAssembly.

---

Multithreaded WebAssembly applications today in web browsers are lacking due to the issue that its multithreading model is based on Web Workers. In particular, thread signaling is not available (pthread_kill), thread priority hints are not available (pthread_setschedparam), and CPU memory and core topology is not available (NUMA archs and big.LITTLE archs). Also thread boosting is not available, so managing battery efficiency usage in mobile multithreaded applications is not possible.

As a result, computation heavy multithreaded WebAssembly applications on a mobile device can fall short of the performance, battery & power efficiency that native applications can reach.

These aspects have been met with uncertainty as to how these types of features could be introduced to the web, taking into account the fingerprinting and security concerns.

---

Hopefully some of these areas might spark fruitful conversations forward!

[titzer]

I've started collection projects for students who would like to work with me. Several are Wasm-related.

https://github.com/titzer/student-projects/