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. > > > -- > ------------- 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
