From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Add more supported primitives in libgccjit IR Date: Sat, 26 Aug 2023 02:47:02 +0200 Message-ID: <87cyza635l.fsf@dataswamp.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87y1i57jqi.fsf@localhost> <87pm3h7h8k.fsf@localhost> <87h6ot7cf3.fsf@localhost> <87edjx7c0b.fsf@localhost> <831qfxw2cx.fsf@gnu.org> <87v8d95918.fsf@localhost> <87zg2lav4b.fsf@yahoo.com> <87sf8d57wf.fsf@localhost> <87r0nxatu1.fsf@yahoo.com> <87pm3h56ig.fsf@localhost> <87edjxarhz.fsf@yahoo.com> <87edjw4uw4.fsf@localhost> <77daee02cf1ba0db70c1@heytings.org> <87v8d8fzr9.fsf@localhost> <87jztofwqm.fsf@localhost> <83cyzgvb70.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40515"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:SpV/XevA7Zmq5zE/uAEaNGVgIEs= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 26 07:14:11 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qZlch-000AF2-2G for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Aug 2023 07:14:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZlc9-0001jt-M2; Sat, 26 Aug 2023 01:13:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZhSR-000151-9s for emacs-devel@gnu.org; Fri, 25 Aug 2023 20:47:19 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZhSO-0006cB-On for emacs-devel@gnu.org; Fri, 25 Aug 2023 20:47:19 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qZhSM-0000yr-Jx for emacs-devel@gnu.org; Sat, 26 Aug 2023 02:47:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 26 Aug 2023 01:13:36 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309226 Archived-At: Andrea Corallo wrote: > Anyway to clarify: > > Yes the native compiler does value-type inference already > (this is how the return type of functions is computed as > well). > > Yes one can already type hint an object to the compiler, > even if this is limited to cons and fixnums (making it > generic is on my todo list). > > Yes would be great IMO to extend this mechanism to function > arguments eventually as well (I might give it a go after > summer?). > > Yes the backend tries to inline some code when possible (ex > define_add1_sub1). > > Yes we could add more of this inlining, the infrastructure > is already there but I personally had no time to work on > this :( > > Yes would be great to work on this benchmark driven, even if > this open the classic question of what is a set of > rapresentative benchmarks. > > My next activity when my time is not used by maintenance and > other activities of my life will be focused more on > safetyness and correctness I think. I'd love to work 100% on > Emacs but I must pay my bills like everyone :) Thanks for this summary! So we have - everything? We have types that are implicit (inferred), explicit (type hints), we already have a dynamically typed language but the possibility to do type checks at compile time should be possible, with subsequent pruning possible (the drop of certain run time typechecks since types are already known), we can do optimizations ourselves for certain identified areas with the proliferation of functions to do the same thing but for different types, but we can also do it in general, or on a lower level, when transforming bytecode into natively compiled machine instructions? The only thing we don't have is money so we could hire Andrea Corallo to work full time on really getting even more speed out of all of these potential areas, where the ground work and basic infrastructure is already there, just not all the wonderful things one could build on top of them? Question one, doesn't this blur the distinction between statically typed languages and dynamically typed languages? Because isn't the result a mix of the two? Question two, so SBCL compiles directly into natively compiled machine instructions, Elisp, with the byte compiler, compiles into bytecode. What does the native compiler do with that bytecode, it optimizes this for the native architecture? Is this also a blur between the bytecode and "immediately to machine instructions" modes? If so, how far is it from the latter? And how close can it get, if work is done on the byte compiler _and_ the native compiler? Because to me it sounds like we can have the best of both world, we can have complete portability with Emacs and Elisp, faster portability with the byte compiler, and really fast portability (code in execution) with the native compiler? PS. As for money, as you are aware, there is a patron sponsor scheme with people donating money. Maybe the FSF or someone can say, hey, wanna be a patron? If so, we have 3 or so current projects we encourage you to support, one is Mr Corallo's work on native compilation ... PPS. If types can be value-inferred, at what point does this happen? The byte compiler step? If so, how come it never says, "hey, this is gonna be a type error". Maybe that step hasn't been taken. It would be a cool feature IMO, if realized. -- underground experts united https://dataswamp.org/~incal