Re: AOT compiler (was: Running Compiled Guile Objects)
> From: Nala Ginrut > Date: Sun, 15 Dec 2024 11:08:25 +0900 > Cc: Maxime Devos , t...@refpersys.org, > jit@gcc.gnu.org, > "dmalc...@redhat.com" , bas...@starynkevitch.net > > > FWIW libgccjit builds position independent code, and can be used to > build dynamic libraries (which is what I believe gccemacs is doing). A nit: there's no such thing as gccemacs. Perhaps you mean GNU Emacs starting from version 28, which can compile Lisp into native code using libgccjit?
Re: Running Compiled Guile Objects
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) Regards from near Paris in France. -- Basile STARYNKEVITCH 8 rue de la Faïencerie 92340 Bourg-la-Reine, France http://starynkevitch.net/Basile & https://github.com/bstarynk
Re: Running Compiled Guile Objects
On Sat, 2024-12-14 at 18:11 +0100, Basile Starynkevitch wrote: > 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. > > > [Sorry if I'm missing context here, I'm only seeing the part of the thread where Basile CCed the jit@gcc.gnu.org mailing list] > 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/ ...and https://gcc.gnu.org/wiki/JIT 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 :) Probably of most interest to guile developers might be the gccemacs project here: https://akrl.sdf.org/gccemacs.html since AFAIK that has successfully used libgccjit from within a lisp- like language to get noticeable speedups. But guile developers probably know more about this than I do; I confess I don't know much about the lisp/scheme world. > > 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. Indeed, it is gcc's code generation source code (which is C++), wrapped in a C API and header (it looks like a frontend to the rest of gcc, and like an API to the client code). Hope this is constructive Dave > > 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) > > Regards from near Paris in France. >
RE: Running Compiled Guile Objects
>> 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/ > >...and https://gcc.gnu.org/wiki/JIT > >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 :) Are we talking about implementing a ‘to machine code’ compiler for Guile, or about implementing an ‘AOT to machine code’? Guile already has the former – it has a JIT (bytecode -> machine code) for some systems. For what it’s worth -- I never worked with libgccjit or with the JIT code of Guile: I imagine a basic (POC) AOT approach for Guile would be to let it compile AOT – with the JIT implementation, except adjusted to be relocatable and to add relocation information. As far as I can tell, libgccjit does not seem to support relocations and doesn’t say anything about whether the results are position-independent or not (so not suitable fo AOT), though presumably there are ways around that given the existence of gccemacs. Best regards, Maxime Devos
Re: Running Compiled Guile Objects
On Sun, 2024-12-15 at 00:43 +0100, Maxime Devos wrote: > > > 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/ > > > > ...and https://gcc.gnu.org/wiki/JIT > > > > 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 :) > > Are we talking about implementing a ‘to machine code’ compiler for > Guile, or about implementing an ‘AOT to machine code’? I confess I have no idea what the conversation was about; I was just responding to Basile's email to the "jit" mailing list :) > Guile already has the former – it has a JIT (bytecode -> machine > code) for some systems. > > For what it’s worth -- I never worked with libgccjit or with the JIT > code of Guile: > > I imagine a basic (POC) AOT approach for Guile would be to let it > compile AOT – with the JIT implementation, except adjusted to be > relocatable and to add relocation information. As far as I can tell, > libgccjit does not seem to support relocations and doesn’t say > anything about whether the results are position-independent or not > (so not suitable fo AOT), though presumably there are ways around > that given the existence of gccemacs. FWIW libgccjit builds position independent code, and can be used to build dynamic libraries (which is what I believe gccemacs is doing). Dave
Re: AOT compiler (was: Running Compiled Guile Objects)
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 wrote: > Thanks for the inspiring sharing! 👏 > > On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch > 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 >> Date: Sun, Dec 15, 2024, 02:11 >> Subject: Re: Running Compiled Guile Objects >> To: Nala Ginrut , Hakan Candar < >> hakancan...@protonmail.com> >> Cc: guile-u...@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
Re: AOT compiler (was: Running Compiled Guile Objects)
> FWIW libgccjit builds position independent code, and can be used to build dynamic libraries (which is what I believe gccemacs is doing). To my limited experience, libgccjit can generate executable ELF and relocatable .so, folks may pass gcc parameters for common considerations in final codegen. That's why I think libgccjit is good choice for Guile AOT. The whole process and codegen can be consistent with common gcc cases and GNU conventions. Best regards. On Sun, Dec 15, 2024, 10:59 Nala Ginrut wrote: > 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 wrote: > >> Thanks for the inspiring sharing! 👏 >> >> On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch < >> bas...@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 >>> Date: Sun, Dec 15, 2024, 02:11 >>> Subject: Re: Running Compiled Guile Objects >>> To: Nala Ginrut , Hakan Candar < >>> hakancan...@protonmail.com> >>> Cc: guile-u...@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 (GPLv
