This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] benchtests: Memory walking benchmark for memcpy
- From: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 4 Oct 2017 12:23:44 +0530
- Subject: Re: [PATCH 1/2] benchtests: Memory walking benchmark for memcpy
- Authentication-results: sourceware.org; auth=none
- References: <1505756414-12857-1-git-send-email-siddhesh@sourceware.org> <be10b3b8-6440-cacb-62e1-6e44559e7fca@redhat.com> <7d713462-4db7-bdb8-c42c-61da43ccbf9f@sourceware.org>
- Reply-to: siddhesh at sourceware dot org, siddhesh at sourceware dot org
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.
Siddhesh