Hi folks! Please reply AOT topic in this thread.


> Indeed, it turns out that everyone using libgccjit is using it for
ahead-of-time compilation, rather than jit-compilation.  Sorry about
picking a bad name :)

Thanks for the work! 

At least in Guile community, now that we already have JIT with GNU Lightening, we won't redundantly talk libgccjit for JIT. But I think it's still interesting to try libgccjit for JIT in my other project. :-p

> Probably of most interest to guile developers might be the gccemacs
project here:
  https://akrl.sdf.org/gccemacs.html


It looks super interesting!

They created a high level IR just like GIMPLE, which named LIMPLE. It's the way I preferred in streaming-fist. The basic idea is to provide such an IR, then try to replace 'bytecode' in Guile compiler tower codegen. And they choose SBCL for it, I think it can inspire people who are interested in Guile AOT. Or maybe they could consider to change to Guile to save a lot of time for both Guile and Emacs.

The compiler tower is so flexible that it's possible to try it as a plugin. 

I agreed with @mikael about losing weight of Guile. The AOT feature can be a plugin to install as guild tools. Of course, plugin unnecessarily mean it will be small......


Best regards.

On Sun, Dec 15, 2024, 02:45 Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Thanks for the inspiring sharing! 👏


On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org> wrote:
On Sun, 2024-12-15 at 02:21 +0900, Nala Ginrut wrote:
@basile I'm glad you raise this topic, I've played lobgccjit with a toy project.

I would say libgccjit is a wrong name since it's more like a tool for AOT.
Of course, one may still use it for JIT, however you have to do your own work for JIT and finally use libgccjit for codegen. 😁

Best regards.

You basically are right. If you want to use get a fast just-in-time compilation, libgccjit might not be the right tool.

But in practice, current computers are so fast that I think that in practice libgccjit is quite usable, and it can be tuned to various GCC optimization strategy.

A few years ago I did experiment (see https://arxiv.org/abs/1109.0779 ...) generation of C++ code which (on Linux desktop) was GCC compiled to a plugin and dlopen-ed. This works quite well with an elapsed time suitable for human users.

A related experiment is my manydl.c thing on https://github.com/bstarynk/misc-basile - it is/was a toy program that I wrote which generates a lot of random C code (in many thousands of C files), compile it to a plugin, and use dlopen and dlsym. It shows that on Linux a process can successfully dlopen do many hundred thousands of plugins (and never bother dlclose-ing them)

BTW in France the Lisp syntax and Scheme semantics of GNU guile is sadly becoming impopular. I know few persons using it.

Just in case I am attaching a few PDF files on RefPerSys.

Some ideas of RefPerSys originated from books and papers by by Jacques Pitrat 

Please mention RefPerSys to your colleagues and forward them this email.

Thanks



---------- Forwarded message ---------
From: Basile Starynkevitch <basile@starynkevitch.net>
Date: Sun, Dec 15, 2024, 02:11
Subject: Re: Running Compiled Guile Objects
To: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Hakan Candar <hakancandar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org>
Cc: guile-user-mXXj517/zsQ@public.gmane.org <guile-user-mXXj517/zsQ@public.gmane.org>, <jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org>


On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
> Hi Hakan!
> The current Guile is not AOT yet. Although the object file is ELF,
> it's
> just bytecode wrapped ELF header. So you can't run it as a regular
> executable file.
>

Those willing to contribute a proper ahead-of-time compiler to GNU
guile could use the GNU CC libgccjit library which is part of the GCC
compiler.
https://gcc.gnu.org/onlinedocs/jit/

This libgccjit layer of the GCC compiler is stable and maintained C API
and has some obsolete C++ API (which seems unmaintained in december
2024). Most of the libgccjit code is internally coded (under GPL
license) in C++, but the stable API is for C.

I am using the C API of libgccjit in the RefPerSys open source
inference engine project (GPLv3+ licensed) on
https://github.com/RefPerSys/RefPerSys/

Both libgccjit and GNU lightning (see
https://www.gnu.org/software/lightning/ ...) could be a basis for
adding a genuine compilation layer to GNU guile. And RefPerSys uses
both.

I guess a significant issue would be to use libgccjit (or GNU
lightning) with GUILE's garbage collector (which seems to be Boehm
conservative GC).

The RefPerSys project has a precise garbage collector and some
persistence (to textual files). Since it is GPLv3+ licensed, its code
could be reused in a future GUILE major version. RefPerSys is mostly
coded in C++.

I did contribute to GCC long time ago and hope that RefPerSys could
become a GNU project (but don't know how to make that happen)