On Wed, 13 Apr 2011 13:15:50 +0200
Cedric BAIL <cedric.bail@...> wrote:
> On Wed, Apr 13, 2011 at 2:47 AM, Carsten Haitzler <raster@...>
> wrote:
> > On Tue, 12 Apr 2011 19:16:43 -0400 Mike Blumenkrantz <mike@...>
> > said:
> >> On Tue, 12 Apr 2011 16:12:52 -0700
> >> "Enlightenment SVN" <no-reply@...> 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 :-)
This seems to be a somewhat comprehensive test suite for hash functions that
may be interesting for people to look at: http://code.google.com/p/smhasher/
--
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

On Thu, Apr 14, 2011 at 10:18 AM, Vincent Torri <vtorri@...> wrote:
> On Thu, 14 Apr 2011, Enlightenment SVN wrote:
>> Log:
>> unrevert. this is not a mistake.
>
> explain me why it can segfault, then
I think Vincent is right. I don't see how moving a list to an unvalid
position could be considered good behaviour in the calling code. Seems
to me like a way to hide bug. Please explain.
--
Cedric BAIL

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details