On Tue, 12 Apr 2011 19:16:43 -0400 Mike Blumenkrantz <m...@zentific.com> said:

> On Tue, 12 Apr 2011 16:12:52 -0700
> "Enlightenment SVN" <no-re...@enlightenment.org> wrote:
> 
> > Log:
> > add bench for google's cityhash function (64bit,
> > http://code.google.com/p/cityhash/) convenient graph of output can be found
> > at http://www.enlightenment.org/~discomfitor/hash_bench.png 
> > 
> > Author:       discomfitor
> > Date:         2011-04-12 16:12:52 -0700 (Tue, 12 Apr 2011)
> > New Revision: 58610
> > Trac:         http://trac.enlightenment.org/e/changeset/58610
> > 
> All libraries compiled with the same cflags/cxxflags/ldflags/etc, glib 2.28.5,
> latest svn eina. It appears that cityhash is identical to superfast, and
> currently none of eina's tested algorithms scale as well as ecore's hash or
> glib's hash.

while i'm at it... eina_bench_hash.c ... is a REALLY POOR hash test. not only
does it have different results every time you run it (srand(time(NULL)) guys?)
different behavior per run.. it can differ per machine you run it on just based
on the libc thats there and nothing else. also it uses horribly SHORT keys.
(less than 10 chars) and its benchmarking HEAVILY favors adds not lookups as
per loop run it FILLS a hash with N items (from 10 up to 10,000) then it looks
up a random set of 200. that doesn't smell even remotely like real life usage.
(where hashes tend to be long-lived, filled over time or filled in one blob
then with LOTs and LOTs and LOTS of lookups. either way. the lookups will
dominate, not the adds.

i feel like fixing this so we have at least something approximating real life
behavior. chances are something like city hash only really shows itself once
our keys get much longer AND we have more lookups.

fyi ghash wins here. any results from this will be very much dependent on the
system you run it on - the architecture, memory bus, l1/l2(or l3) cache sizes,
compiler, optimizations flags... but even accounting for that... the benchmark
itself doesnt drive the hash in a realistic way. there are even zero deletes in
the bench. just a solid block of adds, then a fixed 200 lookups. we can debate
what real life usage looks like and then fix it... :) strlog is a dump from e17
running of its stringshare usage as an example of one set of real life usage
with stringshare (which is really a hash with just keys + refcount per key).

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to