[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shrinking the C core
From: |
Alfred M. Szmidt |
Subject: |
Re: Shrinking the C core |
Date: |
Sun, 20 Aug 2023 04:28:34 -0400 |
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 ; #<FDEFN
SB-C::%COMPILE-TIME-TYPE-ERROR>
; 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.
- Re: Shrinking the C core, (continued)
- Re: Shrinking the C core, Emanuel Berg, 2023/08/13
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/14
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/14
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/14
- Re: Shrinking the C core, Emanuel Berg, 2023/08/15
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/16
- Re: Shrinking the C core, Emanuel Berg, 2023/08/19
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Emanuel Berg, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core,
Alfred M. Szmidt <=
- Re: Shrinking the C core, Emanuel Berg, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20