A comparison of heavy computations in Giac on various platforms
...including node.js and WebAssembly.
This was planned for a few years already, to learn if the move towards the web platforms can keep the speed of real-time animations that are based on heavy computer algebra. At GeoGebra we worked hard on assembling a handy mixture of symbolic and numerical computations, mostly for educational use, during the last years. My contribution to this topic was summarized in two papers (1, 2). In the second one (published in November 2018) two recent systems were mentioned if they can take over the heavy part of computations in the web browser.
As it is well known, JavaScript (JS) is designed not for heavy symbolic computations, but since its first versions an enormous work was done in speeding it up, by magnitudes. As of today JS is quick enough for most applications, but there is still a speed gap between JS and the native technologies.
One possible solution addressing the problem is asm.js, introduced in 2013, used mostly in Firefox only. That is, another solution that seems more accepted by all major browsers is WebAssembly that is already implemented in Firefox, Edge and Google Chrome, among others, is officially available since 2017.
While many users move to web applications, there is still a big market of desktop applications. What is more, for convenience, several software companies decide to create desktop versions of their web applications by packaging them by using various new tools. Such a possible way is to use Electron that provides connecting the web application with native computations if it requires heavy processing.
The Electron packaging system (actually, it is not just for packaging, but building new applications as well) is built on the top of node.js, a JS framework. At GeoGebra we provide a few different versions of the same popular software GeoGebra Classic by packaging them with Electron and connecting them with a native version of Giac. As a result we have an application with a modern look and feel, but the computations are still fast and reliable.
Now we have some unofficial but still exact reports on that. In the next publicly available version, 6.0.519.0 we will be able to make exact benchmarks that measure the speed of computations via node.js, and also without it, that is, the computations fall back to use WebAssembly in that case.
The first results can be found in the official benchmarking database of the locus outputs of GeoGebra Automated Reasoning Tools. As expected, both the WebAssembly and node.js approaches are faster than the classic JS implementation, but both are somewhat slower than the Java native solution:
Here the column DesktopInternal shows the speed of a given test: deg explains the degree of the polynomial curve in the output and FPS means the speed (frame per second). The column DesktopGrobcov should be ignored here because it uses a completely different (somewhat slower) algorithm than the other ones. The column Web shows the classic JS implementation, and Node and Wasm describe the node.js and WebAssembly implementations.
In this benchmark, however, it is difficult to compare if the node.js or the WebAssembly implementation has a better performance. We know that GeoGebra has some problems with loading the WebAssembly code in certain cases, thus in the summary the node.js implementation is reported to be more successful:
On the other hand, these tests were run in an Xvfb virtualization that may slow down the node.js code in some sense. So further investigation of these platforms is still future work.
This was planned for a few years already, to learn if the move towards the web platforms can keep the speed of real-time animations that are based on heavy computer algebra. At GeoGebra we worked hard on assembling a handy mixture of symbolic and numerical computations, mostly for educational use, during the last years. My contribution to this topic was summarized in two papers (1, 2). In the second one (published in November 2018) two recent systems were mentioned if they can take over the heavy part of computations in the web browser.
As it is well known, JavaScript (JS) is designed not for heavy symbolic computations, but since its first versions an enormous work was done in speeding it up, by magnitudes. As of today JS is quick enough for most applications, but there is still a speed gap between JS and the native technologies.
One possible solution addressing the problem is asm.js, introduced in 2013, used mostly in Firefox only. That is, another solution that seems more accepted by all major browsers is WebAssembly that is already implemented in Firefox, Edge and Google Chrome, among others, is officially available since 2017.
While many users move to web applications, there is still a big market of desktop applications. What is more, for convenience, several software companies decide to create desktop versions of their web applications by packaging them by using various new tools. Such a possible way is to use Electron that provides connecting the web application with native computations if it requires heavy processing.
The Electron packaging system (actually, it is not just for packaging, but building new applications as well) is built on the top of node.js, a JS framework. At GeoGebra we provide a few different versions of the same popular software GeoGebra Classic by packaging them with Electron and connecting them with a native version of Giac. As a result we have an application with a modern look and feel, but the computations are still fast and reliable.
Now we have some unofficial but still exact reports on that. In the next publicly available version, 6.0.519.0 we will be able to make exact benchmarks that measure the speed of computations via node.js, and also without it, that is, the computations fall back to use WebAssembly in that case.
The first results can be found in the official benchmarking database of the locus outputs of GeoGebra Automated Reasoning Tools. As expected, both the WebAssembly and node.js approaches are faster than the classic JS implementation, but both are somewhat slower than the Java native solution:
In this benchmark, however, it is difficult to compare if the node.js or the WebAssembly implementation has a better performance. We know that GeoGebra has some problems with loading the WebAssembly code in certain cases, thus in the summary the node.js implementation is reported to be more successful:
Comments