Re: AOT compiler (was: Running Compiled Guile Objects)
Thanks for all your explanation! Is the IR keeping the design of LIMPLE described in the slide? Maybe Guile AOT can be inspired from it. Best regards. On Sun, Dec 15, 2024, 20:02 Eli Zaretskii wrote: > > From: Nala Ginrut > > Date: Sun, 15 Dec 2024 19:49:59 +0900 > > Cc: guile-u...@gnu.org, maximede...@telenet.be, t...@refpersys.org, > > jit@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net > > > > Was it merged to upstream or abandoned? > > It was merged to upstream Emacs 3 years ago, and is part of the > released Emacs versions since Apr 2022. >
Re: AOT compiler (was: Running Compiled Guile Objects)
@eli I’m referring to the mentioned link https://akrl.sdf.org/gccemacs.html Though it’s named gccemacs, may not be recognized by gcc or emacs community. Actually I never heard of it before. On Reiwa 6 Dec 15, Sun at 16:39 Eli Zaretskii wrote: > > 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: AOT compiler (was: Running Compiled Guile Objects)
Was it merged to upstream or abandoned? Best regards. On Sun, Dec 15, 2024, 19:41 Eli Zaretskii wrote: > > From: Nala Ginrut > > Date: Sun, 15 Dec 2024 17:07:24 +0900 > > Cc: guile-u...@gnu.org, maximede...@telenet.be, t...@refpersys.org, > > jit@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net > > > > I’m referring to the mentioned link > > https://akrl.sdf.org/gccemacs.html > > Whose last update was on 2021-02-26, almost 4 years ago. > > This is an integral part of Emacs since long ago. >
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 >>
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! >>
