[Gcl-devel] Re: Hash-CONS Stuff

[Camm Maguire]

Greetings!

Matt Kaufmann <address@hidden> writes:

> Thanks, Bob.  The email below is basically a verbose "idunno either".
> 
> I agree -- it's hard to know where the 8% slowdown comes from (though we could
> probably find out quite a lot if we spend some time).  Here is a snippet from
> an email I sent to Warren and J in June of last year, when I first implemented
> mv as values.
> 
>   I still need to deal with proclaiming and trace.  But the regressions 
> passed,
>   with a 10% speed-up for Allegro CL (quite surprising -- perhaps because they
>   optimize for multiple-value passing) and a 17% slowdown for GCL (not at all
>   surprising -- we formerly proclaimed for GCL, but I turned that off -- but 
> not
>   bad performance, really, for starters).
> 
> I believe we now proclaim for GCL, so one wouldn't expect 17% any more.  
> Still,

Do you proclaim stuff like

(proclaim '(ftype (function (t) *) foo))

?  If so, this will default to the old slow lisp value-stack function
calling procedure.  Easy to tell, the C looks like:

        base[1]= (V1);
        vs_top=(vs_base=base+1)+1;
        (void) (*Lnk0)();
        return;

instead of

        base[1]= ((*LnkLI0)((V1)));

Is there some reason not to use Schelter's mechanism?  If there is,
there are some ways to improve mv passing, though I don't know what is
best without experimentatino.  I'm assuming the slowness in lisp value
stack passing is simply due to the extra copying from C stack to value
stack.  If this is correct, some solution along these lines is likely
not to help:

typedef enum {
        S1 s1;
        S2 s2;
        S3 s3;
        ...} Mv;

typedef struct {object v1,v2,v3;} S3;

typedef struct {int n;Mv mv;} MMv;

MMv x=(*LnkLI0)(V1);

unless we put in code to avoid

V2=x.s3.v2

and simply use the rhs instead.

It would likely also be of benefit if the number of values can be
proclaimed to instead do

S2 s2=(S2)(*LnkLI0)(V1);

etc.

What might be most helpful would be to rerun with the older mv
mechanism to see how important this issue is, if possible.

Take care,

> when mv is not implemented as values, GCL does the mv thing even more
> efficiently (as I understand it) than is done for other lisps, so I guess it
> wouldn't be surprising to see some slowdown when we lose that in favor of
> values.
> 
> I also observed, at some point in the past, some slowdown when using larger
> images.  But Camm has made such significant improvements in GC that this
> observation could easily be obsolete.
> 
> -- Matt
>    Date: Tue, 18 Apr 2006 07:52:57 -0500
>    From: Robert Boyer <address@hidden>
>    Cc: address@hidden
> 
>    Matt,
> 
>    Thanks so very much those two times:
> 
>      Time using /projects/acl2/v2-9-4-linux/gcl-saved_acl2
>      (from last line of /projects/acl2/v2-9-4-linux/make-regression-gcl.log):
>      11791.744u 201.456s 3:22:34.21 98.6%     0+0k 0+0io 0pf+0w
> 
>      Time using /projects/hvg/ACL2/v2-9-4-hons/saved_acl2
>      (from last line of /projects/hvg/ACL2/v2-9-4-hons/make-regression.log, 
> which
>      includes the "clean" time off several seconds):
>      12755.821u 242.611s 3:41:41.94 97.7%     0+0k 0+0io 15pf+0w
> 
>    > which is great considering
> 
>    Excellent news indeed.
> 
>    Still, 8% down is 8% down.  Where'd it go?
> 
>    Apples -> Oranges ?
>    CLTL1 -> ANSI ?
>    si::set-mv -> values  ?
>    130,000 page binary image -> 500,000 page binary image ?
>    dynamic -> static ?
>    gcc -O3 -> gcc -Os  ?
>    DVOL=volatile -> "" ?
>    gcc 3.3.3 -> gcc 3.3.4 ?
>    Phase of the Moon?
>    Last date of oil change?
>    Tire wear?
>    Octane?
> 
>    (In the MIT AI lab circa 1970, when one printed a file on
>    the line printer, along with the other stuff, like the file
>    name, was printed the phase of the moon (POM) because
>    someone, it was said, believed POM was always influencing
>    computer programs.)
> 
>    As usual, idunno.
> 
>    Camm, I'm not sure if you have the "values" point here
>    exactly to which Matt is referring.  Back in about 1992 or
>    so, Bill Schelter enhanced AKCL (or whatever it was called
>    then) with a special feature, system::set-mv, that was used
>    to advantage by ACL2 to improve performance over the usual
>    AKCL Common Lisp multiple value return mechanism.  In the
>    2.7.0, slower, run above si::set-mv is no longer used, but
>    the ordinary 'values' is used.  It's speculation on my part,
>    but ACL2 is probably one of your more *extraordinarily*
>    intensive multiple value returning Common Lisp programs.
> 
>    Bob
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah