One component of Codeplay’s ComputeAorta that I manage is our high precision maths library Abacus.

One major component of Abacus, and in fact all math libraries, are a requirement to have remez reduced polynomial approximations of functions. In the past we’ve made use of Maple, Mathematica, lolremez, our own fork of lolremez, and to be honest none of them have been satisfactory to our needs. We want a scriptable solution that we can use to bake the generated polynomials automatically into Abacus with minimal user intervention.

I was lucky enough to be involved in a twitter thread with Marc B. Reynolds where he pointed me at Sollya. It’s Linux only which sucks (I’m primarily a Windows developer), but I fired up a VM and tried it out - and I’ve got to say, its pretty darn good! The non-Windows support is a big issue though, so how to fix that?

Enter stage left - Emscripten!⌗

So I’ve known about Emscripten for a while, but never had a really compelling reason to use it. I suddenly thought ‘I wonder if I could use Emscripten to compile Sollya to JavaScript, then use Node.js to run it on Windows?’.

Yep, you are right, I’m mad. This can’t be a good way to take software meant for Linux and cross compile it for Windows, right? That just made me all the more curious to see if it could work.

Sollya and all its dependencies⌗

Sollya requires a bunch of different projects to work: libxml2, GMP, MPFR, MPFI, fplll, and lastly Sollya itself. So I first downloaded all of these, built them all from source, and built Sollya using gcc on Linux - just to test that I could build it.

Then, using Emscripten’s emconfigure (which you place before the typical linux call to ./configure) it replaces any compiler usage with the Emscripten compiler emcc, we can try and build Sollya again but for JavaScript!

So I started with libxml2, which worked! And then onto GMP - and explosions. Some stack overflowing pointed me to Compiling GMP/MPFR with Emscripten which states that for some reason (I didn’t dig into why) Emscripten couldn’t compile GMP if the host platform was not 32 bits. I looked at the answer where it suggests you chroot and thought ‘that seems like a lot of work to mess with my current 64-bit VM that I do other things on, I’ll fire up a new VM to mess with’. But since I’m creating a new VM anyway, I decided to just create a 32-bit Ubuntu VM and use that instead (which meant less configuration work on my part).

So with my 32-bit VM, I started the whole process of compiling libxml2, gmp, mpfr, mpfi, fplll (wow I’m on a roll!) and finally I get to Sollya and… it failed.

Sollya and dlopen⌗

Sollya makes use of dlopen, and thus the ./configure script in Sollya will check that dlopen is a command that works on the target platform. The problem is, ./configure doesn’t use the correct signature for the dlopen call - it just does:

and then ensures that the linker doesn’t complain when this is linked against -ldl. The signature of dlopen is:

and Emscripten looks for that exact signature, and complains if the function doesn’t have the correct number and type of arguments. This meant as far as ./configure was concerned, the system didn’t have dlopen (even though Emscripten can stub implement it), and it failed.

Ever the hacker, I just decided to patch the ./configure to not error out:

tried to build again, and Sollya built!

Emscripten and .bc’s⌗

Emscripten seems to output an LLVM bitcode (.bc) file by default - and I couldn’t work out how to tell emconfigure to output a JavaScript file instead.

So what I did was take the bitcode file that was in ‘sollya’ and used emcc directly to turn this into a JavaScript file.

emcc complained if the input bitcode file wasn’t named .bc, so I first renamed it to sollya.bc:

and I got a whopping 27MB JavaScript file out!

Next I used node to run this JavaScript against a simple test script I wrote:

and ran Node.js:

and it ran!

But it kept on running, like infinite-loop running - the thing just never stopped. I was getting a ton of ‘sigaction not implemented’ messages, so I wondered if Sollya was doing something really ugly with signals to handle exiting from a script. I thought about digging into it, then realised Sollya has an explicit ‘quit;’ command, so I added that to the bottom of the script:

and it ran and exited as expected.

So now I have a JavaScript file that works when I run it through Node.js, but we’ve got a couple of issues:

  • The JavaScript is freaking huge!
  • We don’t want to require Node.js to be installed either for our developers.

File size⌗

Digging into Emscripten I found that there were a couple of options we could use:

  • -O3 - same as all compilers, we can specify that the compiler should optimize the code heavily.
  • -llvm-lto 2 - this enables all the optimizations to occur on the entire set of bitcode files once they are all linked together. This will allow for a ton more inlining to take place which should help our performance.

Adding both these options, the size of the produce sollya.js was 4.1MB! A whopping 6.5x reduction in file size - and its actually optimized properly now too.

Creating a standalone Windows binary?⌗

So I’ve got sollya.js - and I can run this with Node.js on Windows and get actual valid polynomials. But I really want a standalone executable that has no dependencies, is this possible? Searching around, I found out about nexe - a way to bundle a Node.js application into a single executable. It basically puts Node.js and the JavaScript file into the same executable, and calls Node.js on the JavaScript at runtime. While this isn’t _amazing _- would it work?

First off - you have to use nexe on the platform you want to run the end executable on  - so I copied the sollya.js from my VM to my Windows host, and then after installing nexe I ran:

And what do you know - I can run sollya.exe and it works as expected. The downside is that because the executable is shipping an entire copy of Node.js with it - sollya.exe is a whopping 29MB to ship around.

Performance⌗

I’ve compared the natively compiled sollya executable with the JavaScript variant. I ran them 50 times, and averaged out the results.

<th>
  sollyajs
</th>

<th>
   JS vs Native Performance
</th>

<td>
  4.93946s
</td>

<td>
  3.6x slower
</td>

So as expected - given that we are running through JavaScript and Node.js, we are 3.6x slower than the natively compiled executable. I’m honestly surprised we are not slower (I’d heard horror stories of 90x slowdowns with Emscripten) so this seems not too bad to me.

Conclusion⌗

It seems that with Emscripten, in combination with Node.js and Nexe, we can compile a program on Linux to be run entirely on Windows - which is pretty freaking cool. There are probably many other more sane ways to do exactly this, but I find it pretty amazing that this is even possible. Now I can ‘natively’ run a Windows executable which will calculate all the polynomial approximations I need on Windows too - saving our team from having to have a Linux VM when re-generating the polynomials is required.

CMake script to build Sollya with Emscripten⌗

In case anyone is interested, I use a CMake file to bring in all the dependencies and build Sollya using Emscripten.