On Mon, Sep 09, 2013 at 05:11:36PM +0000, Joseph S. Myers wrote:
> On Mon, 9 Sep 2013, Will Newton wrote:
> 
> > I believe the glibc memcpy benchmark is not capable in its present
> > form of showing the difference between this version of the code and
> > the current one:
> > 
> > 1. The variety of alignments benchmarked is not adequate
> > 2. The variability of the benchmark results is quite high (more runs
> > required and page allocation issue)
> > 3. The output of the benchmark contains no measure of variance
> > 4. There is no means of showing graphically the output of the
> > benchmark (for subtle differences this is necessary IMO)
> 
> Please make sure the wiki todo list 
> <https://sourceware.org/glibc/wiki/Development_Todo/Master> includes all 
> these areas for improvement of the benchmarks.
> 
> > These are all surmountable problems but I would rather not gate
> > acceptance of this code on a satisfactory resolution of the above
> > issues. I can provide output from the cortex-strings benchmark quite
> > instead though.
> 
> If your summary of the benchmarking discussion indicates that the existing 
> glibc benchmark is not relevant for the cases addressed by the patch, then 
> it's indeed appropriate to give such results from another benchmark.
> 
I would prefer get profiling results in arm, I wrote simple tool that
measures time and variance of how long it takes gcc to compile with
different memcpy versions. 

For it you need to compile old and new memcpy as separate libraries that
will be preloaded. For that you need to compile memcpy as standalone
library like 

gcc -fPIC -shared   old_memcpy.S -o old.so
gcc -fPIC -shared   new_memcpy.S -o new.so

and place old.so and new.so to benchmark directory, then run
./benchmark 

It may take long until variance becomes statistically significant so its
better ran overnigth.

If you want check another command copy and modify benchmark script.