Hello,
Anyone tried to run a Prolog application on a WASM container? In order to reduce footprint in K8S clusters.
It seems to be a promising way to implement low-footprint micro-services implemented in SWI Prolog.
Thanks,
Quenio
Good question. Prolog for WASM is not particularly small though and less modular than native. The native version is also a lot faster. What exactly do you want to minimize and what kind of scenario do you have in mind?
What I have in mind is implementing micro-services in Prolog. The idea is having very small services that can collaborate via well-defined interfaces, and that can be independently implemented and deployed.
I work in a company that has done it with Python. But the overhead of each container in terms of memory and CPU is considerable. WASM is promising if it can reduce the memory/CPU footprint.
The lower the footprint, the larger the number of micro-services (and the number of instances of each service) that can be run in a cluster, with the same cost.
I see. It is an interesting topic. I don’t really see how WASM helps here (but, I could be wrong). The WASM binary isn’t that much smaller. Next, while the native version maps the executable file read-only into memory, the WASM version is JIT compiled into memory owned by the node process (not 100% sure about this, but that seems the obvious way). So, memory use is not smaller, and while we can possibly share the binary between multiple native instances, the memory of multiple WASM instances is at best only shared if we run multiple WASM Prolog instances on the same node process. Right?
I think that if you run multiple Docker containers from the same image (containing Prolog), the text segments of the Prolog processes will share the same memory (on Linux or other decent Unix derivatives).
Note that the Prolog footprint is the shared “text” segment, about 1.6Mb on AMD64 in the current version. Next to that, we have the loaded Prolog code. That starts at about 5Mb currently, as reported by tcmalloc (see malloc_property/1), rounded up by tcmalloc to 6.3Mb. Finally we have the Prolog stacks. They start small (118K). So, it seems the dominant factor is the loaded Prolog code. It is hard to say anything meaningful about stack usage as that may vary between a few hundred K to Gbs.
The, I think most promising, route to many Prolog micro services on a single host is to use Pengines or something similar. Pengines isolate the computation in a Prolog thread and a single temporary module reserved for the Pengine. All the rest is shared. Contact me directly if you want an in-depth discussion about the issues and possible refinements to make such a thing scale and get the desired isolation guarantees and robustness.
Thanks for being available and for the detailed explanation about the SWI Prolog’s footprint requirements.
The lower footprint, I was imagining, would not necessarily come from the Prolog runtime, but from the underlying stack.
Newer WASM containers run without a full OS, that is: run under a very small core that pretty much has just the WASM VM. Hence, they have a much smaller footprint than regular containers.
Worth looking into Fermyon to envision this new architecture for micro-services based on WASM.
I believe it opens doors for adoption of SWI Prolog on the backend/cloud.
Thanks for the link. It requires some more reading. The good thing is that WASM allows running more or less anything anywhere. The downside is that it comes at significant overhead and if we target a particular CPU using a well designed OS like Linux, I can’t imagine WASM wins.
I couldn’t find it quickly. Does Spin rely on virtual machines or containers? The standard SWI-Prolog Docker container contains Debian Bullseye. It is surely possible to create something much more lightweight that can, like Spin, create Prolog tasks with a low latency.
As is, SWI-Prolog’s WASM port is far from ideal. It is limited to 32-bits and quite slow as we have seen. I guess 64 BIT WASM will become widely available at some point in time. Then still, threading is barely possible (currently not supported in SWI-Prolog). Also the performance drop is high (~5 times). It seems lower for Ciao, which could mean there is room for improvement.
As is, my first intuition for a high performance cloud based Prolog server would be to base it on native technology. There is a lot of relatively low hanging fruit to achieve this in my view. The long term perspective is harder to judge. WASM is unlikely to even become faster than native, but the difference may become small enough to go for the benefits of portability, integration with other components and building on top of an established stack.
What about moleculer? Moleculer is a 100% open source and free of charge
project. All source code is available under the MIT License on GitHub.
Progressive microservices framework for Node.js.
https://moleculer.services/index.html
Edit 06.12.2023
Looks like a head to head competition, unless one has fake bought likes.
Spin:
Moleculer:
