On Wed, 13 Apr 2011 13:15:50 +0200 Cedric BAIL <cedric.b...@free.fr> wrote:
> On Wed, Apr 13, 2011 at 2:47 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > 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). > > I completly agree with you on this, and in fact most test case for > eina benchmark are not real use case. In fact, I planned some time ago > to dump a trace of eina usage by e17 or some elementary apps directly > and use that as a source of benchmark. But I got lazy, and never did > it (only stringshare as something like that, but the resulting file is > hardly usable by a C compiler). Maybe it would be doable with some > hack and Gustavo's liblogger. If someone as some time to spend on > improving eina benchmark :-) This seems to be a somewhat comprehensive test suite for hash functions that may be interesting for people to look at: http://code.google.com/p/smhasher/ -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
