I came across GraalVM and am trying to get my head around it.
It seems that the VM enables some sort of language interoperability when sources are compiled to
produce LLVM bytecode.
Does this mean that I could “embed” swi-prolog, somehow, into other languages such as Java with some kind of interoperability – i.e. java calling prolog and vice-versa.
One use case for me could be to rewrite some “lower-level” prolog code into java and have prolog run on-top.
I am reading that Java today with JIT is often close to C/C++ performance – while enabling a less complex language and a more secure memory model.
Edit:
It seems that the above is the case – and that swi-prolog can be compiled to LLVM bytecode – and then use Graal VM header to call prolog, say, from Java, as if it were embedded as a C library – although the other way around is not fully clear to me to call Java from Prolog within that interoperability environment.
Edit 2:
I am aware of JPL and am wondering if this is an alternative – more tightly integrated – approach, as well as offers interoperability with other languages.
Both Java and Prolog have an extensive independent and largely incompatible runtime support library. I very much doubt anything will help. “Generic” VMs typically target imperative languages, these days typically combined with object oriented features. Some most likely support dynamically typed objects. A Prolog VM is a rather different beast though. Possibly one could share some of the low-level data types, avoiding the need to transfer these when going to a different language. But if the price is that you need to express the Prolog runtime system in VM code you most likely will loose overall.
LLVM is something I still have in the back of my mind for doing hotspot compilation of Prolog code to machine code. That is not just a rainy Sunday afternoon project though.
JPL is pretty slow when compared to the C/C++ binding. It is mostly interesting to tap into the vast amount of available libraries. If you want extra speed for simple things, go C or C++. Well, maybe Rust. I guess @matthijs can answer on the extra overhead compared to C.
I am “flirting” with Java after reading that high performance traders use it and it can perform very well – with very low latency – when used carefully (no polymorphic language features, careful control over GC, and the like, i guess).
The benefit of Java over C/C++ is that its “managed” (to use the .NET lingo) - making it much easier to maintain.
The idea would the be to write an imperative, deterministic – “kernel” that is called by Prolog code. At the prolog level redo’s are essentially, fresh underlying calls with new parameters.
I’d do performance tests before pursuing. Just write a few trivial implementations with a representative data exchange, non-determinism and concurrency if you plan to use that. That should give an idea about the overhead as well as the implementation effort.
My bet would be C++ or Rust to get best performance while providing a reasonable level of high level programming and C if performance is essential (or C++ with great care which provides about the same performance; I don’t know the overhead of Rust).