This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Improve string benchtest timing
General comment on performance test design:
The idea that it is worthwhile to measure memcpy with
misaligned src/dest that are mutually aligned shows
how exposure to particular implementations can
create blind spots in implementation. I'm speaking
of my own blind spot in this issue as I've been
involved in tuning platform specific memcpy
on Sparc/Solaris for over a decade and it never
occurred to me to test that particular case.
That's because the first memcpy code I worked from
[optimized for the Sparc Cheetah processor, first
available almost twenty years ago] had an early
test to determine if the src/dest were mutually
aligned and if so then move a few bytes until
they were long word aligned. Thus, for medium length
or longer copies, the performance was essentially
the same for aligned copies with aligned starting points
and aligned copies with misaligned starting points.
Full coverage performance testing of library code can be
challenging, especially when the "typical" usage pattern
is not predictable in advance. Even something as well
defined as memcpy can have very different usage patterns.
Examples:
Machine characteristic differences:
target machine supports/does not support misaligned access at full speed
target machine supports/does not support misaligned access at cost
similar to or less than mispredicted branch
target machine imposes major overhead for misaligned access
equivalent to a segfault, handled by the kernel
Even within a single architectural family, these details can
change with implementations. Across architectures like x86, sparc,
power, arm, etc. it can be very challenging to write 'general'
fast code.
Data characteristic differences also can be challenging:
Data is overwhelmingly aligned but often short
[Need to minimize testing before moving data]
Data is often misaligned sometimes aligned and large
[Best to special case various alignments with large copies
handled differently]
Data frequently overlaps
[Need to watch out for HW limitations on load/store timing]
and so on...
In writing tests, if we are buried in irrelevant data, we are more
likely to miss important changes while tuning. But if we trim the
tests too much, we may miss important limitations of the implementation.
Another opportunity comes in how the data is presented. If the
data to be compared is spread in an irregular way, it is more
difficult to identify trends as opposed to random variations.
I find the current standard glibc mem* performance tests difficult to
quickly skim/compare for possible performance regressions.
I've just touched on a few of the issues involved for memcpy perf work.
malloc is even more complex which is why we are still discussing
how to performance test glibc malloc.
- Patrick McGehearty (patrick.mcgehearty@oracle.com)
On 5/21/2019 9:11 AM, Siddhesh Poyarekar wrote:
On 21/05/19 7:28 PM, Wilco Dijkstra wrote:
Well the test doesn't actually test misaligned copies - both source and
destination are always mutually aligned, so any memcpy implementation which
aligns either source or destination will only do aligned copies.
They were not intended to be mutually misaligned, that was not the
intent of the benchmark since the target application it modeled did not
have such inputs.
In any case I'm not sure what the test is supposed to measure - the scores are
identical across all memcpy implementations. The time taken for double the
copy size is exactly twice as much.
Right, you'll probably only see differences in case of mutually
misaligned inputs.
Siddhesh