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] Don't use SSE4_2 instructions on Intel Silvermont Micro Architecture.\


On Thu, Jun 27, 2013 at 11:54:23AM -0400, Carlos O'Donell wrote:
> On 06/27/2013 03:24 AM, Liubov Dmitrieva wrote:
> > I think for this particular patch we don't need super accurate
> > benchmarks to see that it is better because we talk not about 20-60%
> > of boost but about several times asymptotically boost as current
> > benchmarks showed. It was a server machine, nobody runs Firefox there.
> 
> Agreed, but we still need some kind of reproducible result that shows
> your patch improved performance. I'm not happy with performance patches
> going into glibc without some proof that they made things better.
> 
You said proof but we are not in proof stage yet. We are not in claim
stage yet. As these "benchmarks" are like mechr one please explain with
following code questions below: 

    for (i = 0; i < 32; ++i)
        {
          HP_TIMING_NOW (start);
          CALL (impl, s, c, n);
          HP_TIMING_NOW (stop);
          HP_TIMING_BEST (best_time, start, stop);
        }

1. You use only 32 element sample. Can you be sure that this sample is
big enough to be relevant?

2. You take minimum of these samples. Please explain how this is related
to real performance. 

3. You call this code in loop with same argmuments. Please explain why 
real world usage cases are close enough that we can observe same
behaviour in real world.

Unless you can satisfactory answer these questions you did not prove
anything about performance only got some numbers that are loosely
related to it. 


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