On Wed, 13 Apr 2011 15:51:08 +0200 Leif Middelschulte <leif.middelschu...@gmail.com> said:
> 2011/4/13 Cedric BAIL <cedric.b...@free.fr>: > > 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 :-) > > As for runtime benchmark: Why not use gprof for e17 runtimes? > > Just my two cents, > > Leif 1. gprof not good - use oprofile if anything (gprof cant profile shared libs last i used it). 2. this isnt profiling a whole app or lib. it's benchmarking a specific hash implementation :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
