This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Support separate benchmark outputs


On 16 April 2013 21:20, OndÅej BÃlka <neleai@seznam.cz> wrote:
> That is my point that you must measure relative performance. However
> code above does not measure performance. In simple test

No, your idea of relative performance is different from mine -
actually I can't call it mine since these are already existing tests
(written by Jakub I think) that I'm only copying over.  From your
description it seems like your definition of relative is the original
memcpy vs the modified memcpy.  Here 'relative' implies comparison
between multiple implementations of functions, i.e. the sse3, sse4,
avx, etc. and then with the generic implementation and finally the
simple byte copy/move/write, etc.

> According to sequential glibc implementation is better than my by 15%.
> However when I sample randomly my implementation becomes 33% better than
> glibc one.

There's a do_random_tests in memcpy (and possibly in others too, I
haven't checked) that is there just for correctness tests.  It can be
trivially modified to measure the cost of the calls and make into a
reasonable random sampling benchmark.

Siddhesh
--
http://siddhesh.in


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]