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