Re: [E-devel] E SVN: discomfitor IN trunk/eina: . src/tests

[Leif M. <lei...@gm...>]

Am 15.04.2011 um 08:24 schrieb Carsten Haitzler (The Rasterman) <ra...@ra... 
 >:

> On Wed, 13 Apr 2011 15:51:08 +0200 Leif Middelschulte
> <lei...@gm...> said:
>
>> 2011/4/13 Cedric BAIL <ced...@fr...>:
>>> On Wed, Apr 13, 2011 at 2:47 AM, Carsten Haitzler <ra...@ra... 
>>> >
>>> wrote:
>>>> On Tue, 12 Apr 2011 19:16:43 -0400 Mike Blumenkrantz <mi...@ze... 
>>>> >
>>>> said:
>>>>> On Tue, 12 Apr 2011 16:12:52 -0700
>>>>> "Enlightenment SVN" <no-...@en...> 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)    ra...@ra...
>