From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 14 Aug 2023 03:27:12 -0400 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <87fs4pkkqi.fsf@dataswamp.org> <87jztzkgct.fsf@dataswamp.org> <87y1if8j8t.fsf@linux-m68k.org> <87y1ifi9fv.fsf@dataswamp.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 14 09:28:28 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 1qVS03-0006KP-SG for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Aug 2023 09:28:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qVRzS-0006GU-La; Mon, 14 Aug 2023 03:27:50 -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 1qVRzI-0006EE-9j for emacs-devel@gnu.org; Mon, 14 Aug 2023 03:27:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVRzH-0003PP-Ks; Mon, 14 Aug 2023 03:27:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=5jN184tDMNn6RCqy8EdqCLUxgRDT53r811RNdPhrKJ8=; b=KoyM1e4013Uw Rwq57SPUTeRv3lqIAe0Rh559whnGcRpiVSpM2m8agDtwMawvl5IJ28qyGrehmXCfz77dYmR1JdPaP lK+WRyfnr2bfdY+awzLVMrKHjjmnaB/k8NF4kRJf74lFFioD4w309CtaGWVVBTxqKIiIV4lNvhwya ArwYm0DbntZuB8fePkwtTfbNMS0x/YdFX3s1qwxy5qAOuKv/a8Q8qcQs0K2ryP/KWA5fk2bmVr9d+ f7yQlnnq7ZjLPTwMxBVXI3fmR+WhJ+rURgf6E6tjZ3VuqFx1ars7/4MwBtjyxOwtvtgVI6sErubiq TpaliPwGyB++yBnlswwn8g==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qVRyq-0000V0-Ef; Mon, 14 Aug 2023 03:27:22 -0400 In-Reply-To: <87y1ifi9fv.fsf@dataswamp.org> (message from Emanuel Berg on Sun, 13 Aug 2023 11:21:56 +0200) 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:308705 Archived-At: Step one would be to identify why SBCL is so much faster. The short reason why SBCL is faster is that SBCL uses lots of type checking and interference, which allows it to figure out optimizations better. And then using assembly to implement such optimizations. CL code compiled without DECLARE/DECLAIM is generally slow, but can be made fast if you are very careful, and lucky that the things you need are implemented as VOPs -- which are entierly unportable. It also has the luxury of using a language that is set more or less in stone, that doesn't change constantly. Which means the developers can spend quite a bit more time on optimizing what they have. If that fails maybe one would consider ECL or some other faster, yet portable solution ... "Porting" Emacs to CL is not just slap ECL or some CL implementation on top. Adding type checking of the sort that SBCL does, would be possible but ALOT of work. It would most definitly require a entierly new VM, and with that comes dragons.