Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > > And, if possible, on various OS and various lisps.
> >
> > I just finished the standard tests using sbcl, gcl and Closure CL
> > (former openmcl) on 2.2 GHz Intel Core 2 Duo running 64-bit Debian. I see
> > no regressions.
>
> Wonderful. Remains MS Windows and MaxOSX, I believe?
>
Well, on Linux we should also test clisp, ecl and Ansi gcl (I tested
only traditional gcl). I do not expect problems from them -- sbcl
is typically the most picky one and tranditional gcl the most
weird, so if the two work the other rarely show problems. For
normal patches I just test using one implementation (typically
sbcl), but from time to time I test using all of them.
> > Timing for test suite are:
> ...
>
> > I think conclusion from measurements is clear: the SPADCALL patch gives
> > significant speedup for sbcl (of order 15-25%) while impact on gcl and
> > Closure CL is much smaller (probably within measurement noise).
>
> Shouldn't the timings (safety 0) be quite different from the default -- I
> believe it's (safety 1), isn't it?
>
Default safety for GCL is 0, but we bump this to 1. For ECL default
is 2. I am not sure what is the default for sbcl, clisp and Closure CL,
but it for sbcl and Closure CL is is certainly bigger than 0.
> What the SPADCALL patch does, is, as you know,
>
> 1 check whether the argument is a function, call it if this is the case,
> 2 otherwise fail.
>
> instead of
>
> 1 check whether the argument is a function, call it if this is the case,
> 1a otherwise check whether symbol-function is set, call it if so,
> 2 otherwise fail.
>
> This *should* give some speedup, but I think the expensive check for the
> algebra (not the interpreter!) is 1.
>
You forgot one effect:
3) tell Lisp that we have ordinary call -- no keyword or other
special argument processing and no multiple values
For sbcl about half of the effect comes from 3. The other half
seem to be due to the fact that in sbcl getting function corresponding
to a function involves some computation done by a separate function.
Checking if an argument is a function should be relatively cheap
(basically one need to read a tag from memory and check if a subfield
(a few bits) of the tag have specific value. Similarly, getting
function associated to a symbol should be cheap, just one extra
read from memory -- but sbcl is doing something weird here.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
