On Fri, 15 Apr 2011 12:43:57 +0200 Leif Middelschulte <leif.middelschu...@gmail.com> said:
> Am 15.04.2011 um 08:24 schrieb Carsten Haitzler (The Rasterman) > <ras...@rasterman.com > >: > > > 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). > Might be, didn't check. > > 2. this isnt profiling a whole app or lib. it's benchmarking a > > specific hash > > implementation :) > You can get runtine stats per function. this would be stats inside a lib - gprof cant. oprofile can. even inside libs... BUT... it doesnt allow us to bench MULTIPLE has implementations side by side with the exact same input :) -- ------------- 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
