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 v1.1] Randomize memcpy benchmark addresses.


On 5 September 2013 15:15, OndÅej BÃlka <neleai@seznam.cz> wrote:
> On Thu, Sep 05, 2013 at 01:00:17PM +0100, Will Newton wrote:
>> On 5 September 2013 12:32, OndÅej BÃlka <neleai@seznam.cz> wrote:
>> >> This means we no longer print what the buffer alignment is which makes
>> >> results analysis impossible.
>> >>
>> > Could you elaborate.
>>
>> The current benchmark shows the performance for memcpy for a given
>> length and source/dest alignment. This can be analyzed to see where
>> performance is strongest and weakest. If we do not print the alignment
>> of the buffers for each test then we can't do this analysis.
>>
> There are 1024 possible alignment to given size(assuming 64byte cache
> lines). Some pairs tend to be slower than others as we need to cross cache lines
> when reading/writing.
>
> Current benchmark prints results for 4 pairs of alignments. Please
> explain why do you thing that best and worst case are among them.

I don't think the current tests test all the necessary alignments but
that is a separate issue from whether or not we should print the
benchmarked alignment. For example, if a memcpy implementation has an
average case performance that is equal to another across a range of
random alignments it may have quite different performance
characteristics with various specific alignments of buffers. I think
this is something that is useful to be able to see.


-- 
Will Newton
Toolchain Working Group, Linaro


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