From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Ihor Radchenko <yantar92@posteo.net>
Newsgroups: gmane.emacs.devel
Subject: Re: Shrinking the C core
Date: Mon, 21 Aug 2023 05:06:15 +0000
Message-ID: <87pm3h56ig.fsf@localhost>
References: <20230809094655.793FC18A4654@snark.thyrsus.com>
 <874jkub40o.fsf@dataswamp.org> <87jztqdw2l.fsf@localhost>
 <E1qXdnW-00063a-CX@fencepost.gnu.org> <87msym9i4r.fsf@dataswamp.org>
 <E1qXkGM-0005IS-PJ@fencepost.gnu.org> <877cpp914t.fsf@localhost>
 <83fs4dwwdo.fsf@gnu.org> <874jkt90a5.fsf@localhost>
 <E1qXlIx-0000Rv-Vu@fencepost.gnu.org> <87y1i57jqi.fsf@localhost>
 <E1qXm5P-0002OC-2I@fencepost.gnu.org> <87pm3h7h8k.fsf@localhost>
 <E1qXnZW-00006Y-S0@fencepost.gnu.org> <87h6ot7cf3.fsf@localhost>
 <87edjx7c0b.fsf@localhost> <831qfxw2cx.fsf@gnu.org>
 <87v8d95918.fsf@localhost> <87zg2lav4b.fsf@yahoo.com>
 <87sf8d57wf.fsf@localhost> <87r0nxatu1.fsf@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="15463"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: Eli Zaretskii <eliz@gnu.org>, ams@gnu.org, incal@dataswamp.org,
 emacs-devel@gnu.org
To: Po Lu <luangruo@yahoo.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 07:06:43 2023
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1qXx7i-0003qF-Tr
	for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 07:06:42 +0200
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1qXx6z-0004g7-Kc; Mon, 21 Aug 2023 01:05:57 -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 <yantar92@posteo.net>)
 id 1qXx6y-0004ft-3y
 for emacs-devel@gnu.org; Mon, 21 Aug 2023 01:05:56 -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 <yantar92@posteo.net>)
 id 1qXx6t-0000xk-Dk
 for emacs-devel@gnu.org; Mon, 21 Aug 2023 01:05:55 -0400
Original-Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 838A0240104
 for <emacs-devel@gnu.org>; Mon, 21 Aug 2023 07:05:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1692594349; bh=wPZ0DirkUQcppqslFMFTl1lDHbpkYp4vLosf1tFePH8=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=TZgpc71LhKrBwA+JDCVWxEWE47g7M3yjn0S9/cD5IN8o6GQeUZ4aPZaPZBDsNli/+
 GuD9s1l3dgrDFXj1vrSgcYA6yaT0mLmft8fRWqAh30rmQRMeujm0GZu6r6Qk8s36gE
 H4oQuwdDQu6vzk7weejL9OzhOS/czLBrkUgONIa3jhYU8YUkk8Rkg8Iu/bTGlmfJXf
 Pugsjvs9ZGIBRVoAnAhLhbaXYYVZSn7YHRYWskHYuZz3rakIdJRNae5exiS0fbqo25
 o65jMkVKnACAYHu9BJvIANJWrI+tg93MSOIbG10g0TUcFXO4RiyTkQgIzTsWJ2w1A8
 N5o9PtRMMAb3w==
Original-Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4RTgRJ6L1Yz6txP;
 Mon, 21 Aug 2023 07:05:48 +0200 (CEST)
In-Reply-To: <87r0nxatu1.fsf@yahoo.com>
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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=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:309020
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/309020>

Po Lu <luangruo@yahoo.com> writes:

>> `car' implementation is very unlikely to change in future.
>
> Why not?

Mostly because such basic functions are rarely changed.
Of course, it is not impossible that `car' is changed in future.

>> But `floor' and other functions (we should not be limited to `floor')
>> may change their implementations. The extra "native comp" copy of the
>> implementation will need to be always synchronized with the original
>> implementation. I doubt that it is practical maintenance-wise.
>
> How and why so?  How are Fcar and Ffloor divergent in this department?

`floor' might also be rather stable. I was mostly referring to "we
should not be limited to `floor'" - it may be a problem for other
functions.

But let me rephrase it in other terms: what you propose will require
maintaining two separate implementations of subroutines - one in C, and
one specially tailored to GCC JIT psudocode. This may be doable for a
small set of core primitives, but not scalable if we want to make more
subroutines benefit from GGC JIT optimizations.

Another idea, if rewriting in Elisp is not feasible, could be somehow
structuring the internal C code in such a way that we can derive GCC
JIT pseudocode right from the C function bodies.

For example, Ffloor could be (1) split into smaller functions dedicated
to certain argument type combinations; (2) record a metadata readable by
native comp code about which small function correspond to different
argument types. Then, native comp can emit direct calls to these smaller
(and faster) functions when the type is known.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>