[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: GCL File "o/hasd.d"
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: GCL File "o/hasd.d" |
Date: |
08 Jul 2005 02:19:04 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! Just checked into t3 -- only a few aethetic mods -- please
feel free to provide feedback if I've messed something up.
Take care,
"Warren A. Hunt Jr." <address@hidden> writes:
> Hi Camm,
>
> Do you feel comfortable enough with Boyer's and my update of GCL
> file "o/hash.d" to include it in the experimental GCL version? It
> certainly speeds up our computations.
>
> Cheers,
>
> Warren
> ++++++
>
> To: "Warren A. Hunt Jr." <address@hidden>
> Cc: address@hidden, address@hidden
> Subject: Re: GCL File "o/hash.d"
> From: Camm Maguire <address@hidden>
> Date: 22 Jun 2005 10:55:02 -0400
>
> Greetings!
>
> "Warren A. Hunt Jr." <address@hidden> writes:
>
> > Hi Camm,
> >
> > Bob and I have merged your changes with our changes. We will do some
> > more testing before we send you (in a day or two) our new "o/hash.d".
> > We had to comment out a couple of lines (see just below) because of
> > unresolved references for our copy of GCL.
> >
>
> Great, and thanks for your work on this!
>
> > /* version is ignored unless logical host */
> > // if ((type_of(x->pn.pn_host) == t_string) &&
> > // (pathname_lookup(x->pn.pn_host,sSApathname_logicalA) != Cnil))
> > // h += ihash_equal(x->pn.pn_version,depth);
> >
> > We choose to end the function "hash_eql" with your hash code from the
> > "t_fixnum" case because we have some tests that exhibited very poor
> > behavior manipulating some very large, somewhat redundant
> > computational biology trees -- these computations involve a lot of
> > hashing on CONS pointers.
> >
>
> I assume you mean that the problems arose from poor distribution in
> the hash table.
>
> > h ^= (h >> 11);
> > h ^= (h << 7) & 0x9D2C5680U;
> > h ^= (h << 15) & 0xEFC60000U;
> > h ^= (h >> 18);
> > return MHSH(h);
> >
> > Ending "hash_eql" with this code works well on average, but in some
> > cases slows down our code 10% to 20% as we make very heavy of hashing.
> > This computation is fairly long. How did you choose it?
> >
>
> I took this from the LGPL'ed Cokus implementation of the mersenne
> twister psuedo-random number generator of several years ago which we
> use here locally. It is probably more than we need. There is a bit
> of an art in construbting these bit pattern manipulations with the
> goal of generating good randomized hashing distributions, an art of
> which I am not too familiar. I also want to mention here that if you
> really can pinpoint a place where you are cpu bound like this, we
> might be able to make use of mmx extensions and do up to four of such
> operations at once if we can find a way to batch them.
>
> Take care,
>
> > Cheers,
> >
> > Warren
> >
> >
> >
>
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gcl-devel] Re: GCL File "o/hasd.d",
Camm Maguire <=