From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 21 Aug 2023 13:34:00 +0800 Message-ID: <87edjxarhz.fsf@yahoo.com> 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> <87edjx7c0b.fsf@localhost> <831qfxw2cx.fsf@gnu.org> <87v8d95918.fsf@localhost> <87zg2lav4b.fsf@yahoo.com> <87sf8d57wf.fsf@localhost> <87r0nxatu1.fsf@yahoo.com> <87pm3h56ig.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="27293"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , ams@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 07:34:54 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 1qXxYz-0006m5-AX for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 07:34:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXxYN-0000bJ-W0; Mon, 21 Aug 2023 01:34:16 -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 1qXxYM-0000b5-3v for emacs-devel@gnu.org; Mon, 21 Aug 2023 01:34:14 -0400 Original-Received: from sonic302-20.consmr.mail.ne1.yahoo.com ([66.163.186.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qXxYJ-0006Et-M1 for emacs-devel@gnu.org; Mon, 21 Aug 2023 01:34:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692596049; bh=hgBd0w9HjiIZO/k0vvdpAg7IFl7q56d9EXHTxeM0vf8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=FqUPjqgxOliM+qYUApKEVdfrcoGzFvwS/aya+RZxcxH997qu7C2+REhiLGGQMGcxyVzhn7OFRDY0UTdOB31giNzPntnU2P7pm/2XQmOBzaZJ4NH9jDtoyLRK9iWFJfFrJHJ+aYfbFQglV2+P2Xw4T9rU+5yiUPhAiIW1ZYvVFPdtsr+ZYDIROCK8+ez32cdTX5fXEK9GAhd1Zxm1VhmXrq6pEEBZ/Fuj5PGcC6inToyxHWKpzIJyqNbSXTexFbfQ4D47T69n1b0y0E51zR0qk36Zw5l0Ge7VG4yPdwMCU74Mx12n23kHInnnFF0R0s3HzsRec/7KlsU8YoRrwRq8Og== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692596049; bh=X9eZYa97CDVwb3crc+fBNICHODaJIb/oHXNR85jUP2E=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=enJEQkK3svqjYRliIvZGiwd+WlCWeBp98WotnHI2g1uMTDU8Y9CfSvc4I2HPfTO2+AtzH5cd+E3HEsx1lr07XqNgSFj5h/t/FdooyQCirEHmHXlW63iKWDRPryxQz3suXPtMnW7Vr3KcebrP5BJTK9f7riggZgipmXd3xN/hDtf2vvtDoODtQFI/eqk32Si5m05RoVV1cFFW4j+kwewKG/LninDeH5OVGiiqz1ubwUtp/KJqWFgJNnTCdwHlWP16d+SZemfT00l64dORmgzTvGWX7pAFu+CMJf18Ib8mTT/O5emD3+qHYaMnIx67oCsSwsgzNDs0KdpQAO/2+A6ZXg== X-YMail-OSG: B1B6NgcVM1m81Agoi00zsENrNLQRPk5O1COwAyhz6hRpZCO8fSukIAg.HKNs9xT GQLiCz4MR42Yx_52h5mP3j_c8c.ToTip2khtrA3kuiLbvCkV6UPzTFHgQeqSa5jcNfq7jopwMcbd kzUwy8wuJZbP2t4ybrvYcsEHCbBqVdp4WxU6FTZk4WZIeIk7EbU6POImbTRkBlv8RDqvdu3I69Zg h_f.i.V6gvFEVuCwItKSq81PUhherQ9D0zilbqr9myTUqVS20aOODUaQWzZgGf8me2cMBxVr48QN nyQlgYm0AZTSWuTIMJcIDhvD8iJU2xJ9P.GTpaGP3lmp9bqaEzbcJx5yKMdZV0waw1d1USEYUs5K IZ7_jW0AonokwV4Fny7sKwNaVMSLAphqY035O.bAP8BCgm07bmnJm7VvMvHanQUxmWohdE_uPjBD .pJLFTxEYDPWEmfak7pzBpqy01cgExhKjPSiQ0Zd3D88tKK_0kWPU.QPbH9kiTNqa4LS7KVBAXRJ FymyVlH9SI9GkvyTkDWe19_iEn5enxUkDAiX1IdFU4GFtESP1eaI7jhnzQrSH05vzqYRUP8E9x9b J6Hb20L7QOCSt81PImYbg2g0g0U91ByAw5hZCHKzT1IKTJZv.mqYzjO3KQRnFX5pOm0V34MNWBOA SivGCxxt8YoTMhOsAnD1x3W5auViBPERn6HgFUeU3DQbVOUg0UZL1y4.EF.ybw5CQoFtpKM.5R4M VnuV214hUtHAW1kju9zk0elNnqWSea0b2cBMOrB.nWvUV.3lhuCPOaB3Q0o3NQE4CQR0Pe79Z2fx W8CcnLrCbi_RQIHj5At.prgd.GVSVziwbQHB_AbBLe X-Sonic-MF: X-Sonic-ID: 3461ad0b-876f-49b3-a024-6fa66bf517ed Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 21 Aug 2023 05:34:09 +0000 Original-Received: by hermes--production-sg3-69654d8bd-sbrjf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eda646f1a7f93cd17168fc318f1da031; Mon, 21 Aug 2023 05:34:06 +0000 (UTC) In-Reply-To: <87pm3h56ig.fsf@localhost> (Ihor Radchenko's message of "Mon, 21 Aug 2023 05:06:15 +0000") X-Mailer: WebService/1.1.21732 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.186.146; envelope-from=luangruo@yahoo.com; helo=sonic302-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:309023 Archived-At: Ihor Radchenko writes: > 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. I'm inclined to believe that type checks within those more complex functions do not contribute so much to the runtime of most native-compiled functions as the small set of arithmetic primitives do. > 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. That sounds like over-engineering, especially given that an actual performance problem (in real text editing tasks) has yet to be ascribed to Ffloor. Can we all stop bikeshedding over this now? By this point, the subject of this thread bears absolutely no relation to the debate within.