In article <········@x-privat.org>, M Jared Finder <·····@hpalace.com>
wrote:
> I've been experimenting with SBCL, seeing how good the optimizer is, but
> I've hit a pretty big snag. DISASSEMBLE is acting different under Slime
> then it is if I run SBCL at the command line! For example the function:
...
>
> What's going on that makes the Slime version *so much simpler* then the
> raw SBCL version?
Are you also using Slime to compile the function in the first place? It
looks like the function was compiled with high optimization in one case,
and with no optimization in the other.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Christophe Rhodes
Subject: Re: What's up with DISASSEMBLE and Slime?
Date:
Message-ID: <sqmztxdmcu.fsf@cam.ac.uk>
M Jared Finder <·····@hpalace.com> writes:
> What's going on that makes the Slime version *so much simpler* then
> the raw SBCL version?
Different compilation options.
Christophe
<·····@hpalace.com> wrote:
> I've been experimenting with SBCL, seeing how good the optimizer is, but
> I've hit a pretty big snag. DISASSEMBLE is acting different under Slime
> then it is if I run SBCL at the command line! For example the function:
[ Assuming that you actually have the same compiler policy in both
lisp instances. ]
I think I've seem this behaviour before, but forgot to investigate
whether it was by design or by accident. As a workaround you can wrap
the defun in an eval:
* (declaim (optimize (speed 3) (safety 0)))
* (eval '(defun binary-add (x y)
(declare (fixnum x y))
(the fixnum (+ x y))))
BINARY-ADD
* (disassemble 'binary-add)
; 00028F48: 4801FA ADD RDX, RDI ; no-arg-parsing entry point
; 4B: 488B4DF0 MOV RCX, [RBP-16]
; 4F: 488B45F8 MOV RAX, [RBP-8]
; 53: 4883C103 ADD RCX, 3
; 57: 488BE5 MOV RSP, RBP
; 5A: 488BE8 MOV RBP, RAX
; 5D: 48 BYTE #X48
; 5E: FFE1 JMP ECX
;
NIL
* (defun binary-add (x y)
(declare (fixnum x y))
(the fixnum (+ x y)))
STYLE-WARNING: redefining BINARY-ADD in DEFUN
BINARY-ADD
* (disassemble 'binary-add)
;
; 000B8164: 40 BYTE #X40 ; no-arg-parsing entry point
; 165: C604251803004000 MOV BYTE PTR [#x40000318], 0
; 16D: 40 BYTE #X40
; 16E: C60425E802004008 MOV BYTE PTR [#x400002E8], 8
[... about 170 lines removed ...]
; 3C5: L7: CC0A BREAK 10 ; error trap
; 3C7: 02 BYTE #X02
; 3C8: 1A BYTE #X1A ; UNBOUND-SYMBOL-ERROR
; 3C9: 0F BYTE #X0F ; RAX
--
Juho Snellman
"Premature profiling is the root of all evil."
From: M Jared Finder
Subject: Re: What's up with DISASSEMBLE and Slime?
Date:
Message-ID: <421c0fdf$1@x-privat.org>
Juho Snellman wrote:
> <·····@hpalace.com> wrote:
>
>>I've been experimenting with SBCL, seeing how good the optimizer is, but
>>I've hit a pretty big snag. DISASSEMBLE is acting different under Slime
>>then it is if I run SBCL at the command line! For example the function:
>
> [ Assuming that you actually have the same compiler policy in both
> lisp instances. ]
>
> I think I've seem this behaviour before, but forgot to investigate
> whether it was by design or by accident. As a workaround you can wrap
> the defun in an eval:
>
> * (declaim (optimize (speed 3) (safety 0)))
> * (eval '(defun binary-add (x y)
> (declare (fixnum x y))
> (the fixnum (+ x y))))
Yup that's the difference. I noticed that putting the code in a file
and using LOAD also causes it to be optimized. But that makes no sense;
why is top level code left unoptimized? I assume that its something
about the way DECLAIM and PROCLAIM work, but I thought they affect all
code evaluated after the declamation/proclamation.
-- MJF
From: Rahul Jain
Subject: Re: What's up with DISASSEMBLE and Slime?
Date:
Message-ID: <87hdjxnptw.fsf@nyct.net>
M Jared Finder <·····@hpalace.com> writes:
> Yup that's the difference. I noticed that putting the code in a file
> and using LOAD also causes it to be optimized. But that makes no sense;
> why is top level code left unoptimized? I assume that its something
> about the way DECLAIM and PROCLAIM work, but I thought they affect all
> code evaluated after the declamation/proclamation.
No, they affect all code COMPILEd after the declamation/proclamation.
SBCL's interactive "compile" isn't a COMPILE. It tries to get the job
done quickly. If you want properly optimized compilation, COMPILE the
function.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: M Jared Finder
Subject: Re: What's up with DISASSEMBLE and Slime?
Date:
Message-ID: <42233877_3@x-privat.org>
Rahul Jain wrote:
> M Jared Finder <·····@hpalace.com> writes:
>
>>Yup that's the difference. I noticed that putting the code in a file
>>and using LOAD also causes it to be optimized. But that makes no sense;
>>why is top level code left unoptimized? I assume that its something
>>about the way DECLAIM and PROCLAIM work, but I thought they affect all
>>code evaluated after the declamation/proclamation.
>
> No, they affect all code COMPILEd after the declamation/proclamation.
> SBCL's interactive "compile" isn't a COMPILE. It tries to get the job
> done quickly. If you want properly optimized compilation, COMPILE the
> function.
Ah, that makes sense. It's an unfortunate side effect of SBCL's way of
compiling everything with out doing a true compile, that you can't just
write:
* (compile 'binary-add)
because BINARY-ADD is already compiled, and instead have to write:
* (compile 'binary-add '(lambda (x y)
(declare (fixnum x y))
(the fixnum (+ x y))))
-- MJF