[PATCH 1/2] benchtests: Memory walking benchmark for memcpy

[Carlos O'Donell]

On 10/03/2017 11:53 PM, Siddhesh Poyarekar wrote:
> On Friday 22 September 2017 05:29 AM, Siddhesh Poyarekar wrote:
>> On Thursday 21 September 2017 11:59 PM, Carlos O'Donell wrote:
>>> I like the idea, and the point that the other benchmark eventually degrades
>>> into measuring L1 performance an interesting insight.
>>>
>>> I do not like that it produces total data rate not time taken per execution.
>>> Why the change? If time taken per execution was OK before, why not here?
>>
>> That is because it seems more natural to express string function
>> performance by the rate at which it processes data than the time it
>> takes to execute.  It also makes comparison across sizes a bit
>> interesting, i.e. the data rate for processing 1MB 32 bytes at a time vs
>> 128 bytes at a time.
>>
>> The fact that "twice as fast" sounds better than "takes half the time"
>> is an added bonus :)
> 
> Carlos, do you think this is a reasonable enough explanation?  I'll fix
> up the output in a subsequent patch so that it has a 'throughput'
> property that the post-processing scripts can read without needing the
> additional argument in 2/2.

As the subsystem maintainer I defer to your choice here. I don't have a
strong opinion, other than a desire for conformity of measurements to
avoid confusion. If I could say anything, consider the consumer and make
sure the data is tagged such that a consumer can determine if it is time
or throughput.

-- 
Cheers,
Carlos.