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: Sun, 20 Aug 2023 16:34:49 +0000 Message-ID: <871qfx8yfq.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87fs4pkkqi.fsf@dataswamp.org> <87jztzkgct.fsf@dataswamp.org> <87y1if8j8t.fsf@linux-m68k.org> <87y1ifi9fv.fsf@dataswamp.org> <87zg2uqdmv.fsf@localhost> <87edk3gbh3.fsf@dataswamp.org> <87jztvnuyb.fsf@localhost> <875y5bdutt.fsf@dataswamp.org> <87y1i6e1uh.fsf@localhost> <874jkub40o.fsf@dataswamp.org> <87jztqdw2l.fsf@localhost> <87msym9i4r.fsf@dataswamp.org> <877cpp914t.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="31542"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Sun Aug 20 18:35: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 1qXlOM-0007vP-Di for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 18:35:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXlNn-0003ak-Oe; Sun, 20 Aug 2023 12:34:31 -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 1qXlNl-0003aW-QR for emacs-devel@gnu.org; Sun, 20 Aug 2023 12:34:29 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXlNi-0008As-T7 for emacs-devel@gnu.org; Sun, 20 Aug 2023 12:34:29 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A5DBD240027 for ; Sun, 20 Aug 2023 18:34:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692549264; bh=rwqXsAVzqnp9ZZpQ91QsB537jAHDBtvnOkHZD18MZ4s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=NpISeEQSfMmqQd1UW5gks9TgA9ytrzKFb1enC/jF4jUWq9tSxXeb36JbLPDDg6NXv b/dOYHFQSMtoUf5aDQR4BJ5HEiYHH2i/sxEUJ9bgfJ/PJTJ9yJMr5nbrsv0u4SarBR zn1BJi2FkjB9el2/uckXkZN4pXl08VUjwSECJ50ZwkYjJdce+13U1+ZnfCFhfz6A6r azWhfYgRzx4EIU2u1JWdmYUOPlE3pNrBow22jXkpoRI3Z1FDSw8G0RCexgyAZtxZgO eal2IMe3G8ftFSTn+6a+egQv9RTW3I8XlISKLymM4aXB7eUQv33CDbl/lA4/VRhtkL 3U6KTMedReFoQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RTLmJ0JnWz6tw5; Sun, 20 Aug 2023 18:34:23 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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=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:308972 Archived-At: "Alfred M. Szmidt" writes: > I'll suggest that you try to figure it out, it is a good exercise. > But the big difference is that there is much more indirection between > what SBCL does and what Emacs Lisp does. SBCL is a much more > aggressive optimizer of code. Emacs simply cannot optimize much of > the call _flow_. Ok. Here is what I got for Elisp `car': Dump of assembler code for function Fcar: Address range 0x200250 to 0x20026c: 0x0000000000200250 <+0>: lea -0x3(%rdi),%eax 0x0000000000200253 <+3>: test $0x7,%al 0x0000000000200255 <+5>: jne 0x200260 0x0000000000200257 <+7>: mov -0x3(%rdi),%rax 0x000000000020025b <+11>: ret 0x000000000020025c <+12>: nopl 0x0(%rax) 0x0000000000200260 <+16>: test %rdi,%rdi 0x0000000000200263 <+19>: jne 0x5007d 0x0000000000200269 <+25>: xor %eax,%eax 0x000000000020026b <+27>: ret Address range 0x5007d to 0x5008b: 0x000000000005007d <-1769939>: push %rax 0x000000000005007e <-1769938>: mov %rdi,%rsi 0x0000000000050081 <-1769935>: mov $0xaf20,%edi 0x0000000000050086 <-1769930>: call 0x4ffc7 Does not look too bad in terms of the number of instructions. And I do not see any obvious indirection. > And then you will generally either have byte compiler, or interpreted > code to handle (ignoring native compile, since must people probobly > still use the VM) -- all code in SBCL is comnpiled (EVAL is essentially > a call to the compiler, and then executed). IMHO, we should not ignore native compile. If we want to improve the peak performance of Elisp, native compile should be essential part of it. Then, for real improvements, we should better focus on what native compile cannot optimize. > As an idea, I would take the Gabriel benchmarks and run them in SBCL > vs. Emacs. Take one, and investigate what they do in detail... You > will see that the two worlds are universes far apart. Sure. That's what I asked Emanuel to do. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at