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 11:22:46 -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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9894"; 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 Sun Aug 20 17:23:17 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 1qXkGq-0002Lo-0G for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 17:23:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXkGP-0007ie-11; Sun, 20 Aug 2023 11:22:49 -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 1qXkGN-0007iU-Ln for emacs-devel@gnu.org; Sun, 20 Aug 2023 11:22:47 -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 1qXkGM-0000qD-Vf; Sun, 20 Aug 2023 11:22:46 -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=rl18nIE5vNcA3ZEmz2HxSmEmL6uYnDLzmSGgibCD7GU=; b=dK/YS3LXUuuS iic4AGKIphbd66r7bU/VxJczXYkzYVmPJYxdDZ1/KNjWqTfwsQSxVYKx9JhKIDGt28eIv9aJnmfVg y6e8pAyu5Z87S1ciKv0+iLU5TVnCCVb3j0L+EssqWoqUBuVmKANR69pqonJqn4nGl1MWRI7c9vEAI Zji/j9tFy+RuVaxBzHR73X64dHpgiuFDp/IiXJxJ+/PWSBO7ITfpO8FKsJ1w752TYtk5NWclGUb3+ KfcVSxHV70S2yRXa0+neOl5AUZQB52a9ACerhZaqe6Rra8nHy6TkmeKsrEpm3k1n/PS69J1vxXH9i J8tgb5TaMmnI6zLJFxYxhg==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qXkGM-0005IS-PJ; Sun, 20 Aug 2023 11:22:46 -0400 In-Reply-To: <87msym9i4r.fsf@dataswamp.org> (message from Emanuel Berg on Sun, 20 Aug 2023 11:29:24 +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:308965 Archived-At: 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 > ; 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 > * 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". >> 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. Only for the kind of use (code) that we are used to. See this: https://medium.com/@MartinCracauer/static-type-checking-in-the-programmable-programming-language-lisp-79bb79eb068a This has literally nothing to do with the difference between static typing, and dynamic typing. The author, and you, have it completeley backwards to the point where I need to suggest that you take sometime to read up on basic Lisp compilers, and then look into very good Lisp compilers (CMUCL and SBCL come to mind). Since it is already showing that it is very hard to even explain basic Lisp compiler behaviour without going to fundamentals.