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: Sun, 20 Aug 2023 12:03:30 -0400 Message-ID: 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3899"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Sun Aug 20 18:04:12 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 1qXkuR-0000iO-Qj for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 18:04:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXkto-0004kj-OT; Sun, 20 Aug 2023 12:03:32 -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 1qXktn-0004jw-Uk for emacs-devel@gnu.org; Sun, 20 Aug 2023 12:03:32 -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 1qXktm-0001Qq-Tf; Sun, 20 Aug 2023 12:03:30 -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=Lhf6EOwAeX7ixT8LA4pTg7fWcXM8hmuBxJXiuER8mE4=; b=Ek7DkHpCzx9G 3FXdJP+8BYkKr6F11Wd1cMkJ98AblNVLSz5XXl8bDVSVpvSsyLePsuSRkFQIE7ePrDeG32tLXXrl2 9obnOzW6ouZ7KgFG+KgSMTyWJMQSoobB1gJbcH8N6OYFCja6/+W9h/kXS7nxE0RWfvEpvBVZYDJXi KURKe8azx6T9lN5/GmfIOndiGHtCiU0JPBbCtIZw1XBXIVfIhAfw0NaZLa9zuGkHex4vr8o16Bq+r DmemYSlCZyFb/hhl6Mba/AVm2VlB8ZO3mLFiJYic6jeyhRadJQfa2msjA6RzpyblylEKF0GebJeEe nTp3dun5qctugANHZFlmsQ==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qXktm-0001ug-3m; Sun, 20 Aug 2023 12:03:30 -0400 In-Reply-To: <877cpp914t.fsf@localhost> (message from Ihor Radchenko on Sun, 20 Aug 2023 15:36:34 +0000) 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:308969 Archived-At: "Alfred M. Szmidt" writes: > Please keep the CC intact, not everyone subscribed. > > > It should be quite obvious why SBCL is faster than the Emacs > > Lisp VM (or even native). Just look at this call to (car > > "foo"), and compare what happens in Emacs. > > > > * (disassemble 'foo) > > ; disassembly for FOO > > ; Size: 166 bytes. Origin: #x225D873F ; FOO >> ... > Okay? > > I guess that you do not understand the above? Or what? Do you know > and understand what happens in Emacs when a similar call is done? It > is far more than "166 bytes". It would be helpful if you show us what happens in Elisp with a similar call. Especially after native compilation. 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_. 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). 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. I am asking genuinely because `car' (1) has dedicated opt code and thus should be one of the best-optimized function calls on Elisp side; (2) Fcar is nothing but /* Take the car or cdr of something whose type is not known. */ INLINE Lisp_Object CAR (Lisp_Object c) { if (CONSP (c)) return XCAR (c); // <- XCONS (c)->u.s.car if (!NILP (c)) wrong_type_argument (Qlistp, c); return Qnil; } So, it is a very simple example that can actually explain the basic differences between Elisp and CL. It would be nice if you (considering your low-level understanding) can provide us with an analysis of what is different between Elisp and CL implementations of such a simple function.