51 lines
3.2 KiB
TeX
51 lines
3.2 KiB
TeX
% The Web Platform
|
|
|
|
|
|
|
|
\subsection{Introduction to Webassembly}
|
|
|
|
\todo[inline]{Present WebAssembly}
|
|
|
|
\subsubsection{Existing compilers}
|
|
|
|
\todo[inline]{Languages from which to compile}
|
|
\todo[inline]{emscripten}
|
|
\todo[inline]{assemblyscript}
|
|
\todo[inline]{rust}
|
|
|
|
\subsubsection{Technical hurdles}
|
|
|
|
\todo[inline]{Managing memory}
|
|
\todo[inline]{passing arrays}
|
|
|
|
\subsubsection{Benefits of WebAssembly}
|
|
|
|
Why are people going through the hassle of bringing machine code to a platform with a working scripting engine. Is javascript really that aweful. It is often stated that WebAssembly can bring performance benefits. It makes sense that statically typed machine code beats scripting languages performance wise. It has to be observed however if the overhead of switching contexts will neglect this performance gain. Javascript has made a lot of performance improvements over the past years. Not at least Googles development on the V8 engine has brought Javascript to an acceptable speed for extensive calculations. The engine observes the execution of running javascript code and will perform optimizations that can be compared to optimizations of compilers.
|
|
|
|
\todo[inline]{Get chart and source of js performance}
|
|
\todo[inline]{Source for V8 performance observation}
|
|
|
|
The javascript ecosystem has rapidly evolved the past years. Thanks to package managers like bower, npm and yarn it is super simple to pull code from external sources into ones codebase. In course of this growth many algorithms and implementations have been ported to javascript for use on the web. After all it is however not more then that. A port splits communities and contradicts the DRY principle. With WebAssembly existing work of many programmers can be reused as is for usage on the web. This is the second benefit proposed by the technology. Whole libraries exclusive for native development could be imported by a few simple tweaks. Codecs not supported by browsers can be made available for use in any browser supporting WebAssembly. One example could be the promising AV1 codec
|
|
|
|
\todo[inline]{more about av1}
|
|
|
|
To summarize the two main benefits that are expected from WebAssembly are perfomance and integration. In this thesis these two benefits will be tested.
|
|
|
|
|
|
\subsection{Two test cases - performance and integration}
|
|
|
|
The benefits that WebAssembly promises shall be tested in two seperate Webpages. One for the performance measurements and one to test the integration of existing libraries.
|
|
|
|
\paragraph{Performance}
|
|
|
|
As it is the most applicated algorithm the Douglas-Peucker algorithm will be used for measuring performance. A Javascript implementation is quickly found. simplifyJS. It is the package used by Turf, the most used for geospatial calculations. To produce comparable results the implementation will be based on this package. Since WebAssembly defines a compilation goal several languages can be used for this test.
|
|
|
|
\todo[inline]{source for simplify JS}
|
|
\todo[inline]{source for turf}
|
|
|
|
\paragraph{Integration}
|
|
|
|
An existing implementation of several simplification algorithms has found in the C++ ecosystem. psimpl implements x algorithms distributed as a single header file. It also provides a function for measuring positional errors making it ideal for use in a quality analysis tool for those algorithms.
|
|
|
|
|