This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v1.1] Randomize memcpy benchmark addresses.
- From: Will Newton <will dot newton at linaro dot org>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 5 Sep 2013 13:00:17 +0100
- Subject: Re: [PATCH v1.1] Randomize memcpy benchmark addresses.
- Authentication-results: sourceware.org; auth=none
- References: <20130904163151 dot GB10358 at domone dot kolej dot mff dot cuni dot cz> <20130904165025 dot GA15899 at domone dot kolej dot mff dot cuni dot cz> <CANu=DmjT9Do_1rbVJUGmR=WqGZmwX+KWNvp1QDOQrij3L3q3Xg at mail dot gmail dot com> <20130905113241 dot GA5818 at domone dot kolej dot mff dot cuni dot cz>
On 5 September 2013 12:32, OndÅej BÃlka <neleai@seznam.cz> wrote:
> On Thu, Sep 05, 2013 at 08:41:02AM +0100, Will Newton wrote:
>> > -
>> > - printf ("Length %4zd, alignment %2zd/%2zd:", len, align1, align2);
>> > + printf ("Length %4zd, aligned %c/%c:", len, align1 ? 'y' : 'n', align2 ? 'y' : 'n');
>>
>> 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.
>> > test_init ();
>> > + buf1 = malloc (2 * SIZE + 4096);
>> > + buf2 = malloc (2 * SIZE + 4096);
>> > + buf1 = buf1 + 4096 - ((uintptr_t) buf1) % 4096;
>> > + buf2 = buf2 + 4096 - ((uintptr_t) buf1) % 4096;
>> > +
>>
>> What is 4096? We should avoid magic constants.
>>
>> buf1 and buf2 have already been allocated in bench-string.h. We should
>> make any solution work with that header and work for all string
>> benchmarks, not just one at a time.
>>
> Well buf2 was allocated as
>
> buf2 = mmap (0, 2 * page_size ...
>
> which is too small for this benchmark, so it needs to get changed.
I think if we need to expand the buffer we should do it in one place.
--
Will Newton
Toolchain Working Group, Linaro