From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 21 Aug 2023 10:46:59 +0000 Message-ID: <87sf8cfza4.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87jztqdw2l.fsf@localhost> <87msym9i4r.fsf@dataswamp.org> <877cpp914t.fsf@localhost> <83fs4dwwdo.fsf@gnu.org> <874jkt90a5.fsf@localhost> <87y1i57jqi.fsf@localhost> <87pm3h7h8k.fsf@localhost> <87h6ot7cf3.fsf@localhost> <87350d78j1.fsf@localhost> <87msyk6hhs.fsf@localhost> <878ra46ekc.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14855"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 12:47:07 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 1qY2R9-0003dM-KQ for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 12:47:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qY2Qh-0007DE-OY; Mon, 21 Aug 2023 06:46:39 -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 1qY2Qe-0007D0-41 for emacs-devel@gnu.org; Mon, 21 Aug 2023 06:46:36 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qY2Qb-0004Qb-F8 for emacs-devel@gnu.org; Mon, 21 Aug 2023 06:46:35 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id F09D0240103 for ; Mon, 21 Aug 2023 12:46:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692614790; bh=IOcL8ng/6QpbFDZt1cYYG+dHen/BLxdoOqlRCE6UbDo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=lTrVVmoXQqGslDq6n+G6Fgs9hnE3RJlzv+I2AM20R5uPJVwedgude5SRYPi0jwuE9 LNrFEsR938kzXDS9g1c0afhCKzCSv4QtUGuWdA2w7lpNmAyu80vnU27IktsgrV2zGV ECZVK47vH/4NKJEUaga2VAmu7lSaCwnq/lQ1L7t2nWl+u5k4eP80K/yLwJhcofWn0H hi9V55MxdsaSuwfeHEfj1XBk2XlSwdVtnLlYCrOrtXcO4YFpgj5qk7tfYw7ooQ7Wpn Lxnj7VoFnvqethfj6PjS/GikSDKOApsnDQ4QjmZ2pyZ4ukleAm3XcXAOTRleCqRBWR Cw/dz0dsILkqQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RTq0P1WP6z9rxF; Mon, 21 Aug 2023 12:46:29 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:309048 Archived-At: "Alfred M. Szmidt" writes: >> I am talking about the end result (native code) we achieve after >> converting source Elisp into byte-code and then into native code. Not >> about the byte code. > > The end result depends on what the Emacs Lisp compiler produces, > Native compilation will not figure out that using ASSQ is better when > calling ASSOC has fixnums in it (see byte-opt.el for example of the > required Lisp wrangling that is required -- and something that SBCL > does in a much larger scale). > > That is the type of optimizations that matter more than JIT. Native compilation can actually do it. And it can (AFAIU) do it more efficiently compared to what we have in byte-opt.el, because it uses more sophisticated data flow analysis to derive type information. If we look into Fassoc implementation, it starts with if (eq_comparable_value (key) && NILP (testfn)) return Fassq (key, alist); ... eq_comparable_value (Lisp_Object x) { return SYMBOLP (x) || FIXNUMP (x); } If we have a "libgccjit IR" implementation for Fassoc (see "3.8final (code layout) in https://zenodo.org/record/3736363", the type information can transform assoc call into assq call during compile time. The other question is that `assoc' in particular is currently not implemented in "libgccjit IR". But it can be added, together with other important primitives. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at