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 04:28:34 -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> <87zg2uqdmv.fsf@localhost> <87edk3gbh3.fsf@dataswamp.org> <87jztvnuyb.fsf@localhost> <875y5bdutt.fsf@dataswamp.org> <87y1i6e1uh.fsf@localhost> <874jkub40o.fsf@dataswamp.org> <87jztqdw2l.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34558"; 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 10:29:48 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 1qXdoh-0008kF-MQ for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 10:29:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXdna-0000al-AA; Sun, 20 Aug 2023 04:28:38 -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 1qXdnY-0000aW-47 for emacs-devel@gnu.org; Sun, 20 Aug 2023 04:28:36 -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 1qXdnW-0003Kw-JQ; Sun, 20 Aug 2023 04:28:34 -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=DCIyQzdeRbZ8xytqvZMxgaEbzsdQH/SrdoZsAUTbIG4=; b=JpSYr8b1q/3N PEV+ifMBSpz/4j7n0WbPA2yp1S/1emOLhjg9Dgfyqy/uDw/tuUZIEWEhgqhpKkgJx4BMDQpnaxuDu LLswwQzPxlJuQMFPEZ6DtqvE8kujrq9u36+Og5a42d8kRsmQQfP4b2SQJx1zD1eCs+9fNhwjaq7dJ P+Il3r8ECJK+mZ2UhlH3g26PFRTZ6ztqyFw2hFQpFsJ7AKW217yqaDEj9mv4g/jjs8DBBQAB3h94C neZ5sg1/suHIIeTOIIg1bg737w6i6yny3gKrMtUt8YBBIRe3ZxBLzNc0BfQvYlgpvYqGj+tBnp1Rj yELCsOFQ431jjq9/5YV9uA==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qXdnW-00063a-CX; Sun, 20 Aug 2023 04:28:34 -0400 In-Reply-To: <87jztqdw2l.fsf@localhost> (message from Ihor Radchenko on Sun, 20 Aug 2023 07:14:42 +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:308955 Archived-At: And even this is not a definitive answer. I do not think that we can point out a single reason why SBCL is faster. I am not even sure if SBCL is _always_ faster. Always faster than what? What are you comparing? SBCL is a compiler, Emacs is more than that. 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 ; 3F: 488B042590060020 MOV RAX, [#x20000690] ; 47: 488945F8 MOV [RBP-8], RAX ; 4B: 48892C2560060020 MOV [#x20000660], RBP ; 53: 488B142518000020 MOV RDX, [#x20000018] ; 5B: 488D4210 LEA RAX, [RDX+16] ; 5F: 483B042520000020 CMP RAX, [#x20000020] ; 67: 7770 JA L2 ; 69: 4889042518000020 MOV [#x20000018], RAX ; 71: L0: 488B0570FFFFFF MOV RAX, [RIP-144] ; "foo" ; 78: 488902 MOV [RDX], RAX ; 7B: 48C7420817010020 MOV QWORD PTR [RDX+8], #x20000117 ; NIL ; 83: 80CA07 OR DL, 7 ; 86: 48312C2560060020 XOR [#x20000660], RBP ; 8E: 7402 JEQ L1 ; 90: CC09 INT3 9 ; pending interrupt trap ; 92: L1: 4C8D4424F0 LEA R8, [RSP-16] ; 97: 4883EC30 SUB RSP, 48 ; 9B: BFAF0B1520 MOV EDI, #x20150BAF ; 'LIST ; A0: 488B3551FFFFFF MOV RSI, [RIP-175] ; '(VALUES ; (SIMPLE-ARRAY ..)) ; A7: 488B0552FFFFFF MOV RAX, [RIP-174] ; '("foo") ; AE: 498940F0 MOV [R8-16], RAX ; B2: 488B054FFFFFFF MOV RAX, [RIP-177] ; "(CAR \"foo\")" ; B9: 498940E8 MOV [R8-24], RAX ; BD: 49C740E017010020 MOV QWORD PTR [R8-32], #x20000117 ; NIL ; C5: B90C000000 MOV ECX, 12 ; CA: 498928 MOV [R8], RBP ; CD: 498BE8 MOV RBP, R8 ; D0: B882B12620 MOV EAX, #x2026B182 ; # ; D5: FFD0 CALL RAX ; D7: CC10 INT3 16 ; Invalid argument count trap ; D9: L2: 6A10 PUSH 16 ; DB: FF1425B0080020 CALL [#x200008B0] ; #x21A00540: LIST-ALLOC-TRAMP ; E2: 5A POP RDX ; E3: EB8C JMP L0 NIL * > But isn't that what we do already with compilation and in > particular native compilation, why can't that add > optimizations for the native system? If we talk about type checking, Elisp uses dynamic typing and compilation cannot do much about it. Native compilation also does not touch C subroutines - the place where typechecks are performed. SBCL implements a Lisp, Lisp by definition is dynamically typed.