[Gcl-devel] Re: thanks!

[Camm Maguire]

Greetings!  Great to hear.

The new stuff as you see generates more garbage.  Mostly in type
manipulations, I thought in the compiler, but apparently not from your
results.  I had wanted to put in some sort of type hash consing at
least when compiling.  equal hashing is a no brainer, but I know you
and Warren have experience with a more ambitions eq hash cons ensuring
that every type form (in this case) is unique in the system.  Any
advice, suggestions or warnings most appreciated.  I tried this once
on subtypep itself, but sped up compiles at the expense of performance
running Paul's subtypep tests for example.

Basically, we just need to hash type-and and type-or, each taking two
arguments and returning one, that is eq to one of the arguments in the
case that subtypep holds in the obvious direction, and is a
substantive intersection or union otherwise.

Should this be a one off, or should we have some standard memoization
facility in the compiler?

Also need to do the SSE et.al. gbc accelerations, which  as you've
shown can approach a factor of two, unbelievably as it may seem.   The
easiest way to do this is to depend on an external library which does
optimized copying and selects an appropriate shared lib version at
runtime depending on the running CPU, like blas/atlas.   Perhaps newer
libc already does this in memcpy/memmove.  I do know that the newest
ldconfig searches certain directories under /usr/lib preferentially
depending on the capabilities of the running cpu.

P.S. which if any of the following functions to you and the acl2 crowd
use if any?  I.e. any sequence (vector or list) objects as opposed to
pure lists?

P.P.S.  If you post your full gprof output of anything that is
performance critical to you, I'd be happy to take a look.  There is a
lot of information in there in the call frequencies and hierarchy.

P.P.P.S.  On equal -- as you can see the initial type check and
branch-to-eq at the head of the list searches is basically always a
win or insignificant.  The way we have written equal and type_of,
however, still makes (member x y :test 'equal) about 75% slower (on
big lists where almost every equal result is false) than 2.6.6 when x
is a character, for example, and twice as fast when x is a symbol, for
example.  As stated earlier, I think the big cause here is the new
tyoe_of overhead. I hope this is not a problem, though if so there may
be yet further things we can do.  declarations or other type
inferencing, btw, eliminate the type check and branch altogether.

Take care,

=============================================================================

17.3 Sequences Dictionary
=========================

* Menu:

* sequence::
* copy-seq::
* elt::
* fill::
* make-sequence::
* subseq::
* map::
* map-into::
* reduce::
* count::
* length::
* reverse::
* sort::
* find::
* position::
* search::
* mismatch::
* replace::
* substitute::
* concatenate::
* merge::
* remove::
* remove-duplicates::

=============================================================================

Take care,

Robert Boyer <address@hidden> writes:

> Thanks for the equal-is-eq optimizer.  2.7.0 is now better than 2.6.6 by a
> hair on the Nqthm-1992 tests.  (all times on elgin.cs.utexas.edu).
> 
> 2.6.6
> 
> run-gbc time    :   2117.740 secs
> child run time  :    144.790 secs
> gbc time        :    102.050 secs
> 
>                      2364.58
> 
> 2.7.0 with equal-is-eq opt
> 
> run-gbc time    :   2003.040 secs
> child run time  :    156.230 secs
> gbc time        :    217.580 secs
> 
>                      2376.85
> 
> Thanks,
> 
> Bob
> 
> 
> 

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