>>>>> "rif" == rif <[EMAIL PROTECTED]> writes:
rif> I understand why
rif> (defun square (x)
rif> (* x x))
rif> is slow, because the arithmetic has to be generic. But why is
rif> (defun square-df-int (x)
rif> (declare (double-float x))
rif> (* x x))
rif> almost as slow as square, whereas
rif> (defun square-df (x)
rif> (declare (double-float x))
rif> (prog ((var 0.0d0))
rif> (setq var (* x x))
rif> var))
rif> is about ten times faster? This is all being compiled with speed 3
Did you try running square-df?
* (square-df 5d0)
NIL
Look up PROG in the CLHS.
rif> and safety 0. The compiler is saying (about square-df-int) that it
rif> has to do float to pointer coercion on the result --- by searching on
rif> this term I found the CMUCL manual on the web, which led me to an
rif> example which led me to make square-df, but I still don't really
rif> understand what's going on. It seems that float to pointer coercion
rif> means converting the result from a non-descriptor representation (the
rif> double-float bits) to a descriptor (a lisp object), but why does it
rif> have to do this and how/why is square-df getting around it?
square-df-int has to do this so that the caller can interpret what
square-df-int returns. square-df just returns NIL. In fact, on my
sparc, it doesn't even do the multiplication. It just loads up a
register with NIL.
rif> Can anyone help me? I'm in the early stages of optimizing a program;
First, you can declare square-df-int to be an inline function. That
will help a lot if you actually use square-df-int a lot.
rif> the lisp version was much easier to write and debug than the C
rif> version, but it's unforunately about 50 times slower right now.
Step 1: profile the code.
Step 2: Look at the hotspots and see what the compiler notes say about
those functions.
Step 3: Add declarations, inline things, change algorithms, etc.
Anyway, that's how I optimize my Lisp programs.
Ray
