Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

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@gmail.com> wrote:

> Thanks for the inspiring sharing! 👏
>
> On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch <basile@starynkevitch.net>
> 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.
>> https://gitlab.com/hardenedlinux/screaming-fist
>>
>> 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
>> https://en.wikipedia.org/wiki/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@gmail.com>, Hakan Candar <
>> hakancandar@protonmail.com>
>> Cc: guile-user@gnu.org <guile-user@gnu.org>, <jit@gcc.gnu.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)
>>
>>
>> --
>>
>> Basile STARYNKEVITCH           <basile@starynkevitch.net>8 rue de la 
>> Faïencerie
>> 92340 Bourg-la-Reine,          France 
>> <https://www.google.com/maps/search/8+rue+de+la+Fa%C3%AFencerie%0D%0A92340+Bourg-la-Reine,++++++++++France?entry=gmail&source=g>http://starynkevitch.net/Basile
>>  & https://github.com/bstarynk
>>
>>