Webassembly

instead of porting swi prolog to web assembly, wouldnt it be a better solution to write a swi-prolog program which can parse prolog code, and which can then output code in webassembly format for this parsed code?.

or to let this program generate webassembly script which then can be used for webassembly,

they say that C code can already be converted to webassembly, is this true for all cases because of the procedural nature of the language C?

would it then be good to learn C as a language because you can then use it for webassembly as well,
or would it be benificial to learn webassembly-script for reason that this is made for the purpose of generating webassembly code, in other words does webassemblyscript have a better connection to webassembly-code than C-code?

That is more or less the same discussion whether or not one should compile Prolog to native code or use a virtual machine (as most implementations including SWI-Prolog). There is no simple answer to that. On small programs this is probably a good idea to compile to native code. On larger programs the benefits become less clear. Possibly, hot-spot compilation is an attractive intermediate. I don’t know whether or not this has been done for Prolog. It surely is still on my mind.

As is, SWI-Prolog is written in C (and Prolog). The C part is compiled to webassembly using emscripten. After that, all is normal.

2 Likes

For those not familiar with Prolog virtual machines – the “byte code” already has some implicit optimizations in it, such as early check whether an argument to a predicate is instantiated or not and executing different byte code sequences accordingly. The main advantage of generating native code is in removing the interpreter fetch/interpret overhead (plus eliding some redundant store/fetch instructions) … as the virtual machine instructions can be moderately complex, this isn’t necessarily a big win (a long time ago, I did some analysis on this with PowerPC architecture – the theoretical advantages of not stalling the instruction stream weren’t observed in practical programs).

But as Jan says, hot-spot compilation can probably get big wins.

BTW, I ran some of my code with and without profile-guided optimization and there was essentially no difference - even though Jan had reported a 20% improvement. This shows how synthetic benchmarks can be very different from real world [and, no, I haven’t tried PGO on my code - it’s non-trivial to adapt the code to the cmake/ninja framework that’s used for building SWI-Prolog].

1 Like

This is a bit unexpected. The benefits are pretty much independent of the application provided most of the work is proper Prolog work of course. Now, didn’t you use a Mac? PGO compilation now succeeds AFAIK using XCode’s clang compiler, but according to @pmoura didn’t help. It does help with gcc and much more with recent versions than with old versions. You may give the binary distribution for MacOS a try. In my measurements the GCC with PGO is a lot (over 30%) faster than the XCode compiled version.

I’m on Ubuntu, not Mac. Is there an option to ensure that I’m using gcc and not clang (both are installed on my system)?

I thought that setting the CC and CXX environment variables should do the trick. After some googling I am not so sure any more, there are multiple answers mentioning two other (cmake specific??) environment variables, CMAKE_C_COMPILER and CMAKE_CXX_COMPILER.

Either way you can try out and look at the output of running of cmake to see what happens.

CC=gcc CXX=g++ cmake option ...

But on Ubuntu, gcc is the default AFAIK. Possibly you can install clang and make it your default compiler, but a typical Linux system uses gcc/g++ as default compilers.

There was some demo on the original port. That may still be accessible somewhere. As is, it stayed at a demonstrator state AFAIK. I guess it is waiting for someone to take it to the next stage. In the meanwhile many issue wrt. cross-compiling SWI-Prolog have been improved and it may thus be possible to turn the whole thing into a proper bundle.

There are various files but no self-contained bundle. Even if we bundled the code as a downloadable zip file or something else like that, there are still these issues left:

  • No useful Prolog-JavaScript bridge.
  • Toplevel does not work (read call blocks the browser event loop).
  • Linked dynamic extensions - this felt like nightmare to get working in Emscripten.
  • Tests still do not run due to Emscripten filesystem emulation issues.

There is some support for JS interaction but it needs more work. Currently, only as much as was needed for demos, was built.

It’s possible to put a bundle together by documentation in SWI source. That was documented.

2 Likes

Thanks for the work you did on this. I think we are at the stage where a good motivation is required to get it to the finish line.

I’ve had some inquiries. Surely there a are people who like to do part of the frontend programming in Prolog and if they already do the backend in SWI-Prolog having SWI-Prolog in the browser makes a lot of sense.

2 Likes