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 :-) -- Cedric BAIL ------------------------------------------------------------------------------ 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
