Re: memcpy performance regressions 2.19 -> 2.24(5)

[Carlos O'Donell <carlos at redhat dot com>]

On 05/05/2017 01:09 PM, Erich Elsen wrote:
> I had a couple of questions:
> 
> 1) Are the large regressions at large sizes for IvyBridge and
> SandyBridge expected?  Is avoiding non-temporal stores a reasonable
> solution?

No large regressions are expected.
 
> 2) Is it possible to fix the IvyBridge regressions by using model
> information to force a specific implementation?  I'm not sure how
> other cpus (AMD) would be affected if the selection logic was modified
> based on feature flags.

A different memcpy can be used for any detectable difference in hardware.
What you can't do is select a different memcpy for a different range of
inputs. You have to make the choice upfront with only the knowledge of
the hardware as your input. Though today we could augment that choice
with a glibc tunable set by the shell starting the process.

I have questions of my own:

(a) How statistically relevant were your results?
- What are your confidence intervals?
- What is your standard deviation?
- How many runs did you average?

(b) Was your machine hardware stable?
- See:
https://developers.redhat.com/blog/2016/03/11/practical-micro-benchmarking-with-ltrace-and-sched/
- What methodology did you use to carry out your tests? Like CPU pinning.

(c) Exactly what hardware did you use?
- You mention IvyBridge and SandyBridge, but what exact hardware did
  you use for the tests, and what exact kernel version?

(d) If you run glibc's own microbenchmarks do you see the same
    performance problems? e.g. make bench, and look at the detailed
    bench-memcpy, bench-memcpy-large, and bench-memcpy-random results.

https://sourceware.org/glibc/wiki/Testing/Builds

(e) Are you willing to publish your microbencmark sources for others
    to confirm the results?

-- 
Cheers,
Carlos.