sealable-metaobjects icon indicating copy to clipboard operation
sealable-metaobjects copied to clipboard

Seems broken on SBCL

Open goose121 opened this issue 4 years ago • 0 comments

When testing the example in the README on SBCL 2.1.9 (modified so it will actually compile in the quicklisp version of the library, seeing as fast-generic-function no longer exists, as follows)

(defgeneric generic-binary-+ (a b)
  (:generic-function-class sealable-metaobjects:sealable-standard-generic-function))

(defmethod generic-binary-+ ((a number) (b number))
  (+ a b))

(defmethod generic-binary-+ ((a character) (b character))
  (+ (char-code a)
     (char-code b)))

(sealable-metaobjects:seal-domain #'generic-binary-+ '(number number))
(sealable-metaobjects:seal-domain #'generic-binary-+ '(character character))

(defun generic-+ (&rest things)
  (cond ((null things) 0)
        ((null (rest things)) (first things))
        (t (reduce #'generic-binary-+ things))))

(define-compiler-macro generic-+ (&rest things)
  (cond ((null things) 0)
        ((null (rest things)) (first things))
        (t
         (flet ((symbolic-generic-binary-+ (a b)
                  `(generic-binary-+ ,a ,b)))
           (reduce #'symbolic-generic-binary-+ things)))))

and then compiling and disassembling the provided functions, triple-1 looks like this:

; disassembly for TRIPLE-1
; Size: 38 bytes. Origin: #x534D6960                          ; TRIPLE-1
; 60:       498B4510         MOV RAX, [R13+16]                ; thread.binding-stack-pointer
; 64:       488945F8         MOV [RBP-8], RAX
; 68:       0F28D1           MOVAPS XMM2, XMM1
; 6B:       F30F58D1         ADDSS XMM2, XMM1
; 6F:       F30F58D1         ADDSS XMM2, XMM1
; 73:       660F7ED2         MOVD EDX, XMM2
; 77:       48C1E220         SHL RDX, 32
; 7B:       80CA19           OR DL, 25
; 7E:       488BE5           MOV RSP, RBP
; 81:       F8               CLC
; 82:       5D               POP RBP
; 83:       C3               RET
; 84:       CC10             INT3 16                          ; Invalid argument count trap

while triple-2 looks like this:

; disassembly for TRIPLE-2
; Size: 61 bytes. Origin: #x5365D3FE                          ; TRIPLE-2
; 3FE:       498B4510         MOV RAX, [R13+16]               ; thread.binding-stack-pointer
; 402:       488945F8         MOV [RBP-8], RAX
; 406:       4883EC10         SUB RSP, 16
; 40A:       488BD6           MOV RDX, RSI
; 40D:       488BFE           MOV RDI, RSI
; 410:       B904000000       MOV ECX, 4
; 415:       48892C24         MOV [RSP], RBP
; 419:       488BEC           MOV RBP, RSP
; 41C:       E881CADCFC       CALL #x50429EA2                 ; #<FDEFN GENERIC-BINARY-+>
; 421:       480F42E3         CMOVB RSP, RBX
; 425:       488B75F0         MOV RSI, [RBP-16]
; 429:       488BFE           MOV RDI, RSI
; 42C:       B904000000       MOV ECX, 4
; 431:       FF7508           PUSH QWORD PTR [RBP+8]
; 434:       E969CADCFC       JMP #x50429EA2                  ; #<FDEFN GENERIC-BINARY-+>
; 439:       CC10             INT3 16                         ; Invalid argument count trap

and seems to be running only as fast as a version which uses a generic-binary-+ based on non-sealable generic functions (I did a two-tailed T test and it came out p = 0.4871823765308979, indicating they were very close indeed). Am I using this library wrong, or did something in SBCL change that broke it?

goose121 avatar Dec 21 '21 22:12 goose121