From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.comp.gcc.jit,gmane.lisp.guile.user Subject: Re: AOT compiler (was: Running Compiled Guile Objects) Date: Sun, 15 Dec 2024 11:08:25 +0900 Message-ID: References: <769073d434c2ed5fb7937c85da240aa5df4d854a.camel@starynkevitch.net> <49d9827f4455076cc066add3e51f0e882b59e9b7.camel@starynkevitch.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a7d6600629458af3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19573"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Maxime Devos , team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org, jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, "dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org To: Guile User Original-X-From: jit-bounces~gcgj-jit=m.gmane-mx.org-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org Sun Dec 15 03:08:52 2024 Return-path: Envelope-to: gcgj-jit@m.gmane-mx.org Original-Received: from server2.sourceware.org ([8.43.85.97]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tMe3w-0004tJ-63 for gcgj-jit@m.gmane-mx.org; Sun, 15 Dec 2024 03:08:52 +0100 Original-Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 06148385841D for ; Sun, 15 Dec 2024 02:08:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06148385841D Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=Sw8+CTKi Original-Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 15C463858C48 for ; Sun, 15 Dec 2024 02:08:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 15C463858C48 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 15C463858C48 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1734228517; cv=none; b=QgetfBeEJDV3oTb4lraoBGtBbi4Xr0+krZF+eTbsK4bofjgGxxUtRG9FiDCqZa2n/M8iYldwpGUfFI7ZZPHmrEA89EUskaE1l2LnK8C8M6p4zH4BEAymkG8w3aknXB03OCQxk9mCNdMDjRlzTWAH8m0Dv8tRdwRpFsVjGD6ekfw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1734228517; c=relaxed/simple; bh=XJ8zAMjtFR1YGu86sKNAX84NUS+z7sIWgYP14xoylLo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=vEtatvHdCNcmD7PTIi40I8czkQkBToxv+JibXU94ZeEbNYN/5NefS0meK9hBLXNdUtybImtQsmnusjnSRrBDVWhUakoc5UbysGS8ySVcdOuKqu5BG7xVxzIomf3wFmp8euKkmWS1XdLWcpAzjeUiwwskLQYwmexsJHnpbUijOxM= ARC-Authentication-Results: i=1; server2.sourceware.org Original-Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-8019f048bc7so2037181a12.1 for ; Sat, 14 Dec 2024 18:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734228516; x=1734833316; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yjWrDKEvxPlTG3wyqGs26Ufr1DVDNMpBlbjE7hHNwaw=; b=Sw8+CTKiDnU0XPCdTXoUjerE6GUGqsekCSedPQ6Nlbq7SdnRXgoy7LDgw0QyyUSw6H r7/GH9Xd8UDtbs5BuOvao6uOJXQ5CqQmbyHZKG6xK2gqHottNALlC6FhbXJ5EabXxYtc /llnBQ82/6pdqsC9SxgQHcA8tvQcvsdGSnrra+9++EeVReRaBI72flqkYFOvNsn3AEeC uGoXTyvgwSaHPXDKDCGvHB+Kf2VsdMGE+x/wHpMimUQcGqqWjI8weCln3w3eFfgIH+Ch oW8WxbhO7dsZU10MNHzTkupbNr+kciDi/pWYqbFTwq+6HZ/P3zJ9/6TEKktr20oCJ6JL NWhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734228516; x=1734833316; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yjWrDKEvxPlTG3wyqGs26Ufr1DVDNMpBlbjE7hHNwaw=; b=OAWQ2B/UKVkzYzabZxyPhzBwseEMW1ejIPt4/s29/FCFYUHziJFaE36Bl2lno/BB+E RaNBKufC3hV87eVL3jhjVsiHs2OPaVUrgOTZaIU34fWhfK2npwpcKIpUBCYBot+qh4bl U5BdWwDqckuNXEU6XaCPfF+9iMoVC7DKPFwYWr0HPUEKdoQea6TSKcqyAZJsK2eTftSa kDqzFt7AA+uLZh9CUZ6ptPM+wHIg6wp/Xdr3crTAie8al+abvukG2SM2umD9vR/gZzjj 5n0POTNdXC+JU1kgVI29MLxM3BFW/wdS2yBqUFxauTWUqlWky9NZUaR7ndqfCTyxEmfJ p33g== X-Forwarded-Encrypted: i=1; AJvYcCVW7ynix0VM9ms4tD34OQxF0EPgFdpAHL/paIZTP70yr9a84msX6el1ykahHiXD/9U2src=@gcc.gnu.org X-Gm-Message-State: AOJu0YwqAjY+uk5jI+qWMeC2KDkOEiNKFrwZ0HoqCXAYJwv3Qkcax6o8 VR7WzrGJ0pq9WU7qINROK/FUVTZfkdwxxIgTj9OETFXObLSK1kbh4+7IojMZ0zRn6GUoYqb+6nC EckLrv4Dt8vw6FtXBTAn20Jj8aTs= X-Gm-Gg: ASbGncuU1FGJRTwJD4/bcrAcwrQDQk+NGofgWqQKNs8xS/RwX3VLwAkgPvDNHOTT5DW 89eTQCDtxKP4UaVf+LEKHSu9yWVeNdIfaG/h6bw== X-Google-Smtp-Source: AGHT+IFWw6BG/CjQf+2TbDCiPxHByScsQUktPErw2QS2TPYC+JXrZqz2yntdPrn98f1onu60D9zPHXAmKlVrfKExIT0= X-Received: by 2002:a17:90b:4b0f:b0:2ee:bbd8:2b7e with SMTP id 98e67ed59e1d1-2f28fb6aba4mr14655950a91.12.1734228515999; Sat, 14 Dec 2024 18:08:35 -0800 (PST) In-Reply-To: X-BeenThere: jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: jit-bounces~gcgj-jit=m.gmane-mx.org-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org Xref: news.gmane.io gmane.comp.gcc.jit:1948 gmane.lisp.guile.user:20002 Archived-At: --000000000000a7d6600629458af3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 l= ot > 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 b= e > 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! =F0=9F=91=8F >> >> 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. >>> 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 ow= n >>> work for JIT and finally use libgccjit for codegen. =F0=9F=98=81 >>> >>> 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 suitab= le >>> 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 sadl= y >>> 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 < >>> hakancandar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org> >>> Cc: guile-user-mXXj517/zsQ@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) >>> >>> >>> -- >>> >>> Basile STARYNKEVITCH 8 rue de la Fa= =C3=AFencerie >>> 92340 Bourg-la-Reine, France http://starynkevitch.net/Basile & https://github.co= m/bstarynk >>> >>> --000000000000a7d6600629458af3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> FWIW libgccjit builds position independent code, and ca= n 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 considera= tions in final codegen.

