Re: [Gcl-devel] Performance complaint from a user

[Camm Maguire]

Greetings!  One more thought here -- following the fixnum hashing link
on this site, it appears that fixnum hash code distribution may be an
issue.  Here is what we have at present for eql hashing:

  case t_fixnum:
/*     h=fix(x); */
/*     h ^= (h >> 11); */
/*     h ^= (h <<  7) & 0x9D2C5680U; */
/*     h ^= (h << 15) & 0xEFC60000U; */
/*     h ^= (h >> 18); */
    h=fix(x)<<3;
    break;


I had put in the commented code based on some prior experience with
Mersenne twister algorithms locally.  The folks at the University of
Texas, who make extensive use of hash consing in their acl2 based
applications, determined in their testing that the gains were not
worth the overhead.  If there is interest in a discussion of this
issue, I could ask if they would like to share their thoughts.

Take care,

"Paul F. Dietz" <address@hidden> writes:

> Juho Snellman benchmarked some code he wrote for a Google
> programming project, and found gcl wasn't very good at
> all:
> 
> http://www.cs.helsinki.fi/u/jesnellm/blog/archive/2005-08-27b.html
> 
> He told me the biggest problem was gcl wasn't able to compile
> defuns in non-null lexical environments:
> 
> ;; compile-file didn't do well on this
> 
> (let ((x ni))
>    (defun foo () ...)
>    (defun bar () ...)
>    ...)
> 
> Even after he fixed that (with special variables) it was still
> rather more slow than sbcl or cmucl.  I'd like to see where
> the performance bottleneck is for further tuning.
> 
>       Paul
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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