This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Add objc-lang.c, further cleanup - TAKE TWO
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: Stan Shebs <shebs at apple dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 4 Dec 2001 05:36:01 +0000
- Subject: Re: PATCH: Add objc-lang.c, further cleanup - TAKE TWO
- References: <3C0C130F.22B76EA3@apple.com> <1DA8B993-E84E-11D5-92F8-0030658361CA@apple.com>
Ziemowit Laski wrote:-
> Gotta admit I did not measure the speed hit. However, we absolutely
> need address-independent hash functions throughout the compiler for
> the upcoming persistent front-end to run properly.
> Also, I suspect (although, again, I did not measure it), that the
> bucket distribution achieved by the previous HASHFUNCTION macro
> wasn't that great. The algorithm for the new hash_func is stolen
> from cpplib, so it ought to be good. :) :) At any rate, improvements
> to hash_func are welcome (so long as it remains address-independent).
Incidentally, the NetBSD people tried out a bunch of hash functions
for their kernel (including the much-touted FNV) for hashing both text
and binary data last week. They found that the Perl hash was one of
the best, in terms of both speed and distribution. They tested some
hash from GCC 2.95, which wasn't as good as the Perl one.
I tried out the cpplib hash on about 10000 file names (their test for
text) and 1.5MB of /dev/urandom output (their test for binary data).
I found that the current cpplib hash was as good as the Perl hash
(same in speed, sometimes better sometimes worse for distribution).