That's why I think libgccjit is good choice for Guile AO= T. The whole process and codegen can be consistent with common gcc cases an= d GNU conventions.

Best regards.

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

Hi folks! Please reply AOT t= opic in this thread.


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

Thanks for the work!=C2=A0

At least in Guile community, now that we already have JIT with GN= U 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:
=C2=A0 https://akrl.sdf.org/gccemacs.html


It looks super interesting!

<= p dir=3D"ltr">They created a high level IR just like GIMPLE, which named LI= MPLE. 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 compile= r 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.

Th= e compiler tower is so flexible that it's possible to try it as a plugi= n.=C2=A0

I agreed with @mikael about losing weight of Gui= le. The AOT feature can be a plugin to install as guild tools. Of course, p= lugin 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! =F0=9F=91=8F


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 w= rote:
@basile I'm= glad you raise this topic, I've played lobgccjit with a toy project.

I would say libgccjit is a wrong n= ame since it's more like a tool for AOT.
Of cour= se, one may still use it for JIT, however you have to do your own work for = JIT and finally use libgccjit for codegen. =F0=9F=98=81

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.

<= /div>
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 o= ptimization strategy.

A few years ago I did experi= ment (see=C2=A0https://ar= xiv.org/abs/1109.0779=C2=A0...) 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 r= elated experiment is my manydl.c thing on=C2=A0https://github.com/bstarynk/misc-basile= =C2=A0- it is/was a toy program that I wrote which generates a lot of rando= m C code (in many thousands of C files), compile it to a plugin, and use dl= open 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=C2=A0

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: Runnin= g 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<= /a> <guile-user-mXXj517/zsQ@public.gmane.org&= gt;, <jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org><= br>


On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
&= gt; 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
guil= e could use the GNU CC libgccjit library which is part of the GCC
compil= er.
https://gcc.gnu.org/onlinedocs/jit/

This libgccjit layer= of the GCC compiler is stable and maintained C API
and has some obsolet= e C++ API (which seems unmaintained in december
2024). Most of the libgc= cjit 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 op= en 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 b= asis 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 garb= age collector and some
persistence (to textual files). Since it is GPLv3= + licensed, its code
could be reused in a future GUILE major version. Re= fPerSys 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 k= now how to make that happen)
--000000000000a7d6600629458af3--