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: Victor Rodriguez <vm dot rod25 at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: siddhesh at sourceware dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 4 Oct 2017 17:45:23 -0500
- 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> <ea9cf4c3-e24f-ceae-2034-9a86368c0345@sourceware.org> <03cbcfa5-28c0-1a15-71fb-1a446d845325@redhat.com>
On Wed, Oct 4, 2017 at 5:19 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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.
Quick question , do you think it might be good idea to add this test
into the prhonix glibc bench :
https://openbenchmarking.org/test/pts/glibc-bench
https://openbenchmarking.org/innhold/cac2836cd5dbb8ae279f8a5e7b0896272e82dc76
If so, let me know so I can work on add it
regards
Victor Rodriguez