For part (b) of this exercise in Graham's "ANSI Common Lisp", when I
add declarations to the ray-tracer program, it actually runs slower.
Can anyone explain to me why that is?
My code with declarations is available here:
http://www.automatous-monk.com/lisp/aclp/chap13-exer03.html
I'm not sure, but I believe I was using SLIME when I did this exercise
(it was a while ago).
From: Pascal J. Bourguignon
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87r5yfwut6.fsf@galatea.local>
Paul Reiners <············@gmail.com> writes:
> For part (b) of this exercise in Graham's "ANSI Common Lisp", when I
> add declarations to the ray-tracer program, it actually runs slower.
> Can anyone explain to me why that is?
Because you're not as smart as the compiler at infering the right
types. That's Ok, humans are not good at that. That's why we created
compilers in the first place instead of keeping writting assembler. ;-)
> My code with declarations is available here:
> http://www.automatous-monk.com/lisp/aclp/chap13-exer03.html
I'm no optimization specialist, but one thing I note is that you
don't declare the types of the functions. So the compiler will return
boxed values and expect boxed values. The typing you do outside of
the functions means that it will have to unbox the function results.
Try to add:
(declare (ftype (function (fixnum fixnum fixnum) fixnum) date->num)
(ftype (function (fixnum fixnum) fixnum) month-num)
...)
Also, I would be more specific, use (integer 1 31) rather than fixnum
when the values go from 1 to 31. It may let the compiler even better
optimize.
--
__Pascal Bourguignon__
On 23 maio, 15:14, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Paul Reiners <············@gmail.com> writes:
> > For part (b) of this exercise in Graham's "ANSI Common Lisp", when I
> > add declarations to the ray-tracer program, it actually runs slower.
> > Can anyone explain to me why that is?
>
> Because you're not as smart as the compiler at infering the right
> types. That's Ok, humans are not good at that. That's why we created
> compilers in the first place instead of keeping writting assembler. ;-)
>
> > My code with declarations is available here:
> >http://www.automatous-monk.com/lisp/aclp/chap13-exer03.html
>
> I'm no optimization specialist, but one thing I note is that you
> don't declare the types of the functions. So the compiler will return
> boxed values and expect boxed values. The typing you do outside of
> the functions means that it will have to unbox the function results.
>
> Try to add:
>
> (declare (ftype (function (fixnum fixnum fixnum) fixnum) date->num)
> (ftype (function (fixnum fixnum) fixnum) month-num)
> ...)
DECLARE does not work in the toplevel; you need DECLAIM.
>
> Also, I would be more specific, use (integer 1 31) rather than fixnum
> when the values go from 1 to 31. It may let the compiler even better
> optimize.
>
> --
> __Pascal Bourguignon__
From: Pascal J. Bourguignon
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87iqjrwtgz.fsf@galatea.local>
gugamilare <··········@gmail.com> writes:
> On 23 maio, 15:14, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> (declare (ftype (function (fixnum fixnum fixnum) fixnum) date->num)
>> � � � � �(ftype (function (fixnum fixnum) fixnum) � � � �month-num)
>> � � � � �...)
>
> DECLARE does not work in the toplevel; you need DECLAIM.
Right, I always confuse them. DECLAIM.
--
__Pascal Bourguignon__
On May 23, 9:43 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> gugamilare <··········@gmail.com> writes:
> > On 23 maio, 15:14, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> (declare (ftype (function (fixnum fixnum fixnum) fixnum) date->num)
> >> (ftype (function (fixnum fixnum) fixnum) month-num)
> >> ...)
>
> > DECLARE does not work in the toplevel; you need DECLAIM.
>
> Right, I always confuse them. DECLAIM.
Is there any way to put these declarations in the functions? i.e.,
(defun foo (bar baz)
(declare (ftype (function (fixnum vector) function) foo))
. body)
(in this context, foo is a hypothetical function takes a fixnum and a
vector, returning a closure)
Also, would this declaration (whether within the function, or at the
toplevel with DECLAIM) suffice to tell the compiler the types of the
function arguments as well?
Thanks,
Adlai
On 2009-05-23 14:57:59 -0400, Adlai <·········@gmail.com> said:
> Is there any way to put these declarations in the functions? i.e.,
> (defun foo (bar baz)
> (declare (ftype (function (fixnum vector) function) foo))
> . body)
>
> (in this context, foo is a hypothetical function takes a fixnum and a
> vector, returning a closure)
* (defun foo (bar baz)
(declare (fixnum bar)
(vector baz)
(ftype (function (fixnum vector) (function
(fixnum) vector)) foo)
(optimize speed (safety 0) (debug 0)))
(lambda (x)
(declare (fixnum x)
(optimize speed (safety 0) (debug 0)))
(make-array bar :element-type t
:initial-contents
(loop for elt across baz collecting (* x elt)))))
FOO
* (funcall (foo 3 #(2 4 6)) 3)
#(6 12 18)
*
>
> Also, would this declaration (whether within the function, or at the
> toplevel with DECLAIM) suffice to tell the compiler the types of the
> function arguments as well?
The ftype declaration tells the compiler that foo is a function that
takes a fixnum and a vector as args, and returns an anonymous function,
which itself takes a fixnum as an arg, and returns a vector. Is that
what you mean?
--
Raffael Cavallaro, Ph.D.
From: Pascal J. Bourguignon
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87ab53wl04.fsf@galatea.local>
Raffael Cavallaro <················@pas.espam.s.il.vous.plait.mac.com> writes:
> On 2009-05-23 14:57:59 -0400, Adlai <·········@gmail.com> said:
>
>> Is there any way to put these declarations in the functions? i.e.,
>> (defun foo (bar baz)
>> (declare (ftype (function (fixnum vector) function) foo))
>> . body)
>> (in this context, foo is a hypothetical function takes a fixnum and
>> a
>> vector, returning a closure)
>
> * (defun foo (bar baz)
> (declare (fixnum bar)
> (vector baz)
> (ftype (function (fixnum vector) (function
> (fixnum) vector)) foo)
> (optimize speed (safety 0) (debug 0)))
> (lambda (x)
> (declare (fixnum x)
> (optimize speed (safety 0) (debug 0)))
> (make-array bar :element-type t
> :initial-contents
> (loop for elt across baz collecting (* x elt)))))
>
> FOO
> * (funcall (foo 3 #(2 4 6)) 3)
>
> #(6 12 18)
> *
>
>> Also, would this declaration (whether within the function, or at the
>> toplevel with DECLAIM) suffice to tell the compiler the types of the
>> function arguments as well?
>
> The ftype declaration tells the compiler that foo is a function that
> takes a fixnum and a vector as args, and returns an anonymous
> function, which itself takes a fixnum as an arg, and returns a
> vector. Is that what you mean?
Of course it works, but putting the ftype declaration inside the
function is not the same as outside. Declarations are scoped. When
you leave it inside f, another function g cannot know that g only
returns fixnums, therefore it must use a generic +:
S/CL-USER[36]> (defun f (x) (declare (ftype (function (fixnum) fixnum) f) (type fixnum x)) x)
STYLE-WARNING: redefining F in DEFUN
F
S/CL-USER[37]> (defun g (x) (declare (type fixnum x)) (the fixnum (+ x (f x))))
G
S/CL-USER[38]> (disassemble 'g)
; disassembly for G
; 1199D43C: 8975F4 MOV [EBP-12], ESI ; no-arg-parsing entry point
; 3F: 8BDC MOV EBX, ESP
; 41: 83EC0C SUB ESP, 12
; 44: 8BD6 MOV EDX, ESI
; 46: 8B0510D49911 MOV EAX, [#x1199D410] ; #<FDEFINITION object for F>
; 4C: B904000000 MOV ECX, 4
; 51: 896BFC MOV [EBX-4], EBP
; 54: 8BEB MOV EBP, EBX
; 56: FF5005 CALL DWORD PTR [EAX+5]
; 59: 7302 JNB L0
; 5B: 8BE3 MOV ESP, EBX
; 5D: L0: 8B75F4 MOV ESI, [EBP-12]
; 60: 8BFA MOV EDI, EDX
; 62: 8BD6 MOV EDX, ESI
; 64: E8CF2C66F2 CALL #x4000138 ; GENERIC-+
; 69: 7302 JNB L1
; 6B: 8BE3 MOV ESP, EBX
; 6D: L1: 8D65F8 LEA ESP, [EBP-8]
; 70: F8 CLC
; 71: 8B6DFC MOV EBP, [EBP-4]
; 74: C20400 RET 4
NIL
S/CL-USER[39]> (declaim (ftype (function (fixnum) fixnum) f))
S/CL-USER[40]> (defun f (x) (declare (type fixnum x)) x)
STYLE-WARNING: redefining F in DEFUN
F
S/CL-USER[41]> (defun g (x) (declare (type fixnum x)) (the fixnum (+ x (f x))))
STYLE-WARNING: redefining G in DEFUN
G
S/CL-USER[42]> (disassemble 'g)
; disassembly for G
; 119E10DC: 8975F4 MOV [EBP-12], ESI ; no-arg-parsing entry point
; 0DF: 8BDC MOV EBX, ESP
; 0E1: 83EC0C SUB ESP, 12
; 0E4: 8BD6 MOV EDX, ESI
; 0E6: 8B05B0109E11 MOV EAX, [#x119E10B0] ; #<FDEFINITION object for F>
; 0EC: B904000000 MOV ECX, 4
; 0F1: 896BFC MOV [EBX-4], EBP
; 0F4: 8BEB MOV EBP, EBX
; 0F6: FF5005 CALL DWORD PTR [EAX+5]
; 0F9: 7302 JNB L0
; 0FB: 8BE3 MOV ESP, EBX
; 0FD: L0: 8B75F4 MOV ESI, [EBP-12]
; 100: 8D0416 LEA EAX, [ESI+EDX]
; 103: 8BD0 MOV EDX, EAX
; 105: 8D65F8 LEA ESP, [EBP-8]
; 108: F8 CLC
; 109: 8B6DFC MOV EBP, [EBP-4]
; 10C: C20400 RET 4
NIL
--
__Pascal Bourguignon__
On May 24, 12:46 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Raffael Cavallaro <················@pas.espam.s.il.vous.plait.mac.com> writes:
> > On 2009-05-23 14:57:59 -0400, Adlai <·········@gmail.com> said:
[snip technical stuff]
> >> Also, would this declaration (whether within the function, or at the
> >> toplevel with DECLAIM) suffice to tell the compiler the types of the
> >> function arguments as well?
>
> > The ftype declaration tells the compiler that foo is a function that
> > takes a fixnum and a vector as args, and returns an anonymous
> > function, which itself takes a fixnum as an arg, and returns a
> > vector. Is that what you mean?
@Raffael: Yes. Pascal's point below still stands, but your example was
very clear -- thank you!
> Of course it works, but putting the ftype declaration inside the
> function is not the same as outside. Declarations are scoped. When
> you leave it inside f, another function g cannot know that g only
> returns fixnums, therefore it must use a generic +:
I see what you mean. I overlooked that. By the way, it seems from your
example that you made a typo in the above paragraph. Do you mean,
instead of the second G, an F? That's what it seems from the code
below.
> S/CL-USER[36]> (defun f (x) (declare (ftype (function (fixnum) fixnum) f) (type fixnum x)) x)
> STYLE-WARNING: redefining F in DEFUN
>
> F
>
> S/CL-USER[37]> (defun g (x) (declare (type fixnum x)) (the fixnum (+ x (f x))))
>
> G
>
> S/CL-USER[38]> (disassemble 'g)
>
> ; disassembly for G
> ; 1199D43C: 8975F4 MOV [EBP-12], ESI ; no-arg-parsing entry point
> ; 3F: 8BDC MOV EBX, ESP
> ; 41: 83EC0C SUB ESP, 12
> ; 44: 8BD6 MOV EDX, ESI
> ; 46: 8B0510D49911 MOV EAX, [#x1199D410] ; #<FDEFINITION object for F>
> ; 4C: B904000000 MOV ECX, 4
> ; 51: 896BFC MOV [EBX-4], EBP
> ; 54: 8BEB MOV EBP, EBX
> ; 56: FF5005 CALL DWORD PTR [EAX+5]
> ; 59: 7302 JNB L0
> ; 5B: 8BE3 MOV ESP, EBX
> ; 5D: L0: 8B75F4 MOV ESI, [EBP-12]
> ; 60: 8BFA MOV EDI, EDX
> ; 62: 8BD6 MOV EDX, ESI
> ; 64: E8CF2C66F2 CALL #x4000138 ; GENERIC-+
> ; 69: 7302 JNB L1
> ; 6B: 8BE3 MOV ESP, EBX
> ; 6D: L1: 8D65F8 LEA ESP, [EBP-8]
> ; 70: F8 CLC
> ; 71: 8B6DFC MOV EBP, [EBP-4]
> ; 74: C20400 RET 4
> NIL
>
> S/CL-USER[39]> (declaim (ftype (function (fixnum) fixnum) f))
>
> S/CL-USER[40]> (defun f (x) (declare (type fixnum x)) x)
> STYLE-WARNING: redefining F in DEFUN
>
> F
>
> S/CL-USER[41]> (defun g (x) (declare (type fixnum x)) (the fixnum (+ x (f x))))
> STYLE-WARNING: redefining G in DEFUN
>
> G
>
> S/CL-USER[42]> (disassemble 'g)
>
> ; disassembly for G
> ; 119E10DC: 8975F4 MOV [EBP-12], ESI ; no-arg-parsing entry point
> ; 0DF: 8BDC MOV EBX, ESP
> ; 0E1: 83EC0C SUB ESP, 12
> ; 0E4: 8BD6 MOV EDX, ESI
> ; 0E6: 8B05B0109E11 MOV EAX, [#x119E10B0] ; #<FDEFINITION object for F>
> ; 0EC: B904000000 MOV ECX, 4
> ; 0F1: 896BFC MOV [EBX-4], EBP
> ; 0F4: 8BEB MOV EBP, EBX
> ; 0F6: FF5005 CALL DWORD PTR [EAX+5]
> ; 0F9: 7302 JNB L0
> ; 0FB: 8BE3 MOV ESP, EBX
> ; 0FD: L0: 8B75F4 MOV ESI, [EBP-12]
> ; 100: 8D0416 LEA EAX, [ESI+EDX]
> ; 103: 8BD0 MOV EDX, EAX
> ; 105: 8D65F8 LEA ESP, [EBP-8]
> ; 108: F8 CLC
> ; 109: 8B6DFC MOV EBP, [EBP-4]
> ; 10C: C20400 RET 4
> NIL
Thank you both for your prompt and informative feedback.
- Adlai
From: Pascal J. Bourguignon
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <871vqfwhui.fsf@galatea.local>
Adlai <·········@gmail.com> writes:
> On May 24, 12:46�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Raffael Cavallaro <················@pas.espam.s.il.vous.plait.mac.com> writes:
>> > On 2009-05-23 14:57:59 -0400, Adlai <·········@gmail.com> said:
> [snip technical stuff]
>> >> Also, would this declaration (whether within the function, or at the
>> >> toplevel with DECLAIM) suffice to tell the compiler the types of the
>> >> function arguments as well?
>>
>> > The ftype declaration tells the compiler that foo is a function that
>> > takes a fixnum and a vector as args, and returns an anonymous
>> > function, which itself takes a fixnum as an arg, and returns a
>> > vector. Is that what you mean?
>
> @Raffael: Yes. Pascal's point below still stands, but your example was
> very clear -- thank you!
>
>> Of course it works, but putting the ftype declaration inside the
>> function is not the same as outside. �Declarations are scoped. �When
>> you leave it inside f, another function g cannot know that g only
>> returns fixnums, therefore it must use a generic +:
>
> I see what you mean. I overlooked that. By the way, it seems from your
> example that you made a typo in the above paragraph. Do you mean,
> instead of the second G, an F? That's what it seems from the code
> below.
Yes sorry. So it would have been better to stay with foo and bar...
--
__Pascal Bourguignon__
Adlai <·········@gmail.com> writes:
> Is there any way to put these declarations in the functions? i.e.,
> (defun foo (bar baz)
> (declare (ftype (function (fixnum vector) function) foo))
> . body)
>
> (in this context, foo is a hypothetical function takes a fixnum and a
> vector, returning a closure)
Well, you could do this, but you would be limiting the scope of the
declaration to the function body, so any external reference to foo would
not be in the scope of that declaration.
This would be useful for recursive functions that are not referenced
globally.
To get a global declaration you need to use DECLAIM or PROCLAIM instead.
> Also, would this declaration (whether within the function, or at the
> toplevel with DECLAIM) suffice to tell the compiler the types of the
> function arguments as well?
I'm not sure what the treatment of that would be. I think that it might
depend on the specific compiler, so to be sure, you would have to
somewhat redundantly specify the argument types as well.
The only thing I could find with some small amount of searching in the
Hyperspec was the following line:
"Thus, an ftype declaration for a function describes calls to the
function, not the actual definition of the function."
http://www.lispworks.com/documentation/HyperSpec/Body/t_fn.htm
--
Thomas A. Russ, USC/Information Sciences Institute
> Also, would this declaration (whether within the function, or at the
> toplevel with DECLAIM) suffice to tell the compiler the types of the
> function arguments as well?
I am also unsure about this:
(declaim (ftype (function (float) float) foo))
(defun foo (x)
(declare (type float x)) ; is this still needed?
;; etc.
It seems that after declaiming the ftype, the declaration of the type of
the arguments inside the function becomes redundant.
I say "it seems" because I haven't found anything in the hyperspec that
says this explicitly. However, the CMUCL manual does (section 5.2.6):
> Declaring a function's type with ftype implicitly declares the types
of the arguments in the definition. Python checks for consistency
between the definition and the ftype declaration.
and SBCL does this too. So maybe it's implementation-dependant.
g
So, I tried declaring the function types, like this:
=============================================================================================================
; Use declarations in math utilities:
(declaim (ftype (function (long-float) long-float) sq)
(ftype (function (long-float long-float long-float) long-float) mag)
(ftype (function (long-float long-float long-float) (long-float long-
float long-float) unit-vector))
(ftype (function (long-float long-float long-float) long-float
minroot)))
(defun sq (x)
(* x x))
(defun mag (x y z)
(sqrt (+ (sq x) (sq y) (sq z))))
(defun unit-vector (x y z)
(let ((d (mag x y z)))
(declare (long-float d))
(values (/ x d) (/ y d) (/ z d))))
(defun minroot (a b c)
(if (zerop a)
(/ (- c) b)
(let ((disc (- (sq b) (* 4 a c))))
(declare (long-float disc))
(unless (minusp disc)
(let ((discrt (sqrt disc)))
(declare (long-float discrt))
(min (/ (+ (- b) discrt) (* 2 a))
(/ (- (- b) discrt) (* 2 a))))))))
=============================================================================================================
However it still ran slower than the version with no declarations.
What am I doing wrong here?
Paul Reiners <············@gmail.com> writes:
> So, I tried declaring the function types, like this:
>
> =============================================================================================================
> ; Use declarations in math utilities:
> (declaim (ftype (function (long-float) long-float) sq)
> (ftype (function (long-float long-float long-float) long-float) mag)
> (ftype (function (long-float long-float long-float) (long-float long-
> float long-float) unit-vector))
> (ftype (function (long-float long-float long-float) long-float
> minroot)))
>
> (defun sq (x)
(declare (long-float x))
> (* x x))
>
> (defun mag (x y z)
(declare (long-float x y z))
> (sqrt (+ (sq x) (sq y) (sq z))))
...
> =============================================================================================================
>
> However it still ran slower than the version with no declarations.
> What am I doing wrong here?
I suspect that you need to specify the argument types inside each
function as well.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Tobias C. Rittweiler
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87vdnnpqda.fsf@freebits.de>
Paul Reiners <············@gmail.com> writes:
> However it still ran slower than the version with no declarations.
> What am I doing wrong here?
On what implementation? SBCL, and CMUCL, treat declarations as
assertions in non-unsafe code. So more declarations can easily mean more
type checks at run-time. Getting good performance from Lisp code does
not necessarily equate to inserting declarations randomly.
-T.
On 26 maio, 17:21, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> Paul Reiners <············@gmail.com> writes:
> > However it still ran slower than the version with no declarations.
> > What am I doing wrong here?
>
> On what implementation? SBCL, and CMUCL, treat declarations as
> assertions in non-unsafe code. So more declarations can easily mean more
> type checks at run-time. Getting good performance from Lisp code does
> not necessarily equate to inserting declarations randomly.
>
> -T.
Well, I assumed that Paul Reiners had added the speed and perhaps no
safety declarations:
(declaim (optimize speed (safety 0)))
This way, both SBCL and CMUCL (not sure about CMUCL) will suppress
type-checks and make unboxing of types.
From: Tobias C. Rittweiler
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87r5ybpnjg.fsf@freebits.de>
gugamilare <··········@gmail.com> writes:
> Well, I assumed that Paul Reiners had added the speed and perhaps no
> safety declarations:
>
> (declaim (optimize speed (safety 0)))
You probably did not mean it, but to make it clear for the less
experienced reader: Do not enable these dangerous optimization settings
globally. I.e. use DECLARE inside the relevant function's definition,
not DECLAIM at the toplevel of a file.
For more information about declarations-as-assertions, see
http://www.sbcl.org/manual/Declarations-as-Assertions.html
-T.
On 26 maio, 18:22, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> gugamilare <··········@gmail.com> writes:
> > Well, I assumed that Paul Reiners had added the speed and perhaps no
> > safety declarations:
>
> > (declaim (optimize speed (safety 0)))
>
> You probably did not mean it, but to make it clear for the less
> experienced reader: Do not enable these dangerous optimization settings
> globally. I.e. use DECLARE inside the relevant function's definition,
> not DECLAIM at the toplevel of a file.
>
> For more information about declarations-as-assertions, see
>
> http://www.sbcl.org/manual/Declarations-as-Assertions.html
>
> -T.
It is ok to put this form inside a file as well. The declarations will
be valid only for that file. Or am I wrong?
From: Tobias C. Rittweiler
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87my8zpmcu.fsf@freebits.de>
gugamilare <··········@gmail.com> writes:
> On 26 maio, 18:22, "Tobias C. Rittweiler" <····@freebits.de.invalid>
> wrote:
>> gugamilare <··········@gmail.com> writes:
>> > Well, I assumed that Paul Reiners had added the speed and perhaps no
>> > safety declarations:
>>
>> > (declaim (optimize speed (safety 0)))
>>
>> You probably did not mean it, but to make it clear for the less
>> experienced reader: Do not enable these dangerous optimization settings
>> globally. I.e. use DECLARE inside the relevant function's definition,
>> not DECLAIM at the toplevel of a file.
>>
>> For more information about declarations-as-assertions, see
>>
>> �http://www.sbcl.org/manual/Declarations-as-Assertions.html
>>
>> � -T.
>
> It is ok to put this form inside a file as well. The declarations will
> be valid only for that file. Or am I wrong?
Not necessarily. And even if, a per file scope is in most cases still
way too broad.
-T.
On 26 maio, 18:48, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> gugamilare <··········@gmail.com> writes:
> > On 26 maio, 18:22, "Tobias C. Rittweiler" <····@freebits.de.invalid>
> > wrote:
> >> gugamilare <··········@gmail.com> writes:
> >> > Well, I assumed that Paul Reiners had added the speed and perhaps no
> >> > safety declarations:
>
> >> > (declaim (optimize speed (safety 0)))
>
> >> You probably did not mean it, but to make it clear for the less
> >> experienced reader: Do not enable these dangerous optimization settings
> >> globally. I.e. use DECLARE inside the relevant function's definition,
> >> not DECLAIM at the toplevel of a file.
>
> >> For more information about declarations-as-assertions, see
>
> >> http://www.sbcl.org/manual/Declarations-as-Assertions.html
>
> >> -T.
>
> > It is ok to put this form inside a file as well. The declarations will
> > be valid only for that file. Or am I wrong?
>
> Not necessarily.
I know that SBCL's declarations are local to a file.
> And even if, a per file scope is in most cases still
> way too broad.
Well, I disagree. I think that putting bottle-necks into separate
files is a nice approach to optimize a program. It is convenient to
tell the compiler (and whoever opens the file) that that file is a
bottle-neck. For instance, if you create a data structure that is to
be used many times and needs to be optimized, it is good to keep all
functions that manipulate that data structure into a separated file.
Gustavo.
From: Tobias C. Rittweiler
Subject: Re: Q about ACL: Chapter 13: Exercise 3
Date:
Message-ID: <87iqjnpldv.fsf@freebits.de>
gugamilare <··········@gmail.com> writes:
> Well, I disagree. I think that putting bottle-necks into separate
> files is a nice approach to optimize a program. It is convenient to
> tell the compiler (and whoever opens the file) that that file is a
> bottle-neck. For instance, if you create a data structure that is to
> be used many times and needs to be optimized, it is good to keep all
> functions that manipulate that data structure into a separated file.
It's unlikely that really all functions that manipulate that data
structure need to be compiled totally unsafely.
-T.
On May 23, 8:02 pm, Paul Reiners <············@gmail.com> wrote:
> For part (b) of this exercise in Graham's "ANSI Common Lisp", when I
> add declarations to the ray-tracer program, it actually runs slower.
> Can anyone explain to me why that is?
>
> My code with declarations is available here:http://www.automatous-monk.com/lisp/aclp/chap13-exer03.html
>
> I'm not sure, but I believe I was using SLIME when I did this exercise
> (it was a while ago).
I assume you're using either SBCL or CMUCL? I've never heard of type
declarations slowing things down in other implementations. The short
answer: just littering your code with declarations is the wrong way to
go about things; you probably didn't accomplish much besides forcing
the compiler to insert a lot of runtime type checks.
Read the sections on types in both the CMUCL and SBCL manuals. Then
once you understand what type declarations mean for those
implementations, add declarations using the following procedure:
1. Compile with (safety 1) (speed 3)
2. Read the compiler notes. If there are too many, start with your
inner loops.
3. If the compiler is unable to perform an optimization because id
doesn't know the type of something, but you know that it will have a
type that lets one of the optimizations run: why do you know this?
What is the point the farthest from the inner loop where you can know
this to be true? Add a type declaration to this effect there.
4. Recompile.
5. Goto 2
Also, things to think about: passing floating point values to calls to
non-local functions is expensive. It's better to pass a specialized
array and an index. Returning an index is better than returning a
float. If these aren't practical, make sure the compiler inlines these
functions if they occur in your inner loop.
Declaring function types is no fun; setting *derive-function-types* to
true is usually nicer. Learn how to make sure the type of the return
value is known. Sometimes you need to compile everything twice